Hixie's Natural Log

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

2004-04-11 21:12 UTC Sunny newspaper clipping

I was reading Google News earlier today...

... "See loads more girls on our super cyber site" The Sun, 7 hours ago. "A white house memo released today has revealed that US President George Bush was warned about a possible hijacking plot inside America more than a month before September 11 2001." ... "The selection and placement of stories on this page were determined automatically by a computer program."

No comment.

Pingbacks: 1

2004-04-06 16:41 UTC Ow

Today we went skiing.

Tomorrow we will be actively not doing anything.