Last night around 2am a big long fire truck parked silently next to my tower block. After a few minutes the three firemen got the ladder out and one climbed up to the third floor of the apartment complex opposite. Then after a good five, ten minutes, during which no fire was seen, no cats meowed, and no maidens were rescued, the ladder was brought down, the two firemen climbed back into their truck and the truck drove off.
Wait, two?
What happened to the other one?!
Explanations on a postcard to Ian Hickson, 1600 Amphitheatre Parkway, Mountain View, CA 94043.
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
HTMLOptionsCollection
.
The
DOM2 HTML spec's take on the matter is somewhat far from the
truth.
Here are some amusing tidbits I've found so far:
- 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
HTMLOptionsCollection
/HTMLSelectElement
object is not equivalent to indexing into the object using the
JavaScript square-bracket notation. (Demo)
- In Opera9,
HTMLOptionElement
s 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
HTMLFormElement.elements
and
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.
2006-10-02 06:52 UTC
Real sacrifices (and some notes on what I've been up to)
Over the last few weeks I've finished several key parts of the HTML5 specification, most notably innerHTML
for HTML elements, document.write()
in HTML documents, the new datagrid
element, and the drag and drop APIs.
Yay! This makes me happy.
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 some of the 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.
2006-09-23 00:03 UTC
Tag Soup: innerHTML interoperability (or lack thereof)
I wrote a "simple" test.
I then tested five browsers: IE7b3, Firefox (20060921 trunk), Safari (2.0.4 and Webkit Fri Sep 22 14:05:47 GMT 2006), and Opera 9.
I got five different results.
- IE
- Firefox
-
- Safari (latest released version)
-
- Safari (Webkit nightly build)
-
- Opera
-
Meep.
Pingbacks:
1
2