OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XUL vs. XHTML 2.0/XForms 1.0

[ Lists Home | Date Index | Thread Index ]

Hi Robin,

Thanks for your reply.

Robin Berjon wrote:
> Emmanuil Batsis (Manos) wrote:
>> Flamewars and name hijacking aside, XUL has some very interesting 
>> features that leave XHTML behind, namely the set of reusable widjets 
>> and advanced box model.
> That's a statemenent ("leave XHTML behind") that would need more 
> qualification. 

True, but such qualification cannot be contained in a xml-dev post IMHO 
and if it could, I wouldn't have the time and clarity to do it. It's a 
personal opinion build on experience and just thrown in; I wouldn't even 
try to support it in a debate here. Similarly, you can try and write 
about the merits of SVG for example but I will only grasp those after 
extensive use of it. Unfortunatelly, I haven't found motive to include 
SVG in my every day work as there is no demand for it yet.

But to give some points, my main complaints on (X)HTML could perhaps be 
limited to:

* Absense of UI widgets beyond HTML 4.x. The result of this is 
proprietery technologies like DHTML behaviors and (the original W3C 
note, not much to do with today's) XBL as approaches to address the 
*need* of application oriented UIs.

* Luck of extensibility mechanisms. I want custom elements and I want to 
define their rendering and behaviour in a standards way, not the 
hackiish approaches we struggle with every day.

* A higher level of remote data awareness and utilization. True, XMLHTTP 
is (a non standard but) implemented in at least two major browsers and 
can be combined with DOM scripting to allow interactive content without 
refreshing the whole page each time but it's too low level.

* A more flexible box model. XUL has a more advanced box model; a 
superset of HTML's.

 > XHTML wasn't designed for applications, it was designed
> for documents.

For once, I cannot agree with you. (X)HTML documents have been used as 
application UIs for a long time. Their role as such is increasing as 
time goes by VS the plain document role. The two roles are not mutually 
exclusive, while XHTML is not the best choice for a strictly document 
oriented format. Various others are better choices depending on 
requierments (DocBook, FO). In my view of the markup universe, XHTML is 
the lowest common denominator as a document rendering medium due to 
(mostly partial) implementations being widely available.

In short, I just think that XHTML could provide better support for 
application oriented documents. XForms is a leap forward of course, but 
it only solves part of the problems we face each day, plus it's far from 
being widely implemented.

>> But the best part is about extensibility via XBL. Something like DHTML 
>> behaviors but far more efficient, offering creation of custom 
>> elements, events, etc. Actually, most widjects are implemented in this 
>> way.
> Please see: http://www.w3.org/TR/SVG12/#rax . It's an early WD 
> description. Imho it's the way forward.

Sounds promising but it's too early for me to bet on it. SVG support in 
browsers is rather dissapointing. Even worse, plugin-based support 
cripples what could be done with mixed markup (SVG+MathML for example) 
although the document you point out will probably try to address that.

I don't want to compare the two approaches but XUL/XBL offers me much 
more than any other implementation of foo in the browser area. XUL 
support for RDF datasources for example, may provide some insight on how 
SVG could do [1].

Finally, I strongly believe that if SVG could adopt something like XBL, 
it would probably become *the* UI platform. XBL allows one to build 
custom elements, including their presentation, events and generally 
interaction logic. Of course widgets can be build on top of other 
widgets... but the XUL element set is limited; if something like XBL 
could be used with a vector language like SVG... it wouldn't even have 
to provide widgets; I bet libraries would become available all over the 
web, much like DHTML scripts are today.

[1] http://www.w3.org/TR/SVG12/#rax-semantic



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS