How times have changed. Years ago, I teased Hyatt for his decision to work for Apple (on what people later found out was Safari). Today, I have a Mac Mini as my alarm clock (and as the back end for my model railway control panel), an Apple Cinema Display as my entertainment center, a Powerbook as my main laptop, and I pour tons of cash down mouth of the iTunes Store every month in order to stay up to date with all my favourite TV shows. When I'm in San Francisco, I feel compelled to visit the Apple store. Of all the stores I went to in Zurich, the first one was an Apple store. I watch Apple keynotes like a cult member. My presentations are done using iWork.
Today, I added to my collection; FedEx delivered me my new shiny black 80GB portable hard disk (with colour screen). I believe the term used for these hard disks is "iPod".
I've long been skeptical of the idea of watching TV on the tiny iPod screen, but I have to say, it's not that bad, especially for watching things like Strong Bad's e-mails. I'm not saying I'd watch Stargate on my iPod, but still.
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 specify document.title. Here's
a list of quirks and outright bugs that I have found so far:
IE7
title elements created by the parser don't have child
nodes, but you can see their value in the innerHTML
serialisation. (DOM-created title elements do have
child nodes, however.)
Adding a title element via the DOM has no effect on
document.title.
The first title element that is parsed by the parser
is associated with document.title. If there is already
such a node, then the new one is ignored by the parser.
Changing document.title changes the innerHTML of the
associated title element, potentially creating one at
the start of the head element if required.
Trying to append a child text node to the magic title
element results in an exception being raised: "Unexpected call to
method or property access".
Trying to change the magic title element's
innerHTML gives an "Unknown runtime error".
Firefox trunk
Setting document.title doesn't affect the DOM, and is
sticky; further changes to the DOM no longer affect
document.title.
The first title element that the parser sees sets the
document.title value to the element's
textContent.
Safari trunk
If a title element is inserted into the DOM, it is
associated with document.title, unless another node is
already associated with it.
If the associated title element is removed from the
document, it loses its association.
Setting document.title directly doesn't affect the DOM
but sets an override that causes further accesses of that attribute
to return the set value, until the set value is forgotten.
Appending things to the associated title element works
per the DOM, and causes any override setting of the
document.title to be forgotten.
Setting a title element's innerHTML
attribute rasises a NO_MODIFICATION_ALLOWED_ERR
exception.
Getting document.title returns the concatenation of
all the text node children of the associated title
element, unless an override is in effect, in which case that is
returned instead.
Opera9
In the parser, a title start tag doesn't imply a
head start tag, nor do title tags in the
body end up as elements in the head.
Parsed title elements always have a text node child,
even when that node is empty.
Setting document.title when there's no
title element in the DOM does nothing, otherwise it
deletes all the child nodes of the first title element
in the DOM and then (if it wasn't set to the empty string) appends
a single text node containing the new value.
Getting document.title returns the text of the first
node (if it's a text node) of the first title element
in the document (if there is one).
You can append a title element (or indeed any element)
to the Document node, such that the document has more
than one root node.
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.
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, 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
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.
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.