Tangled in the Threads

Jon Udell, March 1, 2000

The Future of the Programmable Browser

Will DHTML converge on a standard? Where does XUL fit it? The crystal ball is cloudy.

A few weeks back, Mark Wilcox reported:

I've stumbled on this today:

http://zvon.vscht.cz/HTMLonly/MozillaTutorial/General/book.html

And now I have discovered the glory that is XUL, which allows you to build sophisticated menus using XML & JavaScript. Pretty wild stuff.

This is the stuff Zope is now using to build their next generation management system.

XUL, which stands for Extensible User-Interface Language (and is pronounced "Zool"), currently works only with the still-unreleased Navigator 5 (Mozilla) browser. If you've downloaded a recent build of Mozilla you can try out the examples at the URL Mark cited. There are also more examples in the chromeZone area of the MozillaZine site.

I have to admit that my first reaction to XUL was mixed. Great, I thought. Now we can use script to construct real menus, just like Hypercard could 15 years ago!

I don't really mean to be sarcastic, though there is considerable irony here. The web's move away from established GUI paradigms was necessary at the time. Had HTML required GUI-programming skills, the Web never would have taken off as it did. But now it's time for the pendulum to swing back toward richer user-interface machinery. I hope the simplicity that characterized the HTML revolution will carry forward into this next phase. So far I'm unable to read a simple message in the alphabet soup that includes DHTML, DOM, CSS, XML, and XUL.

In principle, XUL looks like a good approach to enabling regular HTML-literate folks (rather than GUI programmers) to create more powerful webtop interfaces. To explain why I think that, let's walk through the example that Mark mentioned. ZopeStudio, announced in December, is the first tangible result of Digital Creations' plan to elevate Zope's management interface, which is currently expressed in plain HTML, into a richer environment.

How ZopeStudio leverages XUL

To run ZopeStudio you need two components. One is a Zope plug-in which creates an alternate way of traversing Zope URLs. Consider this example, in which I'm browsing a Zope folder called XmlFaq using Zope's normal, HTML-based management interface, by way of the URL http://localhost:9191/XmlFaq/manage:

When the ZopeStudio component is plugged into Zope, there is an alternate version of this URL, http://localhost:9191/XmlFaq/zsContainerRDF. It produces, rather than Zope's normal HTML management page, a chunk of RDF (Resource Description Format), which is a flavor of XML. If we call that URL from MSIE, we can directly view the resulting XML:

In other words, the server-side ZopeStudio component delivers a package of RDF instead of the normal HTML page. How does this relate to Mozilla and XUL? To see this, you need to install the client pieces of ZopeStudio. If Mozilla lives in /mozilla, it's enough to just create this structure in your mozilla subtree: 

/mozilla/bin/chrome/zopestudio/content/default/zopestudio.js
/mozilla/bin/chrome/zopestudio/content/default/zopestudio.xul
/mozilla/bin/chrome/zopestudio/content/skin/zopestudio.css
/mozilla/bin/chrome/zopestudio/content/skin/minus.gif
/mozilla/bin/chrome/zopestudio/content/skin/plus.gif

Now, when you invoke mozilla like this: 

mozilla -chrome chrome://zopestudio/content

you should be able to log into your ZopeStudio-enabled server and see Mozilla transformed into a Zope object browser, like this:

There are two key client-side components. zopestudio.xul defines the layout of the object browser in terms of components such as <window>, <menu>, <box>, <toolbar>, <splitter>, and <tree>. I haven't yet found documentation on all these tags and their attributes, but the general idea is clear enough. These things are all widgets related, by way of IDs, to a CSS stylesheet that governs appearance and, most importantly, to the zopestudio.js script which governs behavior.

Thanks to the separation of concerns which the XUL mechanism enforces, you can make quite substantial changes to the UI without knowing anything about the underlying machinery. For example, to create the above screen shot, I wanted a skinnier details view that omitted a fourth column displaying the item's date. To do that I just located, and removed, this line in zopestudio.xul: 

<treecell value="rdf:http://purl.org/metadata/dublin_core#Date"/>

How does the JavaScript code (zopestudio.js) breath life into these simply-written tree components? It uses Mozilla's Document Object Model to get hold of them, and populates them with RDF data that it fetches from the server.

I don't pretend to understand all the details, and indeed I think a lot of this is still in the process of being invented. But I like the general idea a whole lot. In particular, I've long felt that we need to move beyond the basic HTML widgets to the richer constructs (menus, trees) which animate "real" GUI apps -- but that we need to do this without losing the simplicity that enables regular folks to splash some tags onto a page and make useful stuff happen.

But...is XUL going to be too little, too late? In a review of the M13 release of Mozilla, Joe Hewitt complained:

I figured that Mozilla would surely bring DHTML support to a new level. After all, Mozilla is supposed to support all those pesky standards that IE hasn't quite nailed down yet. After playing around for a few days, I have reached this unfortunate conclusion: as of M13, Mozilla is still behind IE5, and Bugzilla priorities don't show much optimism that this will be improved.

Given the heroic effort that is going into Mozilla, I realize that this kind of complaint may seem churlish. But if we're not going to end up in a one-browser world, with Microsoft in control of that browser -- and thus in control, once again, of the desktop -- then it's absolutely vital that we get a cross-browser standard for next-generation webtop GUI apps.

The DHTML juggernaut

Recently somebody pointed me to Halfbrain.com where you can see a remarkable demonstration of what the future of DHTML-based webtop applications may be. Halfbrain's BrainMatter is a simple spreadsheet that you can bookmark, rather than install. And no, contrary to the original vision for webtop apps, BrainMatter isn't written in Java. It's written in DHTML -- and, as you probably won't find surprising, therefore currently runs only in MSIE. Here's a picture of BrainMatter in action:

Java applets depend on a fairly heavyweight portable GUI. In contrast, DHTML webtop applications such as BrainMatter are lighter. They script the browser's Document Object Model. And to my mind, one of the crucial questions facing the Web is: will there be a standard set of next-generation widgets that these scripts can control?

HTML gave us input boxes, radio buttons, checkboxes, textareas, dropdown lists, and precious little else. It did not give us things like menus, or trees, or calendars.

The MSIE DOM (in version 4, and especially, 5) is strong enough to encourage developers to fabricate this kind of widgetry, and this has unleashed a burst of pent-up creativity. There are scads of DHTML sites, many of which illustrate ways to create GUI-style menus in DHTML. The problem, though, is that all these techniques are different. What hasn't emerged yet, from the W3C, are proposed standard tags such as XUL's <menu> and <tree>.

For now, DHTML developers go to extraordinary lengths to paper over the differences between the MSIE and Netscape DOMs. Have a look for example at Scott Isaacs' DHTMLLib, a cross-browser DHTML library. This library allows some very sophisticated things to be done on both Netscape 4.x and MSIE. And it works in an interesting way. On MSIE, it does nothing at all. On Netscape, it loads a JavaScript library that emulates a subset of MSIE's DHTML capability. Once that library's loaded, the JavaScript code written to it performs no browser detection -- it just talks to the real (MSIE) or synthetic (Netscape) DOM.

If you scout around, you can find some early examples of cross-browser DHTML that requires no such trickery. Here's an animation that runs identically in both 5.x browsers. This is certainly an encouraging sign. But, at the moment, I'm hard pressed to see how all the pieces are going to come together, and I have more questions than answers:

It's starting to feel, again, like those bad old days when developers had to place critical platform bets. For a while, the web swept all that away. The browser's basic HTML widget set was good enough for vast numbers of useful applications. That's still largely true, but sooner or later we'll go back to the future -- a richer GUI will appear on the webtop. Here's hoping we don't lose, along the way, the web's most cherished qualities of simplicity and universality.

Jon Udell (http://udell.roninhouse.com/) was BYTE Magazine's executive editor for new media, the architect of the original www.byte.com, and author of BYTE's Web Project column. He's now an independent Web/Internet consultant, and is the author of Practical Internet Groupware, from O'Reilly and Associates. His recent BYTE.com columns are archived at http://www.byte.com/index/threads

Creative Commons License
This work is licensed under a Creative Commons License.