[
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
Manos
|
