Well, I’ve revised the DOM CSS and the DOM CSS OM tables, too, and IE9 continues its march. It supports the standards!
Let’s be more specific. The following methods or properties were not supported by IE8 or lower, but are supported by IE9:
There’s more, but these are the highlights.
Meanwhile I’ve discovered one bug and one oversight, which I’ll treat here for the benefit of the IE team:
p#test,ul, IE8 and lower split it into two separate rules, one for
p#testand one for
ul. IE9 has revised this behaviour: it’s now only one rule. Still, when querying the rule’s
p#test, and not
p#test,ul. This must be fixed before the final release.
setPropertyon style sheets. This is not important; nobody uses the ponderous and slightly absurd
x.style.color = '#00cc00', but for completeness’ sake it would be nice if IE9 supported it.
But that’s it. These are the only two IE9 problems I discovered in this round of revising. If we add the
white-space: pre-line bug I discovered earlier we get to a grand total of three IE9 bugs.
Not bad, Microsoft. Not bad at all.
So what does all this mean for IE’s position in the browser landscape? It’s obvious that it has improved that position, but there’s more.
The question was whether IE improved faster than the other browsers. Pure improvement rate is an unreliable metric at best; if you improve but the other browsers improve faster, you’ll fall even further behind.
I doubted that IE’s improvement rate was enough. With the advent of IE9, however, I doubt no more. Microsoft has made a giant leap forward, and I feel that, certainly in the traditional, non-HTML5 methods and properties, IE’s improvement rate now exceeds that of the other browsers. (They have more stuff to improve, but still.)
I haven’t yet studied HTML5 and related items, and I wouldn’t be surprised if IE still lags there, and that its rate of improvement is not enough yet. Nonetheless, that might change with IE10, now that the obvious stuff has been done. And who knows, I might even be wrong, and IE9 might show a prodigious rate of improvement in HTML5, too.
Another major improvement has been added by Safari, Chrome, and Opera.
elementFromPoint() allows you to see which element is located at a specified coordinate pair. This is a godsent for drag-and-drop scripts: just get the mouse coordinates at the time the user releases the element, find the element that’s located there, and you know the drop target.
Until now, however, there was an incompatibility in the coordinates themselves. IE and Firefox required coordinates relative to the browser window (
clientX/Y), while the other browsers required coordinates relative to the HTML document (
No more. Safari, Chrome, and Opera have followed IE’s and Firefox’s lead and now also support coordinates relative to the browser window. As a result
elementFromPoint() is now truly usable.
There’s a catch here, however.
elementFromPoint() returns the topmost element located at the requested coordinates, and when you use
position: absolute that might matter. More specifically, any drag-and-drop script uses absolute positioning, which means that when you directly query
elementFromPoint() the browser returns the dropped layer, and not the element that’s underneath it.
The solution is to first give the dropped layer a
display: none, then query
elementFromPoint(), and then restore the dropped layer’s original
elementFromPoint() can be improved here. In a future version it should
return an array of elements located at the coordinates, in (reversed?) order of
Thus we’d get all the eligible elements, and it would be up to us to choose between them.
Pretty please, browser vendors?
Still, not everything is rosy. I’ve got a few issues with the non-IE browsers.
First of all, an old Firefox bug returned. Right now Firefox 3.6 returns 24 when you query
colorDepth/pixelDepth, and that’s clearly incorrect on my system, which has a color depth of 32; a depth that’s properly returned by all other browsers.
An earlier Firefox version also had this bug, but it was corrected in the next version. Can’t remember which ones.
Also, Firefox, Safari, and Chrome stubbornly refuse to support
currentStyle. Yes, this is a Microsoft proprietary property, but it’s one of those MS properties that’s just a bloody brilliant idea.
The syntax of
getComputedStyle() is very ugly, and besides it always returns the value you query in pixels.
currentStyle returns the value in whichever unit the style sheet is really using.
Sometimes you need the one, sometimes the other. IE9 and Opera support both. I think Firefox, Safari, and Chrome should move on and implement
currentStyle. And no, it’s not in the standard, but if we have to wait for W3C nothing will ever happen.
Similarly, it would be useful if all non-IE browsers also supported the
imports array, which gives a list of imported style sheets. This is not nearly as important as
currentStyle, but it could conceivable be useful in edge cases.
Upcoming speaking gigs:
Comments are closed.