I hate MSIE (yet again)
Wednesday, 3. October 2007, 17:54:08
Things found as a bug in MSIE7:
1
Set a background colour on generic input elements using CSS, and MSIE7 will apply that background on the outside of radio and checkbox inputs as well... and I found nothing to prevent that, short of not setting it at all.
We could set the background to transparent, but browsers like Opera, Firefox and Safari actually obey that order, rendering the element invisible.
We could use an attribute selector like input[type=text] but some older versions of Microsoft's excuse for a browser don't recognise that.
Thus we are forced to add classes to all our inputs... still.
2
Create an absolutely positioned SELECT element in runtime using createElement and set the focus to that element upon clicking f.i. a button. Make the new element appear next to the button clicked. If the page is longer than the window is high (which is common), MSIE7 (not 6!) makes the page jump... sometimes so far that the focussed SELECT element no longer is in view...
We want to focus the element because creating it in runtime breaks tab order, meaning a user without a mouse can't focus it themselves. But MSIE7 scrolling that element out of view completely destroys that benefit.
Suffice to say that none of the competitors (Safari, Opera, Firefox) display this unfriendliness.
3
Save session scope cookies to the browser, and MSIE7 (and maybe older versions too) will fail to clean them up when the user tells the browser to remove its cookies. All the competitors have a mechanism to remove these...
4
Set a div's CSS position to 'fixed', and MSIE7 will miscalculate all its childrens' heights and widths... instead of calculating in relation to their fixed container, MSIE7 starts calculating in relation to the body, the html, the window... or whatever it chooses at that moment. This is particularly visible if the child element is an IFRAME or an OBJECT.
Solution: make all the children of the fixed container fixed as well, and hand different sizes for those elements to MSIE7 only.
The competition behaves as expected: calculating in relation to the container.
5
MSIE7's XSS prevention (cross site scripting) is a bit too strong to my liking: tell an IFRAME to load a page from a different site, it will... but tell an OBJECT to do the same, and it won't... not even when the correct classid is set for loading text/html. Load a page from the same site and the two elements behave interchangebly.
For the competitive browsers this problem does not exist.
6
Try loading images into OBJECT elements and you will notice that MSIE7 is unable to load JPG and BMP... and maybe more.
7
Serve an XHTML page to MSIE7 as application/xhtml+xml and find that MSIE7 will refuse to render it... it does not know application/xhtml+xml and since Microsoft is keeping hush about MSIE8 it seems they won't be adding support for it any time soon.
Luckily all the other browsers big and small know it, so we can serve real applications to those, while MSIE7 prefers reading TAG SOUP.
8
First tell MSIE7 to load an image with a certain size. Don't supply width and height attributes. Then change the image to something with a different (but near enough) size. Hit ctrl-F5 to force reload without cache. MSIE7 will load the new image... but displays it with the old image's size.
Try opening the image in a new tab page and load it. MSIE7 will load the image nicely, with the correct size. Go back to the original tab and reload the page... still wrong.
Close MSIE7, open the Control Panel for Internet Options, and empty the temporary internet files. Restart the computer, just to be sure. Go back to the page and reload... still wrong.
Still wrong!
Try holding ctrl while clicking the little reload button on the screen, next to the address bar. Finally, MSIE7 decides to read the new image's sizes and display them correctly.
Do I even need to say how the competition fares in this respect?
1
Set a background colour on generic input elements using CSS, and MSIE7 will apply that background on the outside of radio and checkbox inputs as well... and I found nothing to prevent that, short of not setting it at all.
We could set the background to transparent, but browsers like Opera, Firefox and Safari actually obey that order, rendering the element invisible.
We could use an attribute selector like input[type=text] but some older versions of Microsoft's excuse for a browser don't recognise that.
Thus we are forced to add classes to all our inputs... still.
2
Create an absolutely positioned SELECT element in runtime using createElement and set the focus to that element upon clicking f.i. a button. Make the new element appear next to the button clicked. If the page is longer than the window is high (which is common), MSIE7 (not 6!) makes the page jump... sometimes so far that the focussed SELECT element no longer is in view...
We want to focus the element because creating it in runtime breaks tab order, meaning a user without a mouse can't focus it themselves. But MSIE7 scrolling that element out of view completely destroys that benefit.
Suffice to say that none of the competitors (Safari, Opera, Firefox) display this unfriendliness.
3
Save session scope cookies to the browser, and MSIE7 (and maybe older versions too) will fail to clean them up when the user tells the browser to remove its cookies. All the competitors have a mechanism to remove these...
4
Set a div's CSS position to 'fixed', and MSIE7 will miscalculate all its childrens' heights and widths... instead of calculating in relation to their fixed container, MSIE7 starts calculating in relation to the body, the html, the window... or whatever it chooses at that moment. This is particularly visible if the child element is an IFRAME or an OBJECT.
Solution: make all the children of the fixed container fixed as well, and hand different sizes for those elements to MSIE7 only.
The competition behaves as expected: calculating in relation to the container.
5
MSIE7's XSS prevention (cross site scripting) is a bit too strong to my liking: tell an IFRAME to load a page from a different site, it will... but tell an OBJECT to do the same, and it won't... not even when the correct classid is set for loading text/html. Load a page from the same site and the two elements behave interchangebly.
For the competitive browsers this problem does not exist.
6
Try loading images into OBJECT elements and you will notice that MSIE7 is unable to load JPG and BMP... and maybe more.
7
Serve an XHTML page to MSIE7 as application/xhtml+xml and find that MSIE7 will refuse to render it... it does not know application/xhtml+xml and since Microsoft is keeping hush about MSIE8 it seems they won't be adding support for it any time soon.
Luckily all the other browsers big and small know it, so we can serve real applications to those, while MSIE7 prefers reading TAG SOUP.
8
First tell MSIE7 to load an image with a certain size. Don't supply width and height attributes. Then change the image to something with a different (but near enough) size. Hit ctrl-F5 to force reload without cache. MSIE7 will load the new image... but displays it with the old image's size.
Try opening the image in a new tab page and load it. MSIE7 will load the image nicely, with the correct size. Go back to the original tab and reload the page... still wrong.
Close MSIE7, open the Control Panel for Internet Options, and empty the temporary internet files. Restart the computer, just to be sure. Go back to the page and reload... still wrong.
Still wrong!
Try holding ctrl while clicking the little reload button on the screen, next to the address bar. Finally, MSIE7 decides to read the new image's sizes and display them correctly.
Do I even need to say how the competition fares in this respect?
WIDGETIZE