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:

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'color','#00cc00',null) instead of = '#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.


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?


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.


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.

This is the blog of Peter-Paul Koch, web developer, consultant, and trainer. You can also follow him on Twitter or Mastodon.
Atom RSS

If you like this blog, why not donate a little bit of money to help me pay my bills?



Comments are closed.

1 Posted by RaphaelDDL on 29 June 2010 | Permalink

While i hate MS IE because of IE6, i must confess that IE9 is proving that MS saw the big crap they made until version 8 and are trying to get back to market.

Unfortunately, the lack of upgrades in lots of comps with fake windows make the transition to newer versions even worse.

"Also, Firefox, Safari, and Chrome stubbornly refuse to support currentStyle. Yes, this is a Microsoft proprietary property"

Maybe has something to do about copyright and stuff like that since it's proprietary?

2 Posted by Markus Stange on 29 June 2010 | Permalink

The colorDepth change to 24 in Firefox was made in order to follow the spec at - see the discussion on

3 Posted by Brian LePore on 29 June 2010 | Permalink

For anyone curious, IE9's getComputedStyle does not return a CSSStyleDeclaration element with a cssText property with the every style for that element on it. This is similar to how Gecko and Opera behave, though I find the Webkit version to be significantly more useful.

4 Posted by ppk on 29 June 2010 | Permalink

@Markus: interesting; that was about my previous bug report. They changed it to 32 (it's still 32 in FF 3.5), but 3.6 has reverted to 24.

It's not really important, but it's one of those things that are just incomprehensible to web devs.

Besides, colorDepth is usually used by web statistic scripts, and everybody will become hugely confused when one browser suddenly reports 24.

I still count this as a bug, although it seems that on Mac the 24 camp is winning.

5 Posted by Jonas Munk on 29 June 2010 | Permalink

MS now has a reason to improve IE since they are building more browser based apps.

If they did this years ago Google or others might have replaced Office with a web based interface.

I'm sure it is all very calculated :-)

6 Posted by Raphael on 29 June 2010 | Permalink

According to the numbers on this site:

ie9 only supports 58% of HTML5 elements. The other browsers are around 80-90%. I'm not sure how current their numbers are, but they seem to update it pretty often.

Thanks for your hard work, PPK!

7 Posted by GreLI on 29 June 2010 | Permalink

Jonas Munk: version exists that Microsoft realized power of browser apps long ago and stopped IE development in fear it will broke Windows monopoly. But now other browsers going forward and Microsoft have to rush development otherwise they lose browser market.

8 Posted by Klaus on 29 June 2010 | Permalink

Nice suggestion for elementFromPoint. The possibility to get all the elements below a given point will be amazing. I needed that feature in a project a few months ago and the only option for me was to hide the top elements in other to find out what is below.

Hope to see it working in a near future!

Thanks for sharing all this content. :)

9 Posted by Offbeatmammal on 30 June 2010 | Permalink

Loving the advances in the IE9 preview ... best thing it that it's not breaking a lot of what went before.

just wish Webkit/Opera would do like IE9 and revist a lot of the older things they didn't support and enable basic functions like window.onerror to at least provide a common framework going forward

10 Posted by Graham on 30 June 2010 | Permalink

FINALLY they have caught up with the standards, it's only taken 9 years! Just a shame they don't make it available for XP users, still means they are holding back the web :-(

11 Posted by wds on 30 June 2010 | Permalink

Browsers on other platforms have reported 24bit for years, as this is the actual colour depth. The remaining are unused/alpha. Statistics scripts do not have a problem with it, since they're used to seeing 32 and 24 bit as synonyms in this regard.

This is one of those cases where the standard is clearly saying you should return 24, and firefox is doing exactly that.

12 Posted by Erik Arvidsson on 2 July 2010 | Permalink

For drag and drop scenarios you can use pointer-events: none; It is supported in WebKit and Gecko and makes elements transparent to mouse (pointer) events.

13 Posted by majoro on 15 July 2010 | Permalink

Good that Micro$oft is now striving to make IE more standards-compliant. But the damage has already been done; people (like me) hate IE for being notoriously non-standards most especially IE6. As a web developer IE6 has been my worst enemy (and sure other WebDevs do) because of headaches it give in my struggle to make my projects to work in all browsers as possible.

But I am not sure if IE would retake the market again with the growing number of users of Firefox and Chrome.

14 Posted by Christian Effenberger on 17 August 2010 | Permalink

You wrote that you've found only three IE9 bugs. Well maybe I've found another one.

After modifying the code of my programs to support IE's mode 9 (canvas), I discovered a problem on empty div's with background set to transparent.

It seems to be the same old bug like in IE6/7. Setting a transparent gif as a background url was the only way to get rid of the bug.