I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

More IE9 goodness and elementFromPoint()

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:

• getComputedStyle()
• cssRules[] (in addition to the proprietary rules[])
• deleteRule() and insertRule() (in addition to the proprietary addRule() and removeRule())
• innerWidth/Height and pageX/YOffset (!!!). Ever since the Browser Wars IE has refused to support these originally Netscape-proprietary properties, but IE9 supports them.
• pageX/Y (!!!). Back in 2002 I complained that IE didn’t give us the opportunity to read out the coordinates of a click event relative to the HTML document. Now IE9 finally gives us what we need.

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:

1. A selectorText bug.
   If a rule has selector p#test,ul, IE8 and lower split it into two separate rules, one for p#test and one for ul. IE9 has revised this behaviour: it’s now only one rule. Still, when querying the rule’s selectorText it returns p#test, and not p#test,ul. This must be fixed before the final release.
2. An honest oversight: IE9 does not support setProperty on style sheets. This is not important; nobody uses the ponderous and slightly absurd x.style.setProperty('color','#00cc00',null) instead of 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.

IE’s position

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.

After IE7 and IE8 had been released I was left wondering about Microsoft’s pace of improvement. Sure, both releases fixed a lot of CSS and JavaScript issues and added support for new stuff, but was that enough?

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.

elementFromPoint()

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 (pageX/Y).

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.

Future enhancements

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 display.

Still, elementFromPoint() can be improved here. In a future version it should return an array of elements located at the coordinates, in (reversed?) order of z-index.

Thus we’d get all the eligible elements, and it would be up to us to choose between them.

Pretty please, browser vendors?

Problems

Still, not everything is rosy. I’ve got a few issues with the non-IE browsers.

colorDepth in Firefox

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.

currentStyle

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.

imports

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.

Comments

Comments are closed.