Knobs and Trees

Related link: http://lists.w3.org/Archives/Public/public-webapps-cdf-discuss/2004Jun/att-0000/…

That non-Microsoft browser makers have organized themselves as the WHAT Working Group to develop browsers further should come as no surprise: Microsoft is obviously looking in the direction of XAML and is probably quite happy with the current state of HTML.

The esteemable T.V.Raman makes several good points in the transcript of the recent W3C Workshop on Web Applications and Compound Documents, especially We have stagnated in the last 5 years.

Of course, every-one knows how HTML subsetted SGML syntax (and the ISO DTD, in part)) and how XML subsetted SGML syntax differently, and both have been very successful for different things. I don't want to bore you with my views on why XHTML (when conceived as a replacement for HTML, rather than a different stroke for different folks) is dumb. I have other things to bore you with!

I have been working on two projects over the last several of years that have made me think the problem with HTML's stagnation and XML's lack of success on the client is not just to do with the HTML WG being forced to cope with XML, nor with the kitchen-skin standards. Nor even with the database/business focus at W3C nor Microsoft's boredom with standards making.

I think the essential problem with browsers is that users have not demanded of vendors (which is a polite way of saying that vendors have not anticipated and co-operated) that they provide declarative tags for the things that are currently implemented using scripting. Why don't we have tags for menus, for trees and so on?

One of the projects I have been working on involves creating music synthesizers in software: there is a ubiquitous API called VSTi that most music host applications support. These little VSTi plug-ins are usually highly skinnable: in fact there is even a "skinning community" of people who make knobs, WinAmp skins, Java Looks and Feels and so on.

Now if I want to add a knob to an HTML page, say to select a value, what are my options? I could download some kind of JavaScript and animations, or some Java applet, or some VisualBasic (or whatever we call it now) control. If I want to do it in markup, I have to wade into SVG, so that I can draw circles and construct things from primitives and bitmaps. Utterly inconvenient. And the result is that while the dashboard "bells and whistles" GUI is thriving like never before, especially in connection with media-related applications, the WWW is essentially knob free.

The main project I have been working on is, to me, an even starker indication. My company, Topologi, creates various analytical tools for high-end SGML and XML publishing. (We are just delivering our newest offerings, by the way.) We build a lot of these on a special kind of Web browser, "TreeWorld", that exchanges and displays tree data rather than HTML data. Like original HTML, we don't try to do everthing: the model is a simple REST model, where you select a displayed branch or branches and send that as a request serialized to XML to some URL with an action request. Then the response comes back (asynchonously) as XML (simple SOAP), with indications of whether to replace the original branch, open a new tab, append it, etc. The XML also has simple formatting hints, such as decorating GIFs and so on.

Now functionally, there are probably hundreds of systems for displaying trees on web pages using JavaScript. Indeed, we have a couple in-house too. But the point is not so much that we are viewing trees (they are a basic and common component), nor that our trees are generic XML rather than a specific vocabulary (allowing extensibility). And not that this kind of system has a great network effect, because you can link between trees sourced from different URLs so easily. The key point is that the data transferred is 100% declarative not programmed: we just send data, and the data usually requires very little transformation from the source.

HTML has largely stagnated because the W3C et al (and, I say this with enormous respect for the people at W3C, who have to cope with lots of different forces, from reactionary to visionary) because there has not been a systematic program to look at applications (web applications, applets, web-enabled applications) as the prime source of uses cases for new tags for HTML. Microsoft's XAML and Netscapes' XUL are both reactions to the stagnation of HTML, undoubtedly not entirely innocent ones, and also steps backwards: large, systematic proprietary APIs that expose a native/extensible set of controls.

I know that knobs are good, and make interaction much easier for some applications. I know that trees are good, and make interaction and access much easier for some other applications. I know that most web-applications or web-enabled media programs I use have trees (and menus) or knobs. They are a nice size of object to work with, and to skin.

It will be interesting to see how the WHAT Working Group goes: I am hopeful something good will come out. But how to get these kind of objects standardized and available on HTML web-pages without an enormous "W3C Standard Rotatable Virtual Graspee Object, Event, Behaviour, Styling and Canonicalization Markup Language and Primer" (SRVGOEBSCMLAP) being made for knobs, or something worse for trees? I don't know...

But I am sure that the approach of providing straightforward elements in HTML for the kinds of things that people are forced to do in JavaScript is the best approach. (XML Forms is probably the technology closest to this following this approach, and I am glad to see that the WHAT vendors look like supporting it.)

Do you want more knobs on the Web?