A nice DOM property I bet most of you have missed ...

Have you ever heard about the defaultValue and the defaultChecked properties?
They seems to be a standard DOM properties so the major browsers seem to support them.
What they do?
The defaultValue property is about textboxes (input type="text") and it will contain the value which the textbox has at the time it was rendered on the page.
The defaultChecked property is almost the same, it is about a checkbox and it tells you whether the checkbox was rendered checked or not.

So doing something like:

function hasTextBoxChanged(textBox) {
return textBox.defaultValue == textBox.value;
}

would tell you whether the textbox passed as an argument has changed its value since it was rendered on the page.

Same function for checkbox would be something like:

function hasCheckBoxChanged(checkbox) {
return checkbox.defaultChecked == checkbox.checked;
}

I find those properties very helpful. If you play a bit with jQuery you can find a real life application of them.
I am however wondering if there are such properties for dropdowns and some other controls.
If I find - I'll definatelly post again.

Hope it helps someone outthere ...

P.S. if the control is a part of update panel and it was udpated in the code behind it will not be counted as a change as the defaultValue / defaultChecked properties will be set again (those properties are taken to be the value of the control when it was rendered).

Join the W3C feature suggestions group in Facebook!

You want to see a feature as a part of the W3C standard?
Join the W3C feature suggestions group in facebook:

http://www.facebook.com/srch.php#/group.php?gid=111306074563

You may find the feature already included or find a workaround ...

Work in a cooperation with your compiler. Always tell the truth about your datatypes!

When you have a cast you should avoid asking the compiler to figure out what kind of data should be returned. This is more about objects and the string data type.
For example I've seen (and to be honest I myself did the following mistake when getting data from DataSet. Don't laugh in .NET 1.1 and 2.0 there was no Linq :)

foreach (DataRow row in dsReportSource.Tables[0].Rows)
{
string strName = row["name"].ToString();
}

The compiler will let you think that it knows how to do the fastest transformation from object (in the dataset all the columns in a row are objects) to the destination type (in our case - string). But it will only let you think so. What will actually happen is that the compiler will slow down the data acquisition due to some internal checks and conversions ...

Instead do the following (as you are more than sure that this column is string):

foreach (DataRow row in dsReportSource.Tables[0].Rows)
{
string strName = (string)row["name"];
}

This way you tell the compiler - "Look, don't even bother to try to infer the type for me. I am telling you this is a string, so please just treat it as string). And it makes sense - after you have a column of type NVARCHAR in the database it will always come to you as a string (masked as object :).

Now there are even worse cases like:

foreach (DataRow row in dsReportSource.Tables[0].Rows)
{
int iId = int.Parse(row["id"].ToString());
}

As you can see you are parsing the id column. You know it's int. But int.Parse can only work on strings, so you are required to turn this object to string, calling its .ToString() method. This will slow down your code insignifficantly on few rows and signifficantly on more rows (few thousands for example).

The following is also wrong:

foreach (DataRow row in dsReportSource.Tables[0].Rows)
{
int iId = Convert.ToInt32(row["id"]);
}

Here you are telling your compiller that you are sure the parameter (row["id"]) will cast to Int32 without problems.
But here you are telling your compiller only 50% of the truth. After you KNOW it is int, just be honest and say:

foreach (DataRow row in dsReportSource.Tables[0].Rows)
{
int iId = (int)row["id"];
}

This applies not only to DataSets but everywhere you have a fixed datatype and you know what the type is.


Don't let your compiler do the work.
Just look at your project and try to find places where you are uncertain about fixed datatype.
Change it to be a direct cast and I am pretty sure you will experience speed improvements.

W3C Zoom CSS property. I really want this feature included!!!

Lot's of people are discussing this.
And the designers are often saying something like:
"I cannot imagine a scenario where you will need to use the Zoom CSS property."
To the readers that haven't yet hit this problem - the CSS Zoom property seems to be proprietary and to be working for IE (I think version 6 and above).

To all those designers - there ARE scenarios where you will want to let the user zoom everything proportionally without using the browser buttons / sliders / shortcuts, but with CSS / JS only.
I will give you few examples:

1. I needed to create an overview control of page. It should represent the page in a smaller percentage and, upon scroll, the page should scroll proportinally. I can have a div with the same DOM tree (or even an IFrame loading the same page or something). In this case I URGENTLY need the CSS Zoom property.
2. Telerik radReporting - the ReportViewer has a dropdown to let the user choose a zoom level to preview the page (web based and not after clicking print preview or something). Actually the Print Preview browser command isn't an option as the report viewer may be on the page with other controls and the user SHOULD BE ABLE to zoom in and out only the portion of the page where the report is (it is an IFrame with the data rendered as HTML, I believe). In telerik case - there seems to be some browser detection and when the browser isn't capable of zooming in / out - the dropdown with the zooming levels is simply hidden (they have no other choice unfortunatelly and I support them for this decision).

Now, as you may expect - in my scenario I cannot simply hide the overview control as the page heavilly depends on it.
Should I now have my revenge now? I've seen all those messages accross the web telling you that there are better browsers to use than IE.
Should I now display a message like:
"Sorry, your browser isn't capable of zooming in and out, only IE supports this, so please switch to IE."

I really hate those browser wars and if you really want to know my opinion - yes, IE may be harder to design. It may be messing up the containers, it may not be passing the ACID N test.
But it is the only browser that is suitable for my scenario (at least from my search in IE all the posts were following the same line - "zoom is IE proprietary, it won't work under other browsers").
Why are all other browsers sleeping then?


P.S. I have found something like -moz-zoom or something but wasn't able to make it work under FireFox (if it works under Firefox it should also probably work under Google Chrome as they are using the same engine I think).
P.P.S. - haven't tested but I think the zoom CSS property should also be available under Opera as they (as far as I know) use the IE core.

P.P.P.S - if anyone know how can we ask W3C to reconsider this for at least the next revision of CSS I would be glad to give my vote. I also advice telerik to do the same. Not only the reporting will work in all browsers but they may be able to do some other great controls using this property.

Really annoying ...