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.

Comments

Forgotten?

[ChunderDownunder]

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

[Chrisq]

I have to hand it to you, as a paid shill you are worth your money:

• (Article) Posted by Unknown Lamer on Tuesday April 16, @08:42AM
• (Shill) by John Wagger (2693019) * Alter Relationship on Tuesday April 16, @08:42AM (#43459079)

Really?

[Anonymous Coward]

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.

There is no Dana, only XUL

[Anonymous Coward]

XUL: Do you want this <body/>?

Venkman: Is this a trick question or what?

Why is it dead:

[psholty2]

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>

Re:Why is it dead:

[dkleinsc]

"Short != Better" (TM)

Short sometimes == Better:
- Programmers don't have to spend as much time reading to figure it out.
- In studies, the ratio of bugs to code size is basically constant until the code is thoroughly tested. Minimize the size of the code, reduce your bug count.
- For network services, including HTTP, fewer bytes = fewer packets = faster response.
- Short is often simpler.

Compare the XBL shown above to the equivalent JQuery:

$.("li#nav").on( "mouseover", doSomething );

Which one would you rather read and parse?

Re:Why is it dead:

[Cenan]

Simplicity is in the eye of the beholder.
Your code does not contain fewer bugs because you put it all in one line. Your code contains bugs because it was, for the most part, produced by humans. And even the best developers will have an error rate > 0. Shorter lines does not magically boost reader comprehension. The quality and clarity of the code produced will however help you, no matter how many lines you're maintaining.

You can scream and moan all you want, the OP is still comparing apples and oranges, and so are you. I don't lament the forgotten-ness of XBL, good riddance. But that little tid-bit of XBL code in the OP is actually very very clear with regards to it's intent; maybe it's just me being way too familiar with XML style syntax.

If every byte counts, don't pick a framework that serves plain XML as responses, that's just retarded. Choosing the right tool for the job, is, well, part of the job.

And yes I got fed the same statistics about code size leading to more bugs in school too, and I thought it was self-evident back then too. More lines -> possibly more features -> more bugs. It is a very simple, but apparently so hard to grasp that studies had to be performed.
If you minimize your code base, you're going to have to cut out features, which in turn leads to comparing oranges and apples again because you no longer have the same product. Or are you saying that jQuery-minified.js is less buggy than jQuery.js?

Good thing it's dead

[MaxToTheMax]

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.

Re:Good thing it's dead

[jetole]

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.

You cannot write programs in any of those. They are not programming languages. They are markup languages. That's why they all have ML in each acronym. It's short for "Markup Language".

It's been superceded by Web Components

[Amtiskaw]

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.

Re:Visual Studio for ASP.NET

[evilviper]

With nearly 10x more users than 6 months before

Those figures are for IIS 8 specifically, not IIS in general. That just means a new version was released, and while only one guy way using it 6 months ago, there's now a few hundred active instances, so the statistics fly all to hell...

you are also hard pressed to find a graph which shows less than 40% IIS usage.

Netcraft says all Microsoft web servers, combined, total just 12% of active sites, as of Feb 2013: Google's own custom, in-house web server may soon surpass IIS in market share.

Meanwhile, Apache and nginx total 67% of the market.

http://news.netcraft.com/archives/2013/02/01/february-2013-web-server-survey.html

Re:Visual Studio for ASP.NET

[TheRaven64]

This is how you do decent shilling. Everything he said is true, his problem was his omission. The MS stack does provide a reasonable MVC programming model for web applications. So do a number of other competing frameworks, many of which are more scalable, free (to deploy and to get the dev tools), cross-platform (do you really want to be forced to run Windows on your server? Even if you like the platform, you'll pay more if you want to deploy it in something like EC2 because of the HVM overhead), and which have been around longer.

More languages is *not* what the web needs

[dingen]

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.

Guess I'm the one guy here.

[bobaferret]

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.

Re:Visual Studio for ASP.NET

[alexo]

Just remember that ISS is mostly used on internal servers. Netcraft doesn't and can't access that information.

Not true.

IIS may be mostly used on internal servers. The ISS is as external as you can get.