Adblock Plus and (a little) more
Mozilla Developer Day: XUL vs. HTML · 2007-06-26 01:10 by Wladimir Palant
Update, Juni 27: It seems that some of the weird comments here originated from a misunderstanding. This article isn’t about the web — HTML is the language of the web, no doubts. The Developer Day was about building applications, the ones you download — like Firefox, Songbird or Joost.
Mozilla Developer Day in Paris was great. I still cannot believe that I sat at the same table with Daniel Glazman and Benjamin Smedberg (but in our modern times there is proof). There were lots of people I always wanted to meet in person and many interesting talks. The Joost guys delivered a very impressive demo. But the best of it were the discussion sessions. 70 XUL developers in one room — this doesn’t happen too often.
I want to write about one particular discussion session because I think that it might be interesting to people who weren’t there. It was titled “XUL dark matter” but that’s not really what we talked about. Instead, Benjamin Smedberg confronted us with a very provocative question: why do we use XUL and what would it take to get us switch to HTML?
Are you puzzled? I think many people were. Was that a serious question? The advantages of XUL are too obvious: the box model, powerful localization mechanism and user interface widgets with native look-and-feel. But it isn’t that simple. The box model can be used from HTML as well, just take a look at Mozilla’s CSS extensions (e.g. display: -moz-box and -moz-flex: 1). The same DTDs can be used to localize XHTML just like XUL, and soon peterv will hopefully open us the whole new world of remote DTDs. Even supporting the same mechanism in regular HTML is not unthinkable, the standard allows it (I suspect however that there will be technical issues due to traditional abuse of doctypes in HTML). Finally, there is hope that some XUL widgets can be standardized for HTML (some as part of HTML5, some for later versions of HTML — it is a long-term effort). So the question is, why do we still need XUL?
As it turns out: it isn’t about the features. Ben Bucksch was the first to recover from the shock and to note the cultural aspects. XUL developers would prefer their “own” language simply so they don’t get mixed up with the FrontPage crowd. Currently there are entire worlds between a XUL developer and an HTML “developer”, and this separation is there to stay. I continued with a similar thought: the beauty of XUL is all the things that it cannot do. It cannot do table-based layouts or relative positioning (everybody who ever “inherited” a web application will probably appreciate this a lot). It doesn’t do all the numerous quirks to be compatible with all browsers including Mosaic 1.0. It doesn’t even have a quirks mode! It is a simple and straightforward language built for one and only one reason: to enable efficient development of user interfaces. It is meant for one and only one platform: Gecko. And for one and only one version of it: whatever the current version is at the moment. Yes, it is not backwards compatible, and we sometimes have to suffer because of it. But at least bugs are fixed instead of being preserved for all eternity.
HTML isn’t going away, but I hope Mozilla Corporation will recognize that XUL isn’t going away either. Of course, having to maintain similar yet not identical widgets for both XUL and HTML requires more resources. But giving up on XUL is not the solution. Adjusting XUL wherever necessary to allow code reuse between XUL and HTML seems more realistic to me. For example, <datepicker> in XUL could be changed to behave like <input type="datetime"> in HTML5. This is still a painful process especially because the changes cannot be done all at once but it should be doable.
All in all the developer day was far too short. There was too much to see and discuss for one day, which is why the demo session for example took three hours instead of the expected one hour. AllPeers promised us another developer day in Prague in September and I want to go even if TomTom decides not to sponsor the trip. Hope to see more of you there!
Comment [9]
Commenting is closed for this article.
lockoom · 2007-06-26 10:51 · #
Well but if you’re developing in XHTML rather than XUL only for Gecko you also would not need to fix bugs for other browsers. So – no quirks mode.
And table based layout isn’t evil. It’s abuse of table element which is bad. But, hey, you have display: table-*...
So it looks like the only advantage XUL have over XHTML is that its developers can feel elite ;) But I’m not sure if it’s enough to maintain another HTML-like language ;)
Reply from Wladimir Palant:
I don’t need to fix bugs for other browsers, but the browser does. All the compatibility relics are still there and I have to deal with them when developing.
And there is a <grid> element in XUL which allows for nice layouts – similar to HTML tables, but this element is really meant for positioning other elements. The result is that I have never seen messy layouts made with <grid>, yet a lot of those with HTML tables. Don’t forget that HTML table sizing is about the most complicated thing there is in HTML (partly because of backwards compatibility), so it is absolutely not suited for good user interface design (note: user interface and not document/web page). I already dread the hacks to implement automatic window sizing for dialogs with table-based layout.
Justin Dolske · 2007-06-26 11:02 · #
I don’t know how XUL will transform, but a few things I believe…
* There are vastly more people familiar with HTML+CSS than XUL. Lowering the barriers to developing Mozapps is a good thing.
* My qualitative impression of XUL is that it has quite a few crufty corners where things don’t work quite right, and features which are unrefined. Having a more diverse set of XUL applications will help flush out problems and create justification for fixes, but greater commonality with the parts being banged on every day by billions of web pages is the best test-suite of all.
* I hear people are doing crazy things with the web these days, like writing HTML-based applications/services to replace things that were traditionally desktop apps. :-) So, if XUL can do things HTML can not, then shouldn’t HTML be extended to support those things? Conversely, if HTML can do things XUL can not, then shouldn’t XUL be extended? At the hand-waving level this implies XUL and HTML share a convergent future, although practical details probably limit just how far any kind of unification can go…
My $0.02! :-)
Reply from Wladimir Palant:
Lowering barrier to entry is a good thing of course, but having people go into user interface design keeping the concepts from web page design is just asking for trouble. At the moment XUL at least requires you to relearn how a user interface is designed, you cannot reuse your experience with table-based layouts or other positioning hacks.
I agree that getting better testing for widgets is a good thing (I meant to write this in the article but forgot). And XUL widgets in HTML will certainly be useful – for rich user interfaces in web pages. But these user interfaces will not have the look-and-feel of native applications or only with a huge effort, simply because HTML is not meant for that. We still need a small and focused language.
Brian King · 2007-06-26 11:59 · #
Good thoughts Wladimir, I largely agree.
BTW, I too hope there is another DevDay in September, as I could not make it this time around.
pd · 2007-06-26 12:06 · #
that attitude from XUL developers is EXACTLY why XUL will get caned by Apollo and Silverlight.
What a pathetic elitist load of shit.
Reply from Wladimir Palant:
The funny thing about this is that Apollo and Silverlight don’t compete with XUL – they play in an entirely different league. If anything, their competition is WebRunner. But you wouldn’t know that…
lockoom · 2007-06-26 14:11 · #
Wladimir,
So it is exactly what I said. You assume HTML developers are “handicapped”. They can only use obscure hacks, table layouts and bad design…
Correct if I wrong but there plenty of bad C++ coders, Perl programmers and so on. XUL isn’t different.
You should not fear XHTML as XUL replacement as long as Gecko wont allow bad practices to leak from “web HTML” to “UI HTML”. But that’s quite simple: if it is an extension, not a webpage, use only strict validating XML parser, no quirks mode, only XHTML.
As for missing elements: , etc. – “X” in XHTML stands for “eXtensible”. It’s XML, it can have elements from different namespaces – just like XUL.
Anyway, I suspect that it was simply easier to develop specialized language for GUI than extending language desiged for documents which also happen to give possibility to create GUI ;)
Reply from Wladimir Palant:
I don’t assume that HTML developers are handicapped – I know that most of them are. And “most” certainly doesn’t mean “all” (I am doing web development myself), but the way you design a web page is radically different from the way you design a user interface.
The whole point of using HTML for user interface development is making development simpler and more attractive to new developers – and that automatically means allowing bad practices, otherwise there is no point.
pd · 2007-06-26 16:07 · #
I’m perfectly aware of webrunner and regularly read Finkle, but you wouldn’t know that.
The worst element of IT is arrogant developers who ignore the wider community and separate themselves too far from the vast majority of the people in the world – users.
To suggest that genuine Web Developers are not relevant to XUL is just pathetic. XUL is just another markup language, the same as HTML. If you all think you’re so important because you can write XBL in C and the average Web developer cant’t, you’ve got your heads stuck so far up your arses you cannot see the way out, a fact that is confirmed by moronic comments like “I know most web developers are handicapped”.
Pull your head in (or out, of your arse, as the case may be)
lockoom · 2007-06-26 16:23 · #
@Wladimir: Ok, than we have different definition of “developer” :) I don’t count every single person who happen to create “webpage” as developer :)
But I agree that probably for every 100 developers there are more bad HTML developers than XUL ones. But that’s an effect of browsers forgiving minor (and major ;)) mistakes.
Anyway I’m not advocating on XHTML over XUL. I just agree with Benjamin Smedberg that XHTML could be (successfully) used instead of XUL. But that will not happend :)
@pd: Being offensive won’t help you in discussion.
Reply from Wladimir Palant:
I just look at http://xpoint.ru/forums/internet/html_css/css/forum.xhtml and see what the usual solutions are when you have to deal with HTML. That’s a very professional forum frequented by very experienced web developers – but that’s not the kind of experience you would want to see applied to user interfaces.
XHTML was never an option in this discussion. The general consensus is that XHTML is already too complicated and doesn’t have a future anyway. Having seen what usually comes out when web developers attempt to use XHTML I tend to agree – even experienced web developers rarely understand what XHTML is about.
lockoom · 2007-06-27 10:57 · #
I’m well aware of HTML5 initiative and problems with XHTML. HTML5 is a great thing. I’m Opera user personally so I follow WHATWG effort from the beginning. It was about 2 years, I think, before it got into W3C. Also note that Hixie is writing about XHTML being pointless when sent as text/html. Note that as for now, only in XML serialization of HTML5 (well it’s XHTML5 :)) one can use elements from different namespaces (SVG etc.). AFAIK they’re working on this issue, though.
The truth is, no matter how complex XHTML would be, Gecko have to support it anyway. As far as I know development in XHTML support haven’t stopped ;)
Ok, to end this discussion: like I said I see the advantage of having specialized language for GUI. All I said is that there is nothing wrong in XHTML which prevents it from describing UI of the application. Actually it was already chosen as GUI language for Apple’s and Opera’s widgets. Of course it is not the same as normal application but…
John · 2010-04-26 16:03 · #
WOW!!!! cool great ideas you provided in your post