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.

28 of 138 comments (clear)

  1. Forgotten? by ChunderDownunder · · Score: 3, Interesting

    A Mozilla-only technology that no other engine supports doesn't really qualify as forgotten, even if someone submits it to W3C.

  2. Re:Visual Studio for ASP.NET by Chrisq · · Score: 4, Interesting
    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)
  3. Really? by Anonymous Coward · · 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.

  4. There is no Dana, only XUL by Anonymous Coward · · Score: 4, Funny

    XUL: Do you want this <body/>?

    Venkman: Is this a trick question or what?

    1. Re:There is no Dana, only XUL by slimjim8094 · · Score: 2

      For anyone unaware, they were quite aware of the Ghostbusters reference. The XML namespace is:

      http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul

      which of course links to:

      There is no data.
      There is only XUL!

      --
      I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
  5. Why is it dead: by psholty2 · · Score: 4, Funny

    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>

    1. Re:Why is it dead: by Cenan · · Score: 2, 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.

      --
      ... whatever ...
    2. Re:Why is it dead: by dkleinsc · · Score: 4, Insightful

      "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?

      --
      I am officially gone from /. Long live http://www.soylentnews.com/
    3. Re:Why is it dead: by Cenan · · Score: 3, Insightful

      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?

      --
      ... whatever ...
  6. Good thing it's dead by MaxToTheMax · · Score: 3, Insightful

    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.

    1. Re:Good thing it's dead by jetole · · Score: 3, 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".

    2. Re:Good thing it's dead by Giant+Electronic+Bra · · Score: 2

      JSON isn't even close to being as expressive as XML, and has HUGE issues, like character encoding which actually make it almost worse than nothing. Its fine for some casual stuff, but it lacks any realistic way to validate or generate a schema. S-expressions suffer the same problems.

      The problem here is the usual problem you have at /. which is that most of the people posting are casual and/or amateur system designers. When you get into the serious large-scale line-of-business infrastructure that is required for things like world-wide financial services, integrated medical records, supply chain integration, etc then you simply cannot afford to use messy ill-defined formats. XML is a HUGE boon to these systems because it can be validated and exactly defined even when very complex data is being transmitted. There's ZERO chance you're going to invent a syntax for transmitting the results of medical tests using some fixed format, XML is really your only choice, and with dozens of providers integrated into that kind of system you really need definitions that are both independent of the implementation and easily extensible.

      Anyway, this is definitely OT, though I must say, the lack of real understanding of what XML is about and the surrounding issues is probably why we have the craptastic uselessnes of HTML5 instead of something XML compliant that would have helped enable better web UI development. The last line of the OP is telling, indeed where did XHTML go? We need it more than ever now.

      --
      "Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
  7. It's been superceded by Web Components by Amtiskaw · · Score: 5, Informative

    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.

    1. Re:It's been superceded by Web Components by spiralx · · Score: 2

      There's some articles about the template tag, web components and custom elements. HTML5 Rocks has some articles on the shadow DOM as well.

  8. Re:Visual Studio for ASP.NET by evilviper · · Score: 5, Informative

    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

    --
    Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
  9. Re:Visual Studio for ASP.NET by Chrisq · · Score: 2

    If you only know Apache thats all you see acctually according to some websites IIS is the fastest growing. http://trends.builtwith.com/Web%20Server/growth#!sixMonths With nearly 10x more users than 6 months before, you are also hard pressed to find a graph which shows less than 40% IIS usage.

    Step outside your bubble before you make huge sweeping statements like this.

    Unfortunately the stats you refer to are for IIS8, and are linked to a corresponding decline in IIS6 as people upgrade. If you look at the stats for all versions of IIS on the site you link you will see that far from being the fastest growing, IIS usage as a whole is slowly declining.

  10. Re:Dojo / Dijit by Chatterton · · Score: 2

    I have tried very hard by 2 times to use Dojo to develop a web application (1st try in the 1.2 era and the 2nd try with 1.9 since a week).

    I get it somehow working with the 1.2 version with some workarounds (eg: I can't get it to insanciate a message box on demand. I have to have one hidden in my page, replace its content and display it when needed).

    With 1.9, I can't even get it to load some HTML to put an horizontal menu in a content panel. And all the examples I find on internet are from older versions of dojo.

    If I could just find some kind of template application with a login screen and a master/detail screen with the basic ADD/UPDATE/DELETE sub screens all done within one html page. I could start from that. But for now the examples are not enough to start using dojo has it should be used. And the available examples are diluted in the google results in a way that they are nearly impossible to find :/

    I contrast jQuery is simpler to use, get a lot of plugins to add what you need it to do and 'lighter' that you can split your application on multiple page without having a loading time betwwen user intercation too long making the application feel unresponsive...

    I like really the design of Dojo. But the step is too high for me to use it :( I should stick to jQuery :/

  11. Re:Visual Studio for ASP.NET by terjeber · · Score: 2

    Yeah, that terrible Microsoft. They have one technology, ASP.NET, which over time loses favor. As does all the similar Web technologies like JSP etc. It turns out that the whole thing with pages and code-behind is a bad idea. Along comes Ruby and Rails, and things change. Microsoft sees that this is a Good Idea(TM) and they make their own similar stuff. As does everybody else. Lots of cross-copying takes place. Microsoft makes the (arguably) best template engine (Razor) and the Java world copies that (Play! Framework).

    This is the natural way of things. Only when Microsoft does it it must be evil.

    Seems like the mental faculties of the average /. reader is dropping faster than one would expect something sitting in a standard 1G well.

  12. Re:Visual Studio for ASP.NET by TheRaven64 · · Score: 4, Insightful

    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.

    --
    I am TheRaven on Soylent News
  13. Re:Visual Studio for ASP.NET by Anonymous Coward · · Score: 2, Insightful

    No, the problem is that everything he said is off-topic

  14. More languages is *not* what the web needs by dingen · · Score: 4, 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/
    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.
    1. Re:More languages is *not* what the web needs by dingen · · Score: 2

      That's a creative use of the phrase "works fine".

      --
      Pretty good is actually pretty bad.
  15. Re:Visual Studio for ASP.NET by dkleinsc · · Score: 2

    In other words, Netcraft confirms it: Windows is dying.

    --
    I am officially gone from /. Long live http://www.soylentnews.com/
  16. Re:Dojo / Dijit by RabidReindeer · · Score: 2

    I have tried very hard by 2 times to use Dojo to develop a web application (1st try in the 1.2 era and the 2nd try with 1.9 since a week).

    I get it somehow working with the 1.2 version with some workarounds (eg: I can't get it to insanciate a message box on demand. I have to have one hidden in my page, replace its content and display it when needed).

    With 1.9, I can't even get it to load some HTML to put an horizontal menu in a content panel. And all the examples I find on internet are from older versions of dojo.

    If I could just find some kind of template application with a login screen and a master/detail screen with the basic ADD/UPDATE/DELETE sub screens all done within one html page. I could start from that. But for now the examples are not enough to start using dojo has it should be used. And the available examples are diluted in the google results in a way that they are nearly impossible to find :/

    I contrast jQuery is simpler to use, get a lot of plugins to add what you need it to do and 'lighter' that you can split your application on multiple page without having a loading time betwwen user intercation too long making the application feel unresponsive...

    I like really the design of Dojo. But the step is too high for me to use it :( I should stick to jQuery :/

    Consider yourself lucky. I had to refund 2 months worth of billing because my attempts to use dojo/dijit were such an abject failure that the client rejected it outright.

    Dojo was really hot when it was new, but I had the misfortune to try it when it was at a low spot. It also didn't help that I was attempting to plug it into someone else's DIY JS framework and they had mis-redefined core JS functions.

    jQuery has been a lot friendlier to me.

  17. Guess I'm the one guy here. by bobaferret · · Score: 3, 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.

  18. Re:Visual Studio for ASP.NET by alexo · · Score: 4, Funny

    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.

  19. Where are you keeping your inner cynic? by JoeMerchant · · Score: 2

    >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?

  20. Re:Visual Studio for ASP.NET by Xest · · Score: 2

    He didn't mention MVC, he was talking about WebForms so I don't think what he said is true, as all attempts to make web development like forms development to date has been complete and utter crap. WebForms forces you into a paradigm that often suffers impedance mismatch relative to the way the web and HTTP actually works in practice, and often can result in unnecessary transport overheard to support the faux event-based model.

    In contrast, I'd say their MVC implementation is actually quite excellent, and it scales as well as the competition- it's only really a handful of the Java alternatives that may scale slightly better (or a custom C++ solution, but that has it's costs in terms of increased development time and higher potential for security nightmares and serious bugs). Just about all of the other alternatives scale much more poorly - Ruby, PHP, and yes, I'm afraid even Python right now (even though it's a great language in it's own right). As such I wouldn't really say ASP.NET MVC has scalability as a concern, it's not one of it's weaknesses relative to the market in general, in fact, it's one of it's strengths in that it's the only true mainstream alternative to Java in most cases. The other things you say are however largely valid:

    - Cost is certainly true, though if scalability is an issue you will surely be working on something with a large enough budget that the cost of IDE is a negligible fraction of the total cost of development. This is also a cost that may even be paid for in increased developer productivity through having decent tools. Similarly the increased cost of Windows Server hosting isn't likely to be an issue if you've got a product that requires some reasonable degree of scalability, the additional cost is once again going to be a tiny fraction of your total costs, though if you're really trying to maximise profit margins this will have some impact. The cost thing is of course an issue if you're a lone developer or a small start-up, that's certainly true.

    - Cross platform, obviously a bit of a problem here and I agree. If you don't want to use Windows I wouldn't even bother looking at a Mono based solution, by the time you're done fucking around with Mono you may as well have just used Java or whatever in the first place.