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