Hixie's Natural Log

2006-11-10 01:30 UTC Investing in the Fruit Company

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.

2006-10-28 22:16 UTC Fire truck

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.

2006-10-17 21:43 UTC The DOM0 Legacy: document.title

I'm trying to specify document.title. Here's a list of quirks and outright bugs that I have found so far:

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.
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.

2006-10-16 23:52 UTC The DOM0 Legacy: HTMLOptionsElement

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:

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.