Slashdot Mirror
The Forgotten Macro Language of HTML: XBL 2.0
tvlinux writes "The web is becoming more than just a media display; there is more interaction and more special things that need to be done. Right now, jQuery is the preferred method of a very dynamic user interface. There is a W3 standard called XBL2.0. It is the macro language of HTML. To me it seems like a great idea — reusable HTML widgets, where each one is a separate object contained with in itself. You can define properties, methods, and events, each of which is self-contained. If the browsers supported XBL2, I can envision a whole ecosystem of new widgets, charts, grids and inputs that people could add to web pages just like any other HTML element. I see less experienced developers being able to create fancy websites by just using DOM and not having to learn jquery. My question: why is XBL dead? I think a macro-language for HTML is a good idea."
XBL is alive and well, but only for XUL. Looks like another casualty of HTML5's rejection of XML.
Many Slashdotters don't know it, but ASP.NET and Visual Studio actually make it really easy to use controls, DOM and object-oriented programming. This makes web coding much more like form-based and MFC-based Windows programming, and it works great.
Not only that, but you can actually automate database design and queries. ASP.NET can create SQL queries and db design based on your classes and this makes programming really fast and easy while maintaining good object-oriented code and practicing safe programming.
A Mozilla-only technology that no other engine supports doesn't really qualify as forgotten, even if someone submits it to W3C.
If you want reusable, self-contained widgets that can be used to construct new more complex widgets that can int turn be distributed as self-contained reusable widgets, have a look at Dojo/Dijit. Basically, Dojo is a library that does what jQuery does, but a slightly worse, and Dijit is a library that does what jQuery-UI does, but about a million times better.
Did you even read any of the documents you linked in this post? XBL was never a macro language for HTML, though it could be used for that purpose. It was created by Mozilla specifically for use with XUL. They submitted it to the W3C as a Technical Note (http://www.w3.org/TR/2001/NOTE-xbl-20010223/), and their implementation didn't match the specification they submitted, so naturally it didn't go anywhere. XBL 2.0 was done properly, and is at the Candidate Recommendation stage. However, it will likely never go beyond that: not just because it hasn't for 6 years now, but because the W3C requires two complete and interoperable implementations to exist. Since all the other browsers already have their own ways to mangle CSS into non-standardness, there's not much interest in adopting it.
XUL: Do you want this <body/>?
Venkman: Is this a trick question or what?
XBL was disregarded long before HTML 5 by all browser makers except Mozilla, so trying to pin blame on something that didn't even exist is ignorant and downright rude.
"Wait. Something's happening. It's opening up! My God, it's full of apricots!"
Plain old HTML:
<li onmouseover="doSomething();">...</li>
Same thing with XBL:
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding element="#nav li">
<handlers>
<handler event="mouseover">
doSomething();
</handler>
</handlers>
</binding>
</xbl>
HTML, XML, and really the whole SGML family kind of suck-- ugly syntax, annoying to hand-edit, lots of boilerplate, and the list of faults go on. The idea of writing actual programs in such a language is terrifying.
It's been superceded by Web Components: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html
That's why it's dead.
Like in... XSLT?
I don't know whether you were being ironical or not. But the amount of bad taste coming from this XML direction is almost boundless. Even programming.
XBL stands for eXtended Business Language and is designed for the financial accounting of a company. Corporations must transmit their data in XBL to the SEC for quick analysis. I guess it can be used on the web, but it's much more of an internal language.
The absolute minimum a developer needs to know in order to create a web application these days is: HTML, CSS, Javascript, some programming language on the server (e.g. PHP, Java, Python) and something to store stuff on the server (e.g. MySQL, PostgreSQL, CouchDB, MongoDB). It's also nice if the developer knows how his webserver works. At the very least he should know how .htaccess files work so he can configure his web application to work the way he wants.
Then there is not really necessary but certainly useful stuff to add like an Ajax library (jQuery, YUI, Dojo etc.) and a CSS preprocessor (SASS/SCSS). And there is a bunch of other useful stuff that doesn't really require any training, but they are beneficial to the development of your project like normalize.css, modernizr and html5shiv. These things help to make your web app cross browser compatible and make sure they sorta work with old (but not too old) IE's as well.
And because this is already a lot of stuff and you dont need to invent the wheel for the millionth time, it may be nice to wrap both your clientside and serverside code into a framework. This also helps to prevent things from getting too messed up as the project grows.
For the clientside the choice is relatively limited as Javascript is the only language available. A selection of different frameworks for review is available here: http://javascriptmvc.com/
For the serverside you pick a framework based on your language. Or you pick a language based on the framework you choose. Its up to you.
So no, we dont need yet another language on top of all this, thank you very much.
Pretty good is actually pretty bad.
Good
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
It aate8pts to
Xbl is dead because it's got a steep learning curve and is painfully abstract. Having written a fair amount of it, it took quite a while to get used to. I used while doing a bunch of xforms work with the Orbeon engine; but even they have dropped support for it as their component model. It was pretty cool, you could nest a number of XBL components together and have them render based on the data type of your XML element. An example would be an XBL phone number editor. Every time your schema used that type in your form you always got that editor for it; but debugging was impossible. It all happened in the dark on a cloudy night through three layers of fog snow rain and ice.
>less experience developers be able to create fancy websites by just using DOM and not having to learn jquery
and you expect more experienced developers to make this happen? Look at lawyers and the law since the 1600s - when has it ever gotten simpler or easier for newbies?
That's not really the problem. Sure, it takes more code to define a reusable template than to just use HTML to define a use-one widget, but that's expected. The savings from templates come from reuse, not from using them once.
XBL 2.0 is not a W3C standard, its a W3C Working Note -- which is very far from a standard -- that has a big fat "no one is maintaining or implementing this" on it.
It seems to be dead because the competing HTML Template (current W3C working draft) model was more successful in attracting commitments from implementers.
[...]separate object contained with in it self.
Honestly, is this where the English language is headed? Breaking up words until all sense is lost?
A camel is a horse created by a committee