The Forgotten Macro Language of HTML: XBL 2.0 138
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.
Forgotten? (Score:4, Interesting)
A Mozilla-only technology that no other engine supports doesn't really qualify as forgotten, even if someone submits it to W3C.
Re:Visual Studio for ASP.NET (Score:5, Interesting)
Re:Visual Studio for ASP.NET (Score:1, Interesting)
Maybe (ok, almost certainly) he is, the problem is that everything he wrote is true.
Re:Why is it dead: (Score:3, Interesting)
What exactly is your point? That because the HTML is shorter it is somehow better or easier to maintain? That XML style definitions are bad cause there is too much fluff for your brain to comprehend? Actually, what the Hell are you saying?
"Short != Better" (TM)
Plain old HTML fails miserably, since that hard-codes what to do into every instance of the list element. That's akin to writing a separate class for every instance of Foo, defining the exact same operations for each one. It might look shorter when you have one instance, not so much when you have 1000. Yeah, you could auto-generate the Plain old HTML from a back-end, but for your argument to work, you'd have to show that code too. Plus the code needed to bring it all together.
Guess I'm the one guy here. (Score:4, Interesting)
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.