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-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-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-28 19:14 UTC Spring 2004 Travelog: Part 3 (Poker)

Yesterday I was dealt my first hand of poker. An interesting game. Should be easy to write a decent Web-based version. I wonder how easy it would be to write an artificial player.

Today, we are going to be playing Monopoly, with our all-deals-allowed rules. Loans. Insurance. Shared rent agreements. I can't wait. (I always lose, but that's not the point.) I've already written an Internet-based version of Monopoly.

Yesterday I saw Miracle, today I'm probably going to see Soul Plane.

Earlier today I also went to Fry's Electronics in Palo Alto to see if they had a Linux-based PDA. They didn't, unfortunately.

Now I'm off to La Fiesta for lunch. Grandma's Especial Enchiladas.

As you can see I'm working really hard here.

2004-05-29 08:41 UTC Spring 2004 Travelog: Part 4 (Monopoly)

I managed to convince Pavlov to see The Day After Tomorrow instead of Soul Plane. It was pretty good. I was quite impressed with the CG — nearly every shot had them. (After listening to lots of SG-1 audio commentaries, I appreciate effects a lot more.)

I had a Grandma's Especial with flour tortillas for lunch, and we just got back from another run to Burrito Real for dinner. I'm getting my year's fill of Mexican food all at once in this trip, I think.

We spent the evening playing Monopoly. The first proper game for 3 years! You can see the results on our results page (it's the 2004-05-28 game).

I have no idea what we're going to be doing this weekend, but I think it'll involve some sleeping, given the length of this game.

2004-05-30 17:02 UTC Spring 2004 Travelog: Part 5 (Lick Observatory)

The weekend. David had bought himself a Linksys wireless router when we went to Fry's on Friday, and on Saturday he installed it. It was disappointingly easy. Where's the fun if things Just Work? (Actually it turns out it didn't Just Work; the ethernet ports were broken.)

In the afternoon Ben, Kerz, David and I went up to the Lick Observatory on Mount Hamilton. It was a really nice ride with some great views of the valley. I hadn't realised quite how much smog there was here. It's rather scary. I don't remember seeing smog back in Norway.

We were given a nice talk by one of the amateur astronomers lucky enough to get himself a job at the observatory, and then drove back home. On the way, Ben was annoyed by a Toyota driver who was weaving all over his lane.

Yesterday evening David and I went to Andale Taqueria in Palo Alto. I had a small chicken taco. It was good. Today I'm planning to go to San Francisco to meet Bloo and see Shrek 2. Ought to be fun.

The agenda for the workshop is now available. Looks like David and I are going to give a joint presentation tuesday afternoon. We're right before Microsoft, which could be interesting.

I'm very much at a loss as to what to expect from this workshop. On the one hand I really can't see us convincing everyone else that the solution is to continue down the HTML path. After all, it's not in the interests of most of the other attendees. Many of them are wanting to sell SVG, XForms, or XHTML products, and most of those who aren't are probably more concerned with developing a good theoretical solution than addressing the unfortunate pragmatic needs of today's authors.

I guess this is a case of "wait and see".

2004-05-31 08:15 UTC Spring 2004 Travelog: Part 6 (San Francisco)

Sunday: I saw Shrek 2 (which was great, I highly recommend it!) at the Metreon with bloo, Pavlov, and dbaron, then I went to The Cheesecake Factory in San Francisco with them and Nadia. The food was reasonable, although a little excessive in terms of volume; and the smoothies were very nice.

After ditching bloo we then went back to Nadia's and Kevin's (who appears to not have a URI) to play DDR. I sucked. Pav and dbaron were a bit better. Nadia and Kevin have quite clearly practiced this a lot and were quite impressively coordinated, which was scary.

Before Shrek 2 we saw the trailer for the next Pixar movie The Incredibles, which I can't wait to see (November!), and the next Dreamworks Animations movie, Shark Tale, which also looked great.

Tomorrow afternoon we're probably going to go see Soul Plane since Pavlov is really set on seeing it.

In between all these good times I've also been doing some work on the CSS2.1 test suite, converting the CSS1 tests to the new format (more on that later when I've finished doing it). I'm getting there — only 28 more tests to convert!

2004-06-01 01:12 UTC Spring 2004 Travelog: Part 7 (Notes for the Workshop)

I've been reading through some of the position papers putting together some notes for the workshop tomorrow.

Applications and documents are distinct

Why are they distinct? Microsoft Word documents can be used as applications. Interactive encyclopedia multimedia applications can be viewed as documents. Spreadsheets have long been both simultaneously. Help systems now are able to interact with the user and control other applications to help them along, but are clearly still documentation.

In fact I would posit that users do not really understand the difference between "applications" and "documents" at this stage, and I would argue that they need not.

We need a virtual machine that is defined using declarative mark-up, rather than any particular language

How much is in the meta-language? Would you describe SVG in this language? Would you describe CSS in this language? XPath? XML Schema? XML itself? DOM?

Would this be able to describe XHTML2? XForms? What about XForms' custom XPath functions?

How is this better than XBL?

It also seems that this would encourage a much wider range of languages to be delivered over the Web, breaking the principle that the number of Web formats should be limited, which is important for accessibility.

Presently, three incompatible forms specs (Adobe eForms, Microsoft's Infopath, W3C's XForms) are out in public view, yet none are supported by assistive technology

What about HTML4 forms?

Scripting is bad for accessibility

It is not scripting that is inherently bad for accessibility, it is device-specific APIs that are bad for accessibility. Any technology that makes device-specific solutions easier than device-independent ones will result in poor accessibility, as authors use the simplest solutions.

With this in mind, the best solution might just be to redefine parts of the existing scripting APIs to be device independent. For example, redefine onclick to trigger whenever an element is activated, not just when it is clicked.

We need profiles for mobile devices

If desktop and mobile units have different profiles, then mobile units will not be able to view all the content aimed at desktops (as most content is). It seems that in fact device independence would be far better for mobile users than device-specific profiles.

SVG is the answer

SVG (or rather a drastically simplified version) is a possible solution for the vector graphics requirements of an overall Web Applications technology.

However, it would in my opinion be a bad solution for the core technology. SVG is poor in terms of accessibility and semantics. For example, how do you mark a part of an SVG application as an ordered list? As a paragraph or header? As a dialog box or tabbing control?

SVG is also much less suited for styling. For example, it is not possible, with SVG, to do the radical changes in appearance as seen in the CSS Zen Garden. The ability to do this (without changing the markup) is an important part of the Web.

XForms is the answer

XForms is not backwards compatible.

I'll probably be making some of these points during the questions part of the other presentations.

The more I read the position papers that are going to be presented, the more I wonder at exactly what is going to come out of this workshop.

2004-06-02 06:48 UTC Spring 2004 Travelog: Part 8 (First Day of the Workshop)

Today I listened to a good dozen presentations from various groups on the subject of Web Applications and Compound Documents.

Some interesting things came out. First, the only sustained spontaneous clapping of the entire day came as someone suggested, in response to my brief statement of how backwards compatibility is critical, that it was about time to drop HTML and Windows IE6 from the roadmap.

So I can assume from that that most people don't agree with the whole backwards-compatibility thing!

Second: I was quite amused to see that, of all companies, Microsoft, Red Hat, and Sun Microsystems actually agreed on something. Namely that trying to standardise an API for sophisticated applications is simply a non-starter. The argument, which I agree with, is that such APIs are simply insanely complicated, and that making interoperable implementations is nigh on impossible. Just look at the trouble WINE has had trying to implement Win32 again — now imagine if you had to write a spec to actually describe the entire Win32 API in terms that could actually be implemented interoperably without reverse engineering the first implementation as the WINE people do.

What was funny was watching the other people then disagree with them. Hint: If three of the most bitter rivals in the marketplace — all of whom have extensive experience in the subject in question — agree on something, then it is probably true.

What we (Opera and Mozilla) want to do is simply extend HTML, DOM, and CSS a bit so that the most common things are easier to do. Things like my Web Forms 2 proposal or my server sent events proposal. These are simple extensions, not an attempt to provide comprehensive platform APIs.

Another point that came out of the discussions is that, in case there was any doubt, Internet Explorer in Longhorn will not support XHTML or SVG. (Microsoft suggested they would need some significantly more comprehensive test suites before they started working on standards compliance again.)

After the meeting, a bunch of us had dinner at La Fiesta. Our table had three Microsoft employees, two Red Hat employees, two Mozilla Foundation employees, and an Opera Software employee. I bet you won't see that very often.

Tomorrow we have another dozen presentations. I expect to see more of the same; mostly people expounding on the virtues of XForms, SVG, XHTML2, or their own radically new proprietary technologies, and explaining how Web Applications would all be much better off if the W3C would go down their chosen route.

We, of course, want the W3C to go down our chosen route. Since there doesn't seem to be much consensus on doing that, though, the question is what should we do now? Should we do our own thing (in public of course) and then submit it to the W3C (or IETF or ECMA) at some future point once we have initial implementations? Should we simply do our own thing (Opera, Mozilla, and a few interested parties) and forget standardisation altogether? Should we just take part in whatever Web Applications working group the W3C sets up and implement whatever comes out of that in several years' time, despite being fully aware that few people will ever use it? (Which is a foregone conclusion since it wouldn't work in Windows IE6.)

I'm learning towards the first of the three at the moment. I guess the Opera and Mozilla people will have to discuss this in more detail before we decide anything though.

2004-06-04 22:20 UTC Spring 2004 Travelog: Part 9 (Return to Europe)

Travelling east is painful. I woke up around 05:40 on Thursday, and went to bed around 15:00 on Friday, nine time zones away. My brain now thinks that 23:00 is a good waking time. Also, it meant I had three breakfasts yesterday, which successfully smashed my fast so that I wasn't hungry even though I should have been. Quite the biological clock confusion.

The second day of the workshop had more discussion. We had some straw polls; of the 40 or so people there, around 8 said they wanted to work on the work Opera and Mozilla have been proposing recently, and about 11 said that not only did they not think it would be worth working on this, but they actively thought that the W3C should not work on it.

In my opinion that's pretty short-sighted, but as Steven Pemberton pointed out, six year ago, the W3C decided that HTML was dead, and the way forward was a host of new languages (what is now XHTML2, XForms, MathML, SVG) that would lead the world's population to a clean new world. So at least they are consistent.

Of course I had to point out that six years ago, I was in school, which got a good laugh. My point, though, was that times change. In the last six years we have seen that authors simply didn't agree: Mozilla has supported MathML for years, but it is still very rare to see any MathML content on the Web. Mozilla, Opera and Safari all support XHTML1, in fact Mozilla has supported XHTML1 since before it had an assigned namespace and MIME type, but again the amount of application/xhtml+xml content on the Web is trivial.

The truth is that the real Web, the Web that authors write for, is the Windows IE6 Web. The only way to change that is to reduce the IE6 market share, and new technologies don't do this. Marketing does. Once users are primarily using a browser that is being regularly updated, then we can start introducing radically new technologies. Until then, such technologies simply aren't going to become popular.

There were a lot of rather confused statements during the meeting. For example, it is clear that a lot of people think that the browser is dead and that the way forward is transparent "runtimes" that execute remote applications securely. But then these same people demand to know why Mozilla, Opera and Safari don't support XForms and SVG, saying that their lack of support is crippling their standards' adoption.

Surely if the browser paradigm is dead, it doesn't matter what we implement?

What I think most of the people at the meeting actually want is a standard that combines XHTML, XForms, SVG, and SMIL (and CSS, DOM, and ECMAScript, although they rarely if ever actually mention those by name), and then adds enough APIs to make the host into a platform in its own right.

Java tried the "provide lots of APIs that are interoperable across lots of platforms" and failed. Some people thought this was because Java, as a language, is too complex for most applications. And Java doesn't have a detailed spec (not detailed enough to write an interoperable implementation accurate to the level that is needed for applications).

The detailed spec problem is the big issue. There has simply never been a Web specification written in enough detail for this kind of work. Even "DHTML", which does just a fraction of the number of APIs needed for the kinds of applications these people are imagining, is completely inadequately specified. For example, if you have an object element followed by a script block, will the script execute before or after the object has loaded? This is the kind of behaviour that scripts depend on. (Answer: In IE, the script will block waiting for the object, and if the object doesn't load, it will be removed from the DOM. The exact behaviour depends on the extension of the filename in the data attribute and the local computer's registry. Feel free to explore this yourself using these testcases...)

Making these specs more detailed is the work that Opera and Mozilla want to do. But to do this for a sophisticated application platform on par with, say, Longhorn, is simply unfeasible. Notice how WINE has to reverse engineer Windows to determine how it should work. Or how the various Java clones have to reverse engineer Sun's Java to get interoperability.

Of course, if they want to do this, I wish them the best of luck. I might even want to participate in the working group, since someone will have to look out for the Opera and Mozilla interests!

Sadly there does seem to be a growing opinion in certain circles that the W3C is becoming more and more out of touch with the Web. In many ways, this makes sense: the membership has many more server-side people than client-side people, and most of the client-side people are plug-in vendors, not browser vendors. (All the browser vendors present at the meeting were in favour of variants on the Opera/Mozilla ideas, but they were easily out-numbered by the non-browser members.) Since most people consider "the Web" to be what browsers show, it's only natural for an organisation of people who are largely not doing Web browser work to appear to be "out of touch".

Really it's not that the W3C is out of touch with the Web, but that the W3C membership is solving problems that every day Web users don't see. For example things like CC/PP and SOAP are very much back-end technologies.

I've also heard a lot of comments recently from people asking if the SVG working group realises that SVG 1.2 is becoming a dumping ground for anything and everything, instead of remaining just a graphics language. For example, SVG 1.2 drafts feature raw socket APIs and a Window interface. So I asked people at the conference whether the SVG working group shouldn't, instead of adding every feature under the sun to SVG, simply define how SVG should interact with other languages like XHTML. The answer I got was highly dismissive. Basically: "Well we want it in SVG".

You'll note that Robert O'Callahan (one of the core layout developers for Mozilla) sent an e-mail last month pointing out the many areas of overlap between SVG and CSS. He never got a reply to his last message. (Hmm... this is reminiscent of the way the SVG working group effectively ignored a message I sent back in 1999 pointing out a problem in SVG 1.0 that is still present in SVG 1.2 drafts — reply once, ignore further e-mails on the thread, and don't actually address any of the problems...)

Since many of SVG's features (like Window, or like the way CSS properties are allowed to have lengths with no units) directly conflict with existing standards (both ad hoc and de jure), it's quite clear that browsers that implement SVG will only ever be able to implement a subset of SVG.

Another point that was mentioned at the workshop was that DOM3 core was a long specification, checking in at some 216 pages. The SVG 1.0 spec is 719 pages long. (More than twice the length of CSS2.1, which I thought was already a ridiculously long specification.)

Still, it's a nice language if all you want to do is draw vector graphics.

Anyway. The issues have been discussed, the positions have been given, everyone knows where everyone else stands, now it's time to get down and actually start doing work.

What working group is going to work on extending HTML...

Pingbacks: 1 2 3

2004-06-29 16:26 UTC State of the WHAT

At the start of the month, Opera and Mozilla announced the Web Hypertext Application Technology Working Group. There followed some 600 messages and lots of great ideas, resulting, last Sunday, in our first "call for comments" for the Web Forms 2.0 specification.

When we announced WHATWG, several people noticed that the list of members also contained, in addition to Mozilla and Opera employees, a couple of Apple employees who work on Safari. A few weeks into the project we also added Dean Edwards of IE7 fame to the list. The members of the WHATWG are an oversight committee intended to make sure we don't get off-track; the specs are actually edited by me and based directly on the input we get on the mailing list.

There were also some people who commented that instead of calling it a Working Group we should have called it a Task Force, because the resulting acronym would have been much more appropriate. All I can say is that I wish I had thought of that because that would have been a really funny name.

I recently started on some Web Forms demos, to show what Web Forms can do and how it can do it without losing backwards compatibility. I haven't done much yet, just a demo of how to make the repetition model degrade gracefully in HTML4-compliant UAs, but it's a start. (Sadly the only UA I could find that was compliant enough to degrade in the right way was Mozilla, so we might well have to revisit exactly how those repetition model buttons work.)

The first public demo of a Web Forms 2.0 page was actually a very high profile demo, though I highly doubt that anyone present actually realised they were looking at it. It was during Steve Jobs' keynote speech at Apple's Worldwide Developers Conference, during the Safari RSS spot. If you look at the top right of the screenshots of Safari showing an RSS feed, you'll see a little slider control. That, my friends, is a Web Forms 2.0 <input type="range"> control.

Something I hadn't realised until recently is quite how many Web applications are hidden away inside intranet sites. I always knew that there were some there, but the sheer numbers of such applications is quite surprising. A few people have sent me confidential screenshots of their intranet applications (with the sensitive parts censored, of course), which has really helped get me an idea of the kinds of features that would be most helpful to people writing such sites. We'll be addressing a number of these requests in Web Apps 1.0 proposals once I've dealt with all the recent Web Forms 2.0 comments.

Joel Spolksy wrote an interesting article explaining why Microsoft stopped Internet Explorer development in its tracks a few years ago, despite it having ridiculously many bugs. Here's the executive summary: they realised that IE was competing with their OS to be the preferred application deployment platform. Since they make money from their OS, but don't make money from IE, the choice was clear.

I think the irony of this situation is quite amusing. HTML, a document format, is invented, eventually Netscape is formed and creates a dramatically successful product that makes Microsoft jump. Microsoft instinctively react to the creation of this new networked document viewer market by developing a product to compete with it. They (inevitably) succeed, by the simple mechanism of creating incrementally better products until one is "good enough", aided by the chronic mismanagement that characterised Netscape during its last eight or so years. However, in the middle of this process, the fight stops being over who can make the best document viewer, and slips into who can make the best dynamic content viewer. And that slowly turns into an application platform. Oops. I'm no business expert but I would hazard a guess that plunging billions of dollars into a loss-leader that competes with your primary business model is not the best idea.

I've known all the bits of this story for years, but they never really clicked until Joel explained it.

As Joel points out, though, Microsoft's moves after they realised their mistake with IE have been harder to understand. I would have thought the solution most likely to succeed would have been to extend IE in ways that made it into a better application deployment platform. Eventually, this could have turned IE into the OS, either natively (making the next version of Windows basically be IE), or by selling IE with versions for all operating systems. This would have had several advantages:

  1. It would settle once and for all their claim that IE needs to be part of the OS.
  2. It would solve the Linux threat: instead of competing with Linux, Linux would become just another platform upon which IE can run.
  3. It is what their customers wanted.
  4. It could create lock-in just like Windows has.

They actually did start down that road. IE6 has support for a technology that Microsoft stopped advertising at the same time as they stopped developing IE, namely HTAs, short for HTML Applications. Similarly, even without really trying, Microsoft managed to lock large numbers of people into the IE platform — it has taken years for Opera, Mozilla, et al to catch up to IE, and even now, there are many sites that simply won't work in any other UA. The problem, I am told, is that the visionaries at Microsoft want the lock-in platform to be an OS. That makes sense; I mean, that's what they know.

And so they took all the things that they thought made HTML a good deployment platform, and all the things that they thought made Win32 a good development platform, and all the ideas that Microsoft Research said would be cool, and started a huge project: making a completely new OS. (It isn't clear to me if this project spawned sub-projects like .NET, or if smaller projects like .NET became subsumed in the larger OS project.)

There are several problems with this approach, as I see it. First, the market is no longer growing that fast. In the past, when they released a new OS, Microsoft could grow its marketshare primarily by growing the market, and then once the new market hit critical mass, people on older platforms that couldn't run the newer software would be forced to upgrade to run the newer software. (They did the same with Microsoft Office: by selling enough new copies to new users, eventually old users were forced to upgrade simply to be able to read documents written by new users.)

But in the current market, Microsoft are having to depend mainly on upgrades. Windows XP didn't do as well as previous releases, as far as market penetration goes. And many people are questioning whether Longhorn has enough new features to warrant upgrading to it. So Microsoft will either have to quite radically change their approach, or they will have to settle into a slower revenue cycle.

But IE is only to play a supportive role in this big project.

Of course, Microsoft aren't alone in thinking that extending IE to be a new platform is a bad plan. As I previously discussed, the W3C held a conference on Web Applications just last month, and the majority of people there disagreed with the concept of the browser being the platform as well.

This actually led several key figures in the industry to question the W3C's legitimacy. For example, David Baron ponders whether the W3C is really relevant any more. Brendan Eich also wrote some scathing commentary on the W3C.

Then again, I work for a browser vendor, and have been in the browser industry (both voluntarily and as a job) for years now. So it's not surprise that I think the browser is important as an application platform. (Obviously, though, as Robert Scoble is eager to tell us, Web apps aren't the answer to everything. I wouldn't recommend to anyone that they try to write a graphics manipulation package in HTML.)

The problem with the browser today is that applications based in the browser are constrained to nightmarish UI idioms and a severe lack of polish stemming from the fact that the platform was not really developed as a platform, and that no real progress has been made on this path for several years.

John Gruber points out that users don't really seem to care about the poor UI, though. The other advantages — especially the true zero-install cost of Web-based applications — far outweigh the costs.

But that's why we started WHATWG: we want to make it easier to make nicer the kinds of applications that it makes sense to deploy over the Web. Mail and news clients. Cinema ticket sales. Book stores. Auction sites. Multiplayer stategy games.

In other news, apparently the Windows IE team is starting to wind down its work on the "let's make IE secure" Windows XP service pack 2 release, and is starting to look at what people want in the IE that will ship with Longhorn. They are even looking for feedback. Amusingly one of the most popular requests in the forums I have looked at (which is probably a very skewed subset of the real feedback that Microsoft gets) is "better standards compliance". And even more amusingly, one of the most often repeated messages from Microsoft people in those same forums is "we're not going to be working on standards compliance" (although not usually phrased that way).

I honestly do not expect to see any changes at all to the HTML, CSS, DOM, and JS components in the Longhorn version of IE compared to Windows IE6. I've had Microsoft employees tell me to my face that they will not have XHTML or SVG support in the next release. I've only seen excuses for why features won't be added, never any Microsoft employees saying they are interested in supporting a new spec. I have thousands of tests available on my site if they want to find some bugs, but I doubt they will even look.

On the other hand, I can assure you that here at Opera we are implementing all kinds of things and every release has more CSS/HTML/DOM/JS/XML/etc fixes. And over in Mozilla land Brendan has written several posts listing the kinds of things Mozilla will be implementing over the next few years.

Pingbacks: 1 2 3 4 5 6