I think I've finally understood what the new WHAT group is trying to accomplish. At first, I thought it was intended to be a group for defining ways to create sophisticated applications but using HTML. In effect, what one might do with XUL, or what Macromedia wants to do with Flash, or what many at the recent Web Applications Workshop want to do overall with other languages. That is, build standalone applications separate of browsers that communicate to servers. I was a bit worried that WHAT was essentially trying to do the same thing but use HTML instead, which wouldn't be a good idea. This, I think, is fortunately not the case.

Instead, WHAT is just trying to build a few additional features onto HTML, CSS and the DOM to allow more sophisticated interaction, perhaps what XHTML really should be. Specifically, the goal is to allow better interfaces for web pages and not to build applications like image editors or web browsers. This will certainly be simpler for web developers and is a much better transition. I personally would like to see HTML include much more document oriented features, and even XHTML 2.0 doesn't provide much of this.

The folks in the standalone web applications camp that prefer using XForms and SVG and the like seem to want to build an entire platform. That's fine, but that is rather a lot of work, and may not have a lot of return value considering that there are lots of platforms already. The biggest disadvantage is that they are starting fresh without much of an existing base to build on. Sure, they have XHTML and SVG and the like, but these are fairly new, don't have a lot of implementations to 'harden' them and are hardly the right languages to form the basis of an application. For instance, I don't know many popular Windows or Mac applications (or those of other platforms) that actually have any vector graphics in them. XForms may be sophisticated, but unfortunately a form is only one style of UI, one which doesn't necessarily fit all of the web applications that the advocates want people to create with it. It fits well when the UI is a set of fields to fill out (which is why it's called a form, since it mirrors the paper forms you need to fill out in order to communicate with the government.) Very few applications outside of web pages use this UI paradigm however. For this, an event model is generally more appropriate, since the user interacts with the UI in a fairly random fashion. Click a button here, choose a menu item there, that sort of thing. Which is why I think server side events are a good thing. In fact, I had started an implementation of XUP a while ago; I wrote everything except the part that required SOAP.

I was also wondering how all of this fit into Mozilla's plans described at the recent developer day. In fact, it does. Mozilla as a platform has the advantage that it's not starting fresh -- I doubt they want to go through that again -- it already has a base which implements much of what is necessary. For instance, Mozilla already implements much of the features listed in the requirements section of the WHAT's Web Applications work. As a platform, Mozilla succeeds since it is actually implemented and has much of the needs of a platform already in place. The WHAT's new features will be a benefit to Mozilla as a web browser and as a platform. And, atcually, due to XUL's design and implementation, don't conflict much at all.

One of the interesting aspects about XUL is that there is very little native code in its implementation. All of the box layout code could be considered part of CSS, since these layout types can be used outside of XUL as well. In fact, this flexible box model is already being worked on as part of CSS. The only code of any considerable size specific to XUL is the template builder and the tree widget, as well as some smaller features such as overlays and listbox handling. The template builder and overlays are perhaps application specific while the tree and listbox code could be adapted in a compatible manner to be useful outisde of XUL.

The WHAT is specifically not trying to define any eleborate UI widgets such as toolbars or progress meters and so on. In fact, those would be better defined in libraries of XBL, much as XUL widgets are currently. I think the eventual goal is to make as much as possible be implementable in CSS or XBL such that HTML, XUL and other languages, even XForms, could build upon them. In addition DOM APIs to do drag and drop, server side events and popups would be available to use. With all of these available in the base browsers, it might be possible for someone to implement XUL in another browser such as Opera, simply by porting the XBL to that browser. OK, this isn't really the goal, but it would be a good indicator that the base web application features were of sufficent capability.