One of the opportunities I had at MozCamp was to get caught up on the stuff happening in Thunderbird & Calendar. They have a goldmine of great data, functionality and UX possibilities. During some of the sessions and a small ad-hoc discussion, the use of HTML in XUL to create compelling, interesting and useful user interfaces came up. Thunderbird 3 will be using HTML to enhance to appearance and functionality of message display. Calendar might be using HTML to do the same for displaying tasks, IIRC. The examples I saw looked great.
I got the feeling that the designers and developers thought that using so much HTML in XUL was, in some way, anti-XUL. NO WAY! It’s my opinion that using HTML in this way – enhancing a user interface – shows the power of XUL. The ability to seamlessly mix different markup languages is quite impressive. How many other UI markup languages can do that?
The use of HTML, SVG and specifically, in XUL is not new. You’ll find many examples of add-ons and applications that go beyond XUL to create elements of the UI. XUL itself uses HTML as a foundation for implementing widgets.
Here are some examples from previous posts on using HTML, SVG and in XUL. Start spicing up your XUL UI today.
Ubiquity also mixes XUL and HTML together quite nicely – both in the core UI, and in some command previews. They’re very complementary.
Can you explain what parts of html are useful in this regard? Just some of the newer elements such as canvas, video, etc? Or something else? I fail to see how html can enhance UI as it provides little in terms of UI capability.
svg:image is great in XUL too, it does aspect ratio preserving scaling, unlike the normal XUL image methods 🙂
Neil: the biggest gain to using HTML as opposed to XUL is that there is a huge “cultural” strength behind HTML+JS+CSS, and not so much in XUL+JS+CSS. So for example, all of the popular JS libraries (jQuery, but all the others as well) are tested against HTML documents. They _could_ work in XUL+JS, but that’s just not tested.
The second powerful advantage to HTML over XUL in layout is that it makes working with the design community easier, because there are lots and lots of good web designers who, at this point, understand HTML+CSS deeply, but for whom the XUL box model in particular is very constraining. That’s not a technical argument, but it is real nonetheless. If I can go from design to implementation that much faster, then I can iterate on designs faster, etc.
The biggest challenges of HTML in chrome, I would say, are 1) the fact that dialogs in particular are not web pages — they tend to have a height, not want to scroll, etc., and so using HTML without thinking won’t work, 2) the fact that none of the bindings that people have built over the years work today in HTML, and 3) that accessing OS-native widgets isn’t going to be as good of a match with HTML than XUL, I suspect.
2) is something I think we can address piecemeal, by slowly building up XBL bindings which have the same accessibility (keyboard and otherwise) of the XUL bindings. 1) is avoidable by using CSS wisely. I’m not sure I understand the implications of 3) yet.
While the examples davida showed in Barcelona looked too much webmail-style and non-native-interface-style for my taste (it’s easy to get into that with HTML), my Mandelbrot XULRunner fun project also uses a in XUL, see http://home.kairo.at/blog/2008-08/kairo_at_mandelbrot_going_public
> So for example, all of the popular JS libraries
> (jQuery, but all the others as well) are tested against HTML documents
Are you talking about all those libraries that exist mainly because HTML and its apis are insufficient for what people want them for? That doesn’t sound like an advantage of HTML.
> The second powerful advantage to HTML over XUL in layout is that
> it makes working with the design community easier, because there
> are lots and lots of good web designers who, at this point,
> understand HTML+CSS deeply,
Then the issue here is that you should be working with UI designers, not web designers. UI designers build user interfaces, not web sites. As far as I know, the UI designers that Mozilla has on staff don’t particularly need or use ‘HTML+CSS deeply’ at all and the Firefox UI hasn’t suffered for it.