I'm trying to spec DOM5
HTML, a part of the same specification as HTML5/XHTML5. Specifically,
today I'm trying to specify the various collection interfaces, and in
particular, I'm trying to specify
In IE7, the select element is the same as its options
collection. Literally, it's the same object. (Demo)
In IE7, the namedItem() method of the
object is not equivalent to indexing into the object using the
In Opera9, HTMLOptionElements have a
length property that returns the number of
option elements in their select element. I
can't find any reason for this attribute's existence. No other
browser does this. (Demo)
In Webkit trunk and IE7, if multiple elements match the argument
to HTMLSelectElement.options.namedItem(), then a list is
returned, much like when (in any browser) multiple nodes match
HTMLFormElement.elements.namedItem(). In Firefox trunk
and Opera9, only a single element is returned, not a list, much like
when (in any browser) multiple nodes match
HTMLDocument.images.namedItem(). (The fact that
HTMLDocument.images are both, according to the DOM2 HTML
spec, supposed to be HTMLCollection objects with the
exact same behaviour is, of course, neither here nor there.) (Demo)
In Webkit trunk and Firefox trunk, id and
name attributes on option elements are
considered equals when it comes to matching for
namedItem(). In Opera9 and IE7, only the id
attribute is examined, the name attribute is ignored. (Demo)
In Webkit trunk, setting the length property to a smaller value doesn't remove children of optgroup elements. (Demo)
In IE7, setting the length property to a greater value adds new nodes to the last optgroup element of the select, if there are no option nodes after it. (Otherwise, it does like other browsers, and append them to the select.) (Demo)
The spec is going to be a mix of all of the above, so none of the
browsers are going to exactly match it.
Speccing innerHTML was hard (by which I mean "fun") because despite the fact that every Web browser implements it, none of them agree on exactly what it should do. Which is normal of course when you don't have a spec! I had to come up with rules that are compatible with what browsers do, while being sane for the bits where they differ (none of the browsers exactly match the spec, because I found clear bugs in all of the browsers).
Now I have to work out what to do next.
The problem, of course, is that by specifying things like document.write(), while we hopefully will gain better interoperability and thus less hassles for authors, we symbolically lose the battle for cleanliness in Web authoring. That, of course, is the argument that most of the non-WHATWG-supporting Web standards community keep making: by defining exactly how tag soup should work, we are losing the ability to switch entirely to a clean XML world. Obviously (since I keep working on it!), I'm not really convinced. Authors are using HTML, there's no point pretending they aren't.
Sometimes we lose, but when that happens we have to accept it and hope that we'll have an opportunity to get something better later. That's what I think (and hope!) is happening.
Thankfully, there's at least some hope that myself (and the more than eighty contributors to the HTML5 spec so far) have the agreement of a wider community — several browsers are implementing some of the various proposals, and someofthe things to come out of the WHATWG have now ended up on the W3C TR page.
That this would happen so fast was unthinkable when we started it all.
I will be away for the next three weeks, mostly without internet access. (In fact, mostly without even running water.)
Hopefully by the time I get back XBL2 and CSS2.1 will have been published as Last Call and Candidate Recommendation drafts respectively.
I've unsubscribed from a bunch of mailing lists and disabled mail from a bunch of bug systems, so if there's anything you want me to see, forward it to me. I doubt I'll look at anything but mail sent directly to me and a few key lists (like the WHATWG list) when I get back.