Forgot your password?
typodupeerror
Technology

The Forgotten Macro Language of HTML: XBL 2.0 138

Posted by Unknown Lamer
from the no-nice-things-for-you dept.
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.
This discussion has been archived. No new comments can be posted.

The Forgotten Macro Language of HTML: XBL 2.0

Comments Filter:
  • Forgotten? (Score:4, Interesting)

    by ChunderDownunder (709234) on Tuesday April 16, 2013 @03:56AM (#43459115)

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

  • Really? (Score:5, Informative)

    by Anonymous Coward on Tuesday April 16, 2013 @04:03AM (#43459133)

    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.

  • by Anonymous Coward on Tuesday April 16, 2013 @04:05AM (#43459139)

    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.

  • by psholty2 (2696677) on Tuesday April 16, 2013 @04:11AM (#43459165)
    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: (Score:3, Interesting)

      by Cenan (1892902)

      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 yo

      • by Anonymous Coward

        Short == Better when it is a website with millions of people accessing it. Every single BYTE counts.

        Also, HTML Templating exists too.

        And finally, the reason it was gone isn't because of this, but because Web Components (parent of Templating) is what replaced it.
        It is far more in line with HTML than generic XML is. XML is painful.
        Web Components Spec [w3.org]
        Templates are deliciously simple to work with as well.

        • by Cenan (1892902)

          Yep, short is better when every byte counts. The point was though, that OP was comparing oranges to apples. Following that argument and filling in the blanks doesn't lead to the conclusion that he would like.

      • Did you know us coders only have limited number of KEYUP events before we die.
      • Re:Why is it dead: (Score:5, Insightful)

        by dkleinsc (563838) on Tuesday April 16, 2013 @07:43AM (#43459787) Homepage

        "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: (Score:4, Insightful)

          by Cenan (1892902) on Tuesday April 16, 2013 @09:09AM (#43460421)

          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?

          • by Qzukk (229616)

            maybe it's just me being way too familiar with XML style syntax.

            I think so, because I find

            #nav li {
            onmouseover: doSomething();
            }

            to be more understandable than EITHER of the xbl or jquery examples. Sadly, the CSS people don't want to add javascript and nobody stepped up with a cjs (other than this [wikipedia.org] but it's just css with javascript, not cascading javascript sheets).

            • by Cenan (1892902)

              Much appreciated.
              Simplicity is in the eye of the beholder. I have a preference due to experience and training, and so do you. Discounting one technology because it takes a few more lines to clearly define intent for all instances, as opposed to defining it for one instance with one line, is being a religious zealot, a troll, a retard or possibly a combination of them all.

    • 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 [w3.org]) model was more successful in attractin

    • by higuita (129722)

      you can also format the layout of a page with tables, its may also be much shorter than CSS!!

  • by MaxToTheMax (1389399) on Tuesday April 16, 2013 @04:16AM (#43459183)
    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.
    • by Anonymous Coward

      Yet it's popular. Alright, not entire programs, but recall that there isn't just one, but three xml-y query languages. Just the thing if your business logic language manages to feel yet more like a straitjacket. Just look where their use is popular.

      To me the whole thing is rather useless as a data format too, since it's rather hard to parse correctly (no, "just use a library" is not a valid counter for observing that the format is hard to parse--libraries do not make complexity go away, they just hide it un

    • by jetole (1242490) on Tuesday April 16, 2013 @04:30AM (#43459231)

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

    • by Xest (935314)

      I take it you never really liked Coldfusion then?

      Seriously though, I don't really know why people bitch about XML etc. being ugly. It may be true, but of all the alternatives I've seen they're all just as bad, and often even have more quirks and of course, completely lack any level of worthwhile support.

      Come up with something better, then you can complain.

    • "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."

      You have a replacement in mind?

      Sure, XML has its faults, but so far there are no direct replacements... nobody has yet had a better idea, for doing what XML does.

      XML was designed to be easily machine-readable AND human-readable. That is what it is for.

      The only viable "replacement" these days is JSON, and JSON sucks really hard, because all the faults you list for XML are even more true for JSON than XML: it's hard to read, the syntax is ugly, it is awesomely annoying to hand-edit (far worse than XM

      • by pspahn (1175617)

        Keep in mind also that XML is intended to describe documents... it was never intended to be used in a manner that is now currently being shoe-horned into since there is nothing particularly better.

        JSON, on the other hand, is intended to describe objects... sure, these objects might possibly be document objects, but that is not always the case.

        While they do similar things, they are not, nor are they intended to be, the same thing.

        • "Keep in mind also that XML is intended to describe documents..."

          No, it wasn't.

          XML was designed to represent arbitrary data sets. Virtually any data at all. Hence its name "Extensible Markup Language".

          • I think you have XML confused with HTML, which is a subset of XML originally intended to represent documents.
            • by lgw (121541)

              SGML is a very flexible language created (pre-web) to be a universal document format - or perhaps a meta-format. With the proper definitions you can make legal SGML that looks like wiki markup, or .ini-files, or just about anything with a consistent grammar.

              XML and HTML were both subsets of SGML. XHTLM (the failed alternative to HTML5) was an attempt to unify the two, but "normal" HTML is far from legal XML.

              Getting started with SGML is pretty tough - it's so flexible that actually doing anything concrete

              • by radtea (464814)

                Although you're more correct than most of the people posting here, much of what you say is wrong.

                SGML is a very flexible language created (pre-web) to be a universal document format - or perhaps a meta-format.

                Meta-format is close. SGML is a language for defining markup languages. That's what the "G" is about (it stands for "Generalized" but should have been an "A" for "Abstract"). You're correct that with suitable clever ticks you can make almost anything a valid document against some SGML language. The "" to "/>", which is very clever but incompatible with HTML.)

                SGML plays the same role in markup languages th

                • by lgw (121541)

                  XML would be "just fine" if you could close tags with "</>". That's really the biggest problem. Long element names are sadly common, and that usage makes XML more noise than signal, for both human and machine reading. JSON just works far better for human-maintained small config files (i.e., as a replacement for ini files).

                  I've written a very lightweight XML parser (for use in the kernel - no library calls or recursion or anything) - it just ignored DTDs. XML is overkill for simple object representa

                  • "XML would be "just fine" if you could close tags with "". That's really the biggest problem. Long element names are sadly common, and that usage sometimes makes XML more noise than signal, for both human and machine reading."

                    There. Fixed that for you.

                    XML that is more noise than signal is poorly designed (usually poorly thought out) XML.

                    Having said that, I agree that an abbreviated closing tag would probably be a very good thing, at least in many cases. If it were up to me I would definitely include it as an option.

              • "XML somehow became popular for serializing data, but it's just not a very good tool for that. JSON is far simpler and less verbose for object serialization, but I couldn't see using it for sparse document markup."

                No. XML became popular for doing that because it was designed for that and it's good at it. It can easily represent nearly any data you can throw at it, and it has the advantage that it is relatively easy for people to read, too.

                Granted, XML can be a bit verbose at times, but depending on your data that can be a good thing.

                JSON is certainly more lightweight, and somewhat easier to parse programmatically. So I won't argue that it's not more efficient for small collections of data, if that is your prefe

                • by countach (534280)

                  XML is *** NOT *** very good at representing arbitrary data. It is very biased towards hierarchical data. It's not very good or very standardised at representing non-text data. It's VERY verbose, making it very bad at some kinds of data. That's just scratching the surface. No, XML is BAD at representing arbitrary data, but it is the most standard thing we have right now.

      • by Jmc23 (2353706)
        lisp
  • by Amtiskaw (591171) on Tuesday April 16, 2013 @04:48AM (#43459283)

    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.

    • by Anonymous Coward

      See also http://www.w3.org/TR/shadow-dom/ and http://www.w3.org/TR/components-intro/

    • by spiralx (97066)

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

    • by Flammon (4726)

      Web Components will be useful when theyr'e eventually implemented in browsers other than WebKit but a better solution already exists and is supported by all major browsers. JavaScript. It can be just as declarative as XML, more succinct and much more powerful.

      Here's how I write my web apps lately.

      var saveButton = new Button({
      label: 'Save'
      , busyLabel: 'Saving...'
      , timeout: 30000
      }).placeAt(container);

      • XBL still allows for an easier code reuse. You just xbl:include needed components on the page and add proper styles in CSS.

        Not that it can't be done in JavaScript, but with it every library has its own solution, which makes it hard to reuse components from different libraries. So, while this *can* be done now, standard solution (XBL or not) would be AWESOME!

    • What browser currently supports this? Or at least declared that it will support it?

  • by ExploHD (888637)
    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.
  • by dingen (958134) on Tuesday April 16, 2013 @06:34AM (#43459555)

    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.

    • by garyoa1 (2067072)

      Yeah, well cross browser compatibility seems to be a thing of the past. A lot of problems have been turning up for a lot of folks lately. Need to fill out a form? Won't work? Change browsers... works like a charm. That new browser won't fill out another form? Try another browser or maybe even your original browser. Works fine.

      • yup. i need to use firefox when selling on ebay cuz chrome doesn't work right; photobucket chokes on firefox, gotta fire up chrome to access certain features...
      • by dingen (958134)

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

      • "Yeah, well cross browser compatibility seems to be a thing of the past."

        Huh?

        That's not a problem with "cross-browser compatibility". That's a problem with shitty web design that doesn't properly use the standards. There is a pretty big difference.

    • The absolute minimum a developer needs to know in order to create a web application these days is: ....

      Don't be silly. Web development is easy. Just this week a wise person right here on /. told me an 8-year old child can do it.

    • "The absolute minimum a developer needs to know in order to create a web application these days"

      You forgot XML or (probably and) JSON. And knowing how to use at least one good graphics manipulation program, probably more. And intimate knowledge of your editor.

      • by ultranova (717540)

        And intimate knowledge of your editor.

        I guess that's one way of getting craptastic works published.

  • by bobaferret (513897) on Tuesday April 16, 2013 @08:29AM (#43460003)

    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.

  • by JoeMerchant (803320) on Tuesday April 16, 2013 @09:26AM (#43460607) Homepage

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

  • [...]separate object contained with in it self.

    Honestly, is this where the English language is headed? Breaking up words until all sense is lost?

Happiness is a positive cash flow.

Working...