Hixie's Natural Log

2004-05-28 17:16 UTC Spring 2004 Travelog: Part 2 (Backwards Compatibility)

The CSS working group meeting is now over, and so I've now flown over to the bay area for the workshop. I'm staying at dbaron's, who kindly offered to let me use his couch. We have both been asked to give short presentations at the workshop next week, so I've been thinking about some things to help underscore our point about how backwards compatibility is a requirement, at least for solutions that are to come in the near future.

I think the best way to explain it is to use examples.


Look around the Web. What parts of CSS2 are used? (Not counting those that were already in CSS1.)

The answer is "absolute positioning". Pretty much none of the other new features from CSS2 are used. Why? Because of those new features, pretty much only absolute positioning is supported by Windows IE6.

Many sites still use HTML table elements for layout. Why? Because the CSS2 table model isn't supported by Windows IE6. Authors often ask how to do things like fixed positioning, but lose interest when they are told Windows IE6 does not support them.


Many pages on the Web claim to be XHTML (according to their DOCTYPE) but they are almost all sent as text/html instead of the more correct application/xhtml+xml, despite all browsers except Windows IE6 supporting the latter.


Authors use PNG. Authors don't often use PNGs with eight bit alpha channels. Windows IE6 only supports PNG that don't have eight bit alpha channels. Authors frequently ask how to use semi-transparent bitmaps with their site designs, but again lose interest when told that Windows IE6 won't render them correctly.

Flash is frequently used on the Web

Windows IE6 ships with a binary plugin for rendering Macromedia Flash files. Flash is very widely used on the Web, especially for application-like content, in particular games and interactive multimedia.

SVG is rarely used on the Web

Windows IE6 does not ship with a binary plugin for rendering SVG files, although one is available at no cost. SVG is rarely used on the Web, at least compared to Flash.

Non-standard features

Many pages depend on features that aren't in the specs, but are implemented in IE, despite the features being available in the specs using other methods, and despite those other methods being implemented in IE. For example, document.all is used all over the place despite its standards-compliant equivalent getElementById being implemented in Windows IE6.

Similarly many pages use offsetTop, innerHTML, and the like, which has forced other browser vendors to implement support for those features.

I think these examples demonstrate quite strongly the need for any successful solution to be one that can be deployed in Windows IE6. Adding new functionality to Windows IE6 without using binary plugins is quite possible, as demonstrated by the quite impressive IE7 project.

The long term solution would be to move users from the dead IE platform and the proprietary Windows platform to the actively developed, open, and standards-based alternatives. Once users are using products with (relatively) rapid update cycles, it will be possible to introduce more radical new technologies, and expect to see them adopted by authors.

However, moving users to a different platform is an entirely different problem than providing authors with new technologies. Users use Windows because vendors use Windows as their default operating system. Users use Windows IE6 because Windows uses IE6 as its default Web browser. Very few users ever change either of these, much like very few users ever change their preferences, mostly because they simply are not aware that the alternatives exist.

Therefore before we can create a long term solution for authors developing Web applications we need operating system manufacturers and Web browser manufacturers to significantly step up their marketing campaigns and significantly increase the effectiveness of their lobbying of vendors. Until that happens, there is not much point inventing new languages, since they won't be used in the near future, and will probably no longer be adequate when they can be.

However, in the meantime, authors still want to write Web applications, and the currently deployed standards are inadequate. Since completely new standards won't cut it (as discussed above); this leaves us with the solution we (Opera and Mozilla) have been advocating: updating HTML and the DOM.

Pingbacks: 1 2 3

2004-05-23 17:31 UTC Spring 2004 Travelog: Part 1 (Whining)

It's that time of year again. The quarterly trip. This time I'm going first to Boston for the May 2004 CSS working group face-to-face, and then on to the bay area to eat Grandma's Especial and (probably more to the point) to attend a workshop on Web Applications and Compound Document.

A pretty standard trip: an SAS flight from Oslo to London Heathrow on a 737-800 (with, as most of the SAS fleet, a small poem-like writing at the entrance: On a round planet, / your destination / will always / bring you home) followed by the normal paperwork at Heathrow before boarding the 777 to take me to Boston.

Heathrow is such a mess. Seriously. Imagine one of those science fiction movies where the city is dark and bustling with non-descript industrial activity: things barely working due to a long slide into disrepair, kept working by patching as little as possible, as cheaply as possible. Corridors lead nowhere; derelict equipment lies unused in passenger waiting lounges; "temporary" structures have become part of some of the permanent structures; toilets are concealed behind load bearing columns that look as if they were added as an afterthought during construction (or even later) when the building threatened to collapse (mind you, given recent events, I suppose that could be worse); signs clarify other signs; the public announcement system regularly informs passengers that everyone else in the terminal is intent on stealing their baggage, or maybe giving some to them, and that one must thus be vilgilant at all times... When we landed we had to actually step onto the runway to get into the terminal because for some reason our gate had no extending arm thingy.

It continuously amazes me how the British can have such an obsession with doing things cheaply. "Maintenance", in the UK, seems to mean "repair", not "preventing failure". Things that are functional are good enough. There was a television screen at our gate, showing BBC News 24's coverage of some royal wedding or other. It was a pretty good quality large widescreen plasma display with a pseudo-surround-sound system. But of course the picture was delivered via analogue cable, in 4:3 ratio and stretched to fit the 16:9 frame, an affront to the televison's abilities (and to BBC News 24's producers, since they have been broadcasting in 16:9 for years). Anywhere else, the technicians would have refused to even install such a system; a plasma TV needs a digital feed, not coax. In Britain? Coax is cheaper.

While I'm whining, I think I'll transition smoothly to a critique of Along Came Poly, one of the films we were provided with on the American Airlines entertainment system. A mediocre movie, which could have been saved by featuring more of one of the characters, a ferret, but which unfortunately utterly failed to use even a fraction of its potential.

First of all, I must emphatically point out that ferrets do not sound like squeaky toys. They are in fact largely silent. It's one of the features that makes them look so innocent and mischievous at the same time. They make a sound when you step on them or drop them (a kind of indignant "epp epp epp!") and occasionally let out muted cries while fighting, but that's it.

Secondly they never stand still (except when they're looking at you waiting for you to either feed them or play with them). If you put a ferret in a harness on a leash and attach the leash to the door handle, one of three things will happen within about twenty seconds. First, and most likely, the ferret will somehow manage to get the leash off the door handle and start exploring the surroundings, especially any dark and inaccessible places. Second, less likely but still quite common, the ferret will magically get out of its harness and again start exploring. Don't ask how they manage to get out of their harness. It is a perennial mystery. I'm not a ferret expert but my understanding is that the leading theory is that they possess short range teleporting technology of some sort. The third possibility is that the ferret will begin exploring with the leash still attached to the door handle, and, through climbing atop nearby boxes or through nearby pipes, will manage to either entangle itself in a knot that will take significant effort to undo, or will slip and end up dangling in mid air. (I'm sure more ferrets get killed by curiosity than cats.)

What will never happen is them just standing there patiently waiting for whatever humans have in mind for them. So you would never find a ferret sitting in the middle of a hallway.

Thirdly, ferrets don't run into walls. They run along walls. If they find a wall, they run towards it then follow it to find out where it leads. They follow walls almost as religiously as they explore holes.

And finally, ferrets sleep. As far as I can tell most ferrets spend no more than thirty minutes awake per day. No movie that purports to show someone, whose first guess when he sees a ferret is to think it is a rat, dating a ferret feeder (you don't own ferrets anymore than you would own a cat), could possibly omit the line "do these things do anything but sleep?". Well, I mean, obviously it could, since this one did, but such an omission would always be a major error.

I arrived in Boston having read about half of Peter F. Hamilton's latest book, Pandora's Star. This is a nearly 900 page book, part one of the Commonwealth Saga. I absolutely loved his first saga, the Night's Dawn Trilogy. So far this book is promising to be just as good.

Getting to Boston itself from the airport was quite easy, due to convenient public transport. Unfortunately, Boston reminds me of Heathrow. It's American, of course, so it's on a bigger scale. But it has all the same features of looking temporary. A few months ago I heard that The Big Dig was complete, but it seems that they forgot to let the crew know.

I went for a long two and a half hour walk around the city to see what it was like. One of the most confusing things I came across was a couple of big old iron pipes coming out of the ground and spewing dirty steam. Why would there be steam underground? And why would you want to release it all over the place?

For dinner, I had a burrito. Europeans don't know how to make burritos. They try to serve them on a plate with garnishes, or with the rice on the outside, or with sauce poured over the burrito. That would be like serving a ploughman's lunch as individual parts around a plate (mind you, I've had that done too). Burritos should be self-contained. Just one big lump of goodness filling a leak-proof yet edible wrapper.

It was a good burrito.

The next day, today, I woke up refreshed, watched Finding Nemo on TV (Pixar rocks), then walked around Boston some more. Some of us working group type people are planning to meet for dinner tonight. In the meantime I think I'll sit down at Boston Common and read my book.

2004-05-20 12:39 UTC Web Applications and Compound Documents, IMHO

The W3C is having a workshop on the topic of Web Applications and Compound Documents in a few weeks, which I will be attending. It looks like it could be fun.

Everyone who wants to attend had to write a position paper. We (Opera) got together with our Mozilla friends to write ours — you can see our position paper on the position papers page.

It was interesting to compare the papers that were submitted. A large number of them suggested that the best basis for Web applications was SVG, many of the others suggested XForms.

Our own position was that any successful framework would have to be backwards compatible with the existing Web content, and would have to be largely implementable in Windows IE6 without using binary plug-ins (for example using scripted HTCs). We were the only ones to even remotely suggest that the solution should be based on HTML.

It is going to be very interesting to see how this unfolds. For us (the Web browser vendors: Opera, Mozilla, and Apple), the "backwards compatible" requirement is not really negotiable, because it is quite clear that solutions that don't work in the market leader's browser won't be accepted by mainstream Web developers. I think a lot of people in the W3C world are having difficulty accepting this, especially given that Microsoft have basically said that IE has been end-of-lined (it is my understanding that IE in the next version of Windows will have no changes to its HTML/CSS/DOM/XML implementations and still no support for XHTML, and Microsoft have also stated that there will be no new separately-downloadable versions of IE available anyway, so even if they did upgrade it, it would only be used by those who upgraded their operating system).

It's almost sad, in a way. I was in a W3C meeting yesterday where one of the participants said, in response to "well we have to be backwards compatible with IE on this", something along the lines of "what? I thought we could ignore IE now that Microsoft have said it will no longer be developed".

Another theme I noticed in some of the other position papers was the suggestion that the way to handle mobile devices (phones, PDAs) was to make "mobile profiles": smaller versions of the specifications that mobile vendors would implement in their devices.

This strikes me as rather fundamentally missing the point. All these technologies are supposed to be device-independent, so if they aren't suitable for mobile devices, the problem is with the technology itself, not with the lack of a profile. Having a profile merely results in a fragmentation of the Web — instead of simply writing a Web document or application once and having it run everywhere, it requires that authors decide what devices they are going to target, and limits them to the features those devices are supposed to support, or requires that they write several different versions.

Opera is one of the few vendors to have a single solution that it deploys across both the desktop world and the mobile world — if something works in Opera on the desktop, then it will almost certainly work in equivalent versions of Opera on small devices. (The "equivalent versions" bit is unfortunately more relevant than one might first think. The desktop version's rendering engine has in the past been several versions ahead of the version usually used by devices. We're working to reduce that gap, though.)

Having a single solution obviously means that we're always concerned with implementability. If we can't fit the implementation for a technology into our devices, then we won't implement it on the desktop either. This was one of our major complaints about XForms — it has so many dependencies (e.g. XPath) and reuses so few of the technologies we already implement (e.g. JavaScript, HTML) that we simply couldn't fit an implementation of XForms into our browser while still being able to browse the Web.

Something else that we (Opera and Mozilla) mentioned in our position paper was that we thought the development process for Web application technologies ought to be completely open. Mozilla obviously want this because they live in the Free software world, where everything is done in the open, and where that policy has reaped them many benefits (in fact the only other position paper to mention that the process should be open was RedHat's, presumably for the same reason). As far as Opera goes, we want an open process because our experience with the Web Forms 2 work I've been doing is that developing core Web technologies in the open is far more productive than creating the technologies mostly behind closed doors, getting input from the real world only every few weeks or months.

In my opinion, the way to go for Web applications is the creation of a public mailing list dedicated to the creation of extensions to HTML and the DOM that address the needs of Web authors, and to have someone edit a spec that brings the ideas that are discussed together. A good start for this would be the Web Forms 2 and Server Sent Events specs I've been writing.

My prediction: after the workshop, the W3C will set up a working group to address Web applications. Their charter will be to create two profiles that specify which parts of SVG and XForms should be implemented and used on desktop computers and on mobile devices. There will be a number of implementations from plug-in vendors, as well as several standalone browsers that can host applications written to these profiles. Books will be written, several industries will announce their commitment to this technology, and a couple of companies will be founded based around the business model of supporting the technology in some way (e.g. providing authoring tools, selling Web application browsers, or creating customised software to convert applications written using these profiles to HTML+JS that can be displayed in IE6). About ten years from now, the de facto Web application standard will be Microsoft's Avalon and the .NET framework. (See Microsoft's position paper if you doubt that this is what Microsoft has planned for us.)

I have other plans.

Pingbacks: 1

2004-04-28 15:45 UTC Server-sent DOM events

Someone suggested to me recently that it would be quite cool if there was a way in which servers could dispatch DOM events straight into a Web page so that script in the page could then react to them, updating the page and so forth.

At the moment pages fake this by opening an iframe to a page that the server keeps open, slowly trickling script blocks into it, and having the browser execute them as it finds them.

This is pretty ugly, but it works. So here is a proposal for a cleaner, declarative way to do this.

To specify an event source in an HTML document authors use a new (empty) element event-source, with an attribute src="" that takes a URI to open as a stream and, if the data found at that URI is of the appropriate type, treat as an event source.

The event stream MIME type is application/x-dom-event-stream.

The event stream is always be encoded as UTF-8. Line are always be terminated by a single U+000A line feed character.

The event stream format is (in pseudo-BNF):

<stream>  ::= <event>*
<event>   ::= [ <comment> | <field> ]+ <newline>
<comment> ::= ';' <data> <newline>
<field>   ::= <name> [ ':' <space>? <data> ]? <newline>
<name>    ::= one or more UNICODE characters other than ':' and U+000A
<data>    ::= zero or more UNICODE characters other than U+000A
<space>   ::= a single U+0020 character (' ')
<newline> ::= a single U+000A character

The stream is parsed by reading everything line by line, in blocks separated by blank lines (blank lines are those consisting of just a single lone line feed character). Comment lines (those starting with the character ';' not proceeded by any other characters) are ignored.

For each non-blank, non-comment line, the field name is first taken. This is everything on the line up to but not including the first colon (':') or the line feed, whichever comes first. Then, if there was a colon, the data for that line is taken. This is everything after the colon, ignoring a single space after the colon if there is one, up to the end of the line. If there was no colon the data is the empty string.


Field name: Field data
This is a blank field
1. These two lines: have the same data
2. These two lines:have the same data
1. But these two lines:  do not
2. But these two lines: do not

If a field name occurs multiple times, the data values for those lines are concatenated with a newline between them.

For example, the following:

Test: Line 1
Foo:  Bar
Test: Line 2

...is treated as having two fields, one called Test with the value Line 1\nLine 2 (where \n represents a newline), and one called Foo with the value Bar.

(Since any random stream of characters matches the above format, there is no need to define any error handling.)

Once the fields have been parsed, they are interpreted as follows (these are case sensitive exact comparisons):

Once a blank line is reached, an event of the appropriate type is synthesized and dispatched to the appropriate node as described by the fields above. No event is dispatched until a blank line has been received.

The RemoteEvent interface is defined as follows:

interface RemoteEvent : Event {
  readonly attribute DOMString       data;
  void               initRemoteEvent(in DOMString typeArg,
                                     in boolean canBubbleArg,
                                     in boolean cancelableArg,
                                     in DOMString dataArg);
  void               initRemoteEventNS(in DOMString namespaceURI,
                                       in DOMString type,
                                       in boolean canBubbleArg,
                                       in boolean cancelableArg,
                                       in DOMString dataArg);

Events that use the RemoteEvent interface never have any default action associated with them.

The event-source element may also have an onevent="" attribute. If present, the attribute is treated as script representing an event handler registered as non-capture listener of events with name event and the namespace uuid:755e2d2d-a836-4539-83f4-16b51156341f or null, that are targetted at or bubble through the element.

The following event description, once followed by a blank line:

Event: stock change
data: YHOO
data: -2
data: 10

...would cause an event stock change with the interface RemoteEvent to be dispatched on the event-source element, which would then bubble up the DOM, and whose data attribute would contain the string YHOO\n-2\n10 (where \n again represents a newline).

This could be used as follows:

<event-source src="http://stocks.example.com/ticker.php" id="stock">
<script type="text/javascript">
document.getElementById('stock').addEventListener('stock change',
  function () {
    var data = event.data.split(' ');
    updateStocks(data[0], data[1], data[2]);
  }, false);

...where updateStocks is a function defined as:

function updateStocks(symbol, delta, value) { ... }

...or some such.

What do you think? Let me know.

Pingbacks: 1

2004-04-12 19:27 UTC Embedding flash without <embed>

I've never written any Flash content, or, as far as I can recall, ever used Flash on any of my sites, and I don't even have the Flash plug-in installed here, since Flash is a proprietary language and thus inherently evil and should never be sent over the wire, but, someone asked how to get around the fact that embed is not a valid element in HTML4 Strict, given that tutorials always encourage people to use one object element for IE and then a nested embed element for everything else, so I wrote a sample page to do just that.

Pingbacks: 1 2 3 4 5