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.
Really? (Score:5, Informative)
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.
Re:Good thing it's dead (Score:4, Informative)
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 (Score:5, Informative)
It's been superceded by Web Components: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html [w3.org]
That's why it's dead.
Re:Visual Studio for ASP.NET (Score:5, Informative)
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...
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 [netcraft.com]
More languages is *not* what the web needs (Score:5, Informative)
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/ [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.