[
Lists Home |
Date Index |
Thread Index
]
>the other important aspect is how quickly people
>will understand and author an XML UI language. Re-using
>and extending XHTML means people can start from where
>they are today. That is, IMHO, the way to go.
Right; one of the oft-touted benefits of XUL is that you can build your UI with simple markup(XUL), javascript, and css. ?? well not to be persnickety but if one wanted to exert oneself(by considering something outside of the marketing literature) I bet they could build their UI with simple markup(XHTML), javascript, and css just as easily.
About not understanding the value of XHTML, depending on the way one handles XML the value can be slightly obfuscated; for example if one does a lot of transforming from meaning descriptive formats to presentation formats, which personally I think has been the main impetus of the XML revolution; the benefit becomes hard at first to understand. I think this focus on transformation(by which I mean transformation using not just XSL-T but other tools as well) has led to some bad design decisions, especially where XSL-FO is concerned.
Perhaps there is a tendency in transformation to use brute transforms, to not use the clever things about each markup language but rather to use the clever aspects of your transformation tool of choice to effect a clever result with dumb markup. I say this knowing that I am a great transgressor in this area. This may be because one has to do so many different things that it just does not pay to learn what is clever in a new markup language.
The modularization capabilities of XHTML being one of its clever bits; people do not like to think about: 'okay how should I build my result document to best take advantage of this'. Hell, it's an uphill battle to get people to use CSS.
Jumping back to the XUL subject, one could using Internet Explorer build an UI with the same capabilities offered by XUL.
Although I am not a fan of the language I think some clever XUL proponent should consider building an XUL interpreter using the following, a C++ project hosting the webbrowser control(so they could use IDocHostUIHandler::getExternal for application functions http://www.microsoft.com/mind/defaulttop.asp?page=/mind/1098/advhost/advhost.htm&nav=/mind/1098/inthisissuecolumns1098.htm); although my understanding is that you can also host the control in .Net without the security restrictions one gets in a VB project. I considered at one point porting my simple HTA generating project to the Webbrowser control but C++ just chaps my hide. :)
Have the application on start load your client's default xul and an xsl-t for generating a UI that the webbrowser will understand, have navigation take place inside of an IFRAME so one can gain some control over security.
Then there would be cross-browser XUL, of a sort, and I think it would be a much better contender in the 'simple XML-based UI' wars. :)
Hmmm, I bet I'll get flamed for this.
|
