Today I can finally unveil my most ambitious update: the Events compatibility tables. All in all I think I spent two weeks’ of work on them; testing all common events not only in common situations, but also in unusual ones. A quick test of basic browser support for W3C and Microsoft events completed this series of tests.

Unfortunately the testing of the load and unload events didn’t really fit the test format I devised; therefore information on these events is still lacking. (They generally work fine, though.)

Now only the Events properties table remains to be done, but first I’m going to take a well-deserved break from event testing.

Event delegation is especially useful in effects like dropdown menus, where lots of events on links may take place that can easily be handled at the root level (an <ol> or <ul> in this case).

There used to be one problem, though: although event delegation works fine for the mouse events, it does not work for the focus and blur events we need to make dropdown menus keyboard-accessible.

In the course of my ongoing event research, however, I found a way to delegate the focus and blur events, too. Maybe one of those frightfully clever JavaScript library authors will use this technique to shave off a few milliseconds of computing time

For all I know they're already aware of this technique; but it was new to me so I publish it anyway.

What is event delegation?

For those unaware of it, let's briefly discuss event delegation. As context I'll use a dropdown menu.

When a user uses a mouse to steer through a dropdown menu, you want to capture all mouseover and mouseout events in order to see whether the latest user action should open or close a menu. (You also have to carefully distinguish between useful and useless events because Firefox, Safari and Opera still don't support the mouseenter and mouseleave events, but that's another story.)

The mouseover and mouseout events bubble up; that is, when a mouseover event on a link fires, the event "climbs" the DOM tree to see if any mouseover event handlers are defined on the ancestor nodes of the link. It first checks the link itself, then goes on to the containing <li>, followed by the <ol>, and all the way up to document or window level.

That means that it's perfectly possible to define your generic onmouseover and onmouseout event handlers on the <ol> that forms the root element of the dropdown menu. When these events take place lower in the tree, event bubbling makes sure they eventually end up at the root element and can be handled there.

<ol id="dropdown">
	<li><a href="#">List item 1</a>
		<ol>
			<li><a href="#">List item 1.1</a></li>
			<li><a href="#">List item 1.2</a></li>
			<li><a href="#">List item 1.3</a></li>
		</ol>
	</li>
	[etc.]
</ol>

$('dropdown').onmouseover = handleMouseOver;
$('dropdown').onmouseout = handleMouseOut;

The great advantage of this trick is that you don't need to set two event handlers on every link, which may save some browser memory.

The focus problem

This works fine. However, as soon as you want to make your dropdown keyboard-accessible, too, you run into a problem.

In theory, making a dropdown keyboard-accessible is easy: you just define event handlers for the focus and blur events, too. The problem is that these events do not bubble up. A focus or blur event on a link fires only on the link itself, and not on any ancestor element of the link.

This is an ancient rule. A few events, most motably focus, blur, and change, do not bubble up the document tree. The exact reasons for this have been lost in the mist of history, but part of the cause is that these events just don't make sense on some elements. The user cannot focus on or change a random paragraph in any way, and therefore these events are just not available on these HTML elements. In addition, they do not bubble up.

Take the following situation:

<p id="testParagraph">
	Some text.
	<input id="testInput" />
</p>

$('testParagraph').onfocus = handleEventPar;
$('testInput').onfocus = handleEventInput;

When the user focuses on the input field, the handleEventInput function is executed. However, the event does not bubble up, so handleEventPar is not executed. In addition, it's not possible to focus on the paragraph (except when it has a tabindex attribute), so handleEventPar is never executed.

Event capturing

Except when you use event capturing.

Event capturing is the reverse of event bubbling. When an event bubbles up it starts at the event target and then moves up the DOM tree. When an event is captured, it starts at the top of the DOM tree (usually the window or document object) and then moves down to the event target.

One of the most curious conclusions of my event research is that when you define event handlers in the capturing phase the browser executes any and all event handlers set on ancestors of the event target whether the given event makes sense on these elements or not.

So let's take the same example as above, but now with addEventListener in the capturing phase. (You define it on the capturing phase by setting the last argument to true.)

<p id="testParagraph">
	Some text.
	<input id="testInput" />
</p>

$('testParagraph').onfocus = handleEventPar;
$('testInput').onfocus = handleEventInput;
$('testParagraph').addEventListener('focus',handleEventPar,true);
$('testInput').addEventListener('focus',handleEventInput,true);

Now if the user focuses on the input, the event starts at the window or document level and then moves down to the input. On the way it encounters the onfocus event handler on the paragraph and executes it, even though the event does not make sense on a paragraph.

As a result, handleEventPar is executed, and then handleEventInput.

IE

Unfortunately IE does not support event capturing. However, it supports the focusin and focusout events that, contrary to focus and blur, do bubble up. If we use these events to get IE on board, we're ready to sail.

Delegating the focus and blur events

Therefore the conclusion must be that onfocus and onblur event handlers may be delegated just as onmouseover and onmouseout are by registering them in the capturing phase. In order to properly delegate all events for a keyboard-accessible dropdown menu you do:

<ol id="dropdown">
	<li><a href="#">List item 1</a>
		<ol>
			<li><a href="#">List item 1.1</a></li>
			<li><a href="#">List item 1.2</a></li>
			<li><a href="#">List item 1.3</a></li>
		</ol>
	</li>
	[etc.]
</ol>

$('dropdown').onmouseover = handleMouseOver;
$('dropdown').onmouseout = handleMouseOut;
$('dropdown').onfocusin = handleMouseOver;
$('dropdown').onfocusout = handleMouseOut;
$('dropdown').addEventListener('focus',handleMouseOver,true);
$('dropdown').addEventListener('blur',handleMouseOut,true);

Now you've succesfully delegated the focus and blur events.

Example.

Further questions

The fact that the capturing phase of the event works different from the bubbling phase raises a few questions, which I might answer at a later date:

1. Shouldn't event bubbling and event capturing work exactly the same way? That is, shouldn't both phases either execute all event handlers they find or use the old "only on sensible elements" rule?
2. Isn't it time to allow all events to bubble up?

(Note: In the case of focus and blur, it might make sense for the events not to bubble up. After all, if a user focuses on a link or form field, you don't want any generic window.onfocus to fire, because on the window that event has a totally different function: it fires when the user focuses on the entire browser window.)

The presentation went well; I talked about the principles of unobtrusive JavaScript and it turned out that this concept was new to many attendees. I hope to have made a difference somewhere.

• Chris Heilmann:
  Unobtrusive Javascript
  The seven rules of Unobtrusive JavaScript
  
• Jeremy Keith:
  Behavioral Separation
• Het moet ook van de overheid:
  Het optionele karakter van client-side scripts

If you want to hear me talk about unobtrusive JavaScript in English, come to An Event Apart Boston (June 23rd-24th), where I'll present an updated version.

Testing event support is really awesomely complicated. I've been working steadily for two weeks now, and I still find new bugs and oddities daily, and twice on Sundays.

In any case, I discovered something remarkable when I studied the mousemove event. It sheds light on the way browser vendors keep track of each other's implementations nowadays, and on things that can go wrong.

Update: The bug described in this entry is an OS problem, and not a browser bug.

This is obviously a bug: when the mouse does not move the mousemove event should not fire.

The IE team reacted correctly: the bug has been solved in IE8b1. When the mouse does not move any more the mousemove event stops firing, as it should.

However, this same bug was recently introduced in Safari (Windows) and Opera!

Safari 3.0 and Opera 9.26 support mousemove correctly, but Safari 3.1 and Opera 9.5b have copied the IE bug.

What seems to have happened is that the IE team took a close look at other browsers' mousemove implementation, discovered that the IE5-7 implementation was buggy, and decided to correct the bug.

Simultaneously, however, the Safari and Opera teams were also studying other browsers' mousemove implementation, discovered the IE5-7 bug and decided to implement it in their latest versions.

Their decision is understandable: it's a fact of life that web developers code with IE as baseline, and therefore other browsers must sometimes copy IE bugs.

Nonetheless, the position switch that IE and Safari/Opera have performed just now is unusual, and things like this shouldn't happen too often.

There are lessons to be drawn here. Although all four browser vendors are paying close attention to each other's implementation, it might make sense to discuss potential improvements before actually implementing them. That won't be easy, certainly not for the IE and Safari teams who're part of large companies that have a history of secrecy, but still it's something to be considered.

Besides, it makes me wonder about the wisdom of copying IE's bugs. After all, now that IE is moving quite close to the standards, the IE team may suddenly decide to solve a bug that has been left untouched for many versions.

Although I'm very happy about the increased communication between the various browser vendors, it seems they should cooperate even closer in order to prevent such odd reversals of position. (And the Safari team should send representatives to interesting browser vendor panels, but that's another story.)

In my previous post I dismissed getClientRects() and getBoundingClientRect() as incomprehensible, but now I understand I should test them with multi-line inline elements. When the methods are used on such elements, they (should) return one rectangle per line.

I rewrote the test page to show absolute elements at the rectangle coordinates, and now it's clear how getClientRects() is supposed to work, and that IE5.5-7 have significant bugs with this method: they report far too many rectangles. (IE8b1 does the right thing, BTW.)

Thanks to John Resig for taking the lead in dissecting a few browser oddities with these methods.

offset

I also retested the offset-related properties, and Travis Leithead of the IE team revealed the cause of Opera's weird negative values for offsetX/Y: Opera's reference point is the top/left of the content block (excluding padding and border), while Safari and Konqueror use the top/left of the element's border.

I summarily judged Opera's implementation Incorrect, because the Safari way seems to be the most logical one. I'm open to counter-arguments, though.

Update: The spec says that the correct reference point is the top/left of the padding-box, which makes sense. Page changed to reflect that.

Update 2: Went through the CSS Table, too. No surprises, except for one minor IE8b1 regression. However, I now count IE's support of its own rules[] array Incorrect for reasons mentioned in the table. This is an old bug.

Furthermore I've taken the opportunity to present the CSS compatibility table better. I split the page into two tables, CSS 2.1 and CSS 3, and I added a few CSS tests. The table below shows the new tests and their browser compatibility.

Update: Added Safari 3.1 Windows information to the main CSS table only.

Finally, a question. Who knows of CSS 3 declarations that don't yet figure in the CSS table but are supported by at least one browser? (Nightlies don't count, but betas do.) Please leave a comment with declaration name and supporting browser. It'll help me get my testing priorities straight.

There's a lot to be said about its CSS and JavaScript support, and I'm going to say it all. My readers, as well as the IE team, expect that.

I'm going to start with a (doubtlessly incomplete) list of regressions: stuff that works in IE7 but not in IE8:

1. <ol> numbering may be wildly and weirdly off; see the Core Table index, for instance.
2. scrollTop and scrollHeight are off (test page). Still have to determine how much off and if there's any rule.
3. :first-line and :first-letter don't work.
4. The attributes[] array doesn't seem to have a length.
5. The cells[] and rows[] nodeLists don't work.
6. letter-spacing doesn't work in this page. (The test is about the tag[customAttribute] selector, which works fine.)
7. Opacity doesn't seem to be supported (unless there's some odd syntax; I tried -ms-opacity, but that doesn't work, either).
8. A really minor one: Some CSS selectors, such as the + selector, should also work when the page content is changed by JavaScript. In IE8 they do, but only after you remove the focus from the link that changed the page content.

Wrapper script problem

Yesterday I went through my tests cases and found the problems listed above. However, in at least one case the problem was caused not by IE8, but by my DOM test page wrapper script (although that problem, in turn, may be caused by IE8, since the wrapper script works fine in all other browsers, including IE5.5, 6 and 7).

When going through the Core table, the first thing I noticed is that insertBefore() didn't work. I couldn't believe that the IE team would overlook a serious bug in such an important method and created a simple test case that was independent of my wrapper script. Result: insertBefore() works fine.

One more thing to take care of. Maybe I've been too smart in creating that wrapper script, although it works fine in all other browsers from 2006 onward.

I retested all of the problems listed above separately, and they're independent of my wrapper script.

New CSS

The IE team wants IE8 to fully support CSS 2.1 . Right now, that means that the following bits of CSS have been added (and I only tested those declarations I have tests for, so this list is definitely incomplete):

1. :before and :after are supported, but you can't specify images, only text.
2. :focus is supported.
3. display: inline-block is fully supported (used to be only on natural inline elements).
4. display: table and friends are supported.
5. list-style support now complete, including the upper-greek value that no other browser supports.
6. outline supported.
7. border-collapse, border-spacing and caption-side supported (test page).
8. white-space fully supported (used to be only two values).
9. box-sizing is supported, but it's -ms-box-sizing.

New JavaScript

John Resig and Erik Arvidsson have already discussed IE8's JavaScript updates in detail, so I won't bother to repeat their lists.

And no, the W3C event model is not supported, and yes, I told the IE team what you think of that omission.

Hope to see you there.

Today's decision reverses that behaviour: without a versioning switch IE8 will behave as IE8, although it will still be possible to switch it to IE7 behaviour, if desired.

Frankly, I hadn't seen this coming. I supported the previous system for two reasons:

1. I didn't (and don't) think that adding a <meta> switch or similar mechanism is such a hardship.
2. It seemed that Microsoft really needed the default-to-IE7 rule in order to allow the Intranets of its corporate clients to continue working undisturbed.

As of right now, the second reason has ceased to exist — and that's the bit that I didn't see coming.

Microsoft has decided to put the interests of web standards above the interests of the Intranets of its corporate clients.

I advise you to read the previous paragraph again. Even two years ago I had never expected to be able to write such a statement.

True, the versioning switch will allow anyone to adapt quickly: just set the switch to turn back the clock, and your website is saved.

Nonetheless, the IE team has done exactly what many standards-aware web developers wanted: it has put the onus on non-standardistas. If you want IE7 behaviour, fine, but you have to take action. If you just want standards and progressive enhancement, do nothing.

Isn't that something? The IE team is listening.

That's no coincidence. This specification contains definitions for many properties (and a few methods) that browsers have already been supporting for ages (such as offsetWidth), and W3C has paid scrupulous attention to the current implementation. No more theorizing into the blue — just check what browsers do and describe it in the specification. Excellent idea.

elementFromPoint

One method deserves special attention: elementFromPoint(). This method expects two coordinates and then reports which HTML element is located at these coordinates. This is a godsend for drag-and-drop scripts. If the user drops an element, get the mouse coordinates and use this method to find out which HTML element is located at these coordinates.

One catch: you first have to temporarily hide the dragged element, because otherwise elementFromPoint() would always report the dragged element — after all it itself is the topmost element under the mouse.

I'm going to add this functionality to my Drag and Drop script, but for the moment this seems to be the idea:

releaseElement: function(e) { // called onmouseup
	var evt = e || window.event;
	dragDrop.draggedObject.style.display = 'none';
	var receiver
		= document.elementFromPoint(evt.clientX,evt.clientY);
	dragDrop.draggedObject.style.display = '';

Now receiver contains the element the user dropped the dragged object on.

Unfortunately the browsers do not entirely agree which mouse coordinates this method needs. IE and FF3 need clientX/Y (relative to the viewport), while Opera and Safari need pageX/Y (relative to the document). I expect Opera and Safari to change their implementation, though; market share considerations leave them no other choice. And the brand-new working draft in fact specifies clientX/Y.

Firefox 2 does not support this method; Firefox 3 does.

Critique of the specification

Despite this specification being an excellent piece of work, I have several light points of critique. None of them is show-stopping, but the specification needs just a little bit more work to move from excellent to outstanding.

WindowView

I have doubts about the WindowView interface, which contains ancient properties such as innerWidth.

The problem is that innerWidth/Height and pageXOffset/pageYOffset are essentially doubles: they report the same information as document.documentElement.clientWidth/Height and document.documentElement.scrollTop/Left: the inner width of the viewport (browser window) and the scrolling offset of the document.

Since we already have that information available, why repeat it? The only reason would be that there might be situations where the documentElement does not span the entire viewport, but as far as I know these situations don't exist nowadays, and frankly I wonder if they'll ever exist.

I created a quick test that gives the root <html> element a wide margin and a border. Clicking outside the border still reports the <html> element as target, and document.documentElement.clientWidth and window.innerWidth report the same number of pixels in all browsers.

So even though the root element may appear to cover only part of the viewport, JavaScript still acts as if it covers the entire viewport. That makes sense: there is no block-level element that contains the root element (or the root element wouldn't be the root element).

The other properties of the window view, outerWidth/Height and screenX/Y, are mostly useless. They've been around since Netscape 3, and in the ten years I've been writing scripts I've never needed to use either of them.

For al these reasons I'm wondering if the WindowView shouldn't be scrapped outright. It just serves no purpose.

pixelDepth

From the Browser Wars on, we've had two proprties that give the color depth of the screen: colorDepth and pixelDepth. The only difference between the two is that IE doesn't support pixelDepth. As far as I'm concerned we do not need two properties that contain exactly the same information, so pixelDepth should be removed from the specification.

The getClientRects() and getBoundingClientRect() methods

I don't understand these methods; or rather, the TextRectangle objects they return. They contain information

about the position of the border box edges of an element relative to the viewport

First of all we don't need this information; finding the position of an element is already possible.

I admit that there's no single property that holds this information; then why not create it? Something like element.viewportOffsetX/Y could be useful, and making this a property instead of a method would be more in line with the rest of the specification. (Should W3C go this way, it should also create an element.documentOffsetX/Y property pair.)

On the other hand, that would mean introducing a new property, and part of the point of this specification seems to be that it describes only properties that have already been implemented.

Finally, it seems that one element can contain several boxes, but I have not been able to find out why or how. In my tests only IE sometimes reports more than one box, anyway.

I feel this part of the specification is not yet ready. At the very least, the relation of TextRectangle boxes to actual elements should be defined in the case there's more than one TextRectangle box, because I don't understand what to expect (and I suspect browser vendors don't, either, because Firefox and Opera never report more than one box, anyway).

Furthermore, I think that the inclusion of these methods should be critically reviewed, since I'm not sure they are useful enough to implement, especially not if their actual meaning is vague.

x and y

The specification also contains all mouse pointer property pairs; an area of JavaScript that featured truly horrible browser incompatibilities even at the time I wrote the book. Fortunately, browsers have sanitised their act, and again the specification pays scrupulous attention to the actual implementation of these property pairs.

The single problem is the x/y property pair. The specification states they must return pageX/Y, but currently they return clientX/Y in all browsers, save Firefox, which doesn't implement x/y at all.

Again, why do we need a second property pair to hold information that's already available? Besides, in this single instance the specification departs from current browser behaviour.

My advice is to remove x/y completely.

Conclusion

Despite these minor points, the current working draft is an excellent piece of work that, I hope, will quickly grow to a fully-fledged recommendation. Browser vendors have to do very little in order to comply with this specification, and we badly needed these definitions.