This one is actually more of a general html tip - often you will need to do one thing in IE version xX and another in compliant browsers. Traditionally this is solved either server side, via javascript, or this 3rd method supplied by MS them selves.

I was actually a little surprised to learn that a lot of people aren't aware of microsofts "conditional comments". Now granted it's once again a departure from standards ( but then if they followed the standard we would not need this trick ), however the beauty of this trick is that every browser but IE will ignore it completely since it's a comment.

<!--[if lt IE 7]>
<strong>This is internet exploder version 7</strong>
<![endif]-->

you can put this anywhere in the mark up and put any markup inside.

the syntax is
if condition IE version

version can be any IE version as 5.5000 or 6, etc.. if ommited it will match against any IE

condition can be one of

lt - less than ( < )
lte - tess than equal ( <= )
gt - greater than ( > )
gte - greater than equal ( >= )
eq - equal  ( == )
! - not equal ( != )

a final tip - if you omit the -- in the above the contents between will no longer be a comment and the tags will to other browsers just be illegal markup ( and as such per w3c standard ignored ).

That means if you do

<![if ! IE]>
Then the text here will be displayed by every browser but IE, clever no?
<![endif]>

Personally I most often use this to server up different style sheets to the various versions of IE to ensure that the page at a bare minimum is viewable despite the viewer using a crap browser.

This weeks tip is quite short but is very handy even so

for( key in array ){
// do something with array[key]
}

This has a few nice uses

• Traversing "hash maps" ( ie arrays where they keys are not continuous integers, but could be strings, objects, etc )
• Enumerating properties of unknown objects

The last case is very handy for debugging - in fact I use it in the js debugger I posted earlier.


Addendums to Javascript tip of the week#2

---

1)
The order events are executed in are reverse with IE's attachevent ( FILO queue ) when compared to the other solution.

This problem can be solved for your function atleast by keeping an array of functions that are added to the event and the executing a custom function to execute them in the correct order.
How ever the code for that is outside the scope for a simple tip

2)
The show code does not use/show the correct (w3c) way of doing it - I had to  remove it due to a bug.
Having found the bug you can add the w3c code by inserting

	if (src.addEventListener){ //W3C, DOM level 2
		src.addEventListener("load",func,false);
		return;
	}else if ( src=window && document.addEventListener != undefined ){
		document.addEventListener("load",func,false); //Opera 7
	}

after the IE if clause - seems the bug I experienced was IE trying ( and failing I migth add ) to use src.addEventListner, but putting the IE check in before it once again works.

Tho the function works just fine without this the code is more "correct" with it 8)

Decided to release it, I'm still not very happy with how the main section looks - but if I'm forced to look at it maybe I will finaly get up and do something about it ...

now I just need to find some time in my every so busy schedule

Been working on a javascript library for stuff we commonly do at my job (idefa.dk) , one thing that tends to happen from time to time is having a iframe resize to the content inside.
Now if you controll the content of the page loaded in the iframe it's not a problem, you simply have an onload in that document and hey presto.

No the fun starts when you for what ever reason can not do that - maybe the page is generated by something outside of your controll or what ever, that is not important.

Assuming that you have a function for resizing named "resize();" the most obvious ways are:

<iframe id="ifr1" onload="resize();">

or

document.getElementById("ifr1").onload="resize();";

But ofcourse being able to assing it in javascript is much cooler

However the second option does not work in Internet Exploder - but then we hardly expected MS to conform to any sort of standard especialy not when dealing with event and attributes.

Anyway after trying just about everything I came up with this function;

function addOnLoadEventSrc(func,src) {
	if (src.attachEvent){ //Internet Exploder
		src.attachEvent("onload",func);
		return;
	}
	var oldonload = src.onload;
	if (typeof src.onload != 'function') {
		src.onload = func;
	} else {
		src.onload = function() {
			if (oldonload) {
				oldonload();
			}
			func();
		}
	}
}

to use our previous examples you would need to call

addOnLoadEventSrc(resize(),document.getElementById("ifr1"));

It bears mention that I've yet to test it in IE 6 & 5.5  - still I only have acces to those two via wine emulation so not the most reliable test.

If anyone test them and they come up with an error in one of those two browers ( or any other exotic browser ) I'd appreciate a mail about it, more so if you know how to fix it.


Gotcha:
If the page with the iframe and the one inside does not reside on the same domain you cannot resize to the content as most modern browsers wont allow it ( cross site scripting ).


Update:
Code has been bugfixed

Was going to make this a tip of the day thing, but I know how lazy I am. Plus of course I can not  guarantee  that I will find something to tick me off I IE quite that often

You may know most of the tips that I will bring. But if like me you memory is comparable to a sieve, you will only remember that there is a workaround - not what the actual workaround is. This is where hopefully this series will be helpful.

If you need to assign the onchange attribute of say a <select> element the correct way of doing that is:

el.setAttribute("onchange", "doStuff(this.selectedIndex);");

assuming of course that you have a variabled called el that is a reference to the element, and this works quite well... just not in ( supprise ) Internet explorer (IE).

To make it work you need to do:

el.onchange=function(){doStuff(this.selectedIndex)};

This is properly down to some IE engineer failing to read the w3c DOM specs properly, still at the rate Microsoft usually fixed things this should work natively in IE 11.

Both methods work in Firefox.


ps. The new design wont be finalized till sometime after feb 1st as I've a rather harsh deadline there.