Wednesday, July 25th, 2007

XBL 2.0 Primer

Category: JavaScript

The W3C’s Web Application Formats Working Group has published the XBL 2.0 Primer, which provides a developer-friendly introduction to the XBL 2.0 Specification. XBL stands for the XML Binding Language and serves as a presentational and behavioral layer above XML. XBL will one day allow you to easily implement new DOM interfaces using JavaScript (complete with an inheritance model) and create custom reusable components. Once browser vendors implement XBL, it could potentially have a significant impact on the way we design and build web applications. Amongst other things, XBL lets you:

  • Create custom UI widgets on-top of DOM Elements without changing the underlying DOM,
  • Dynamically reorder content in a document,
  • Easily declare complex event handlers,
  • More completely separate the markup and behavior,
  • Reduce the number of divs and spans in web documents,
  • Dynamically pre-fetch media and style-sheets,
  • XBL’s application is, of course, not just limited to web applications.

To show some of the features and syntax of XBL, here’s a hypothetical example of the game Space Invaders in XBL. Note the use of inheritance and the use of CSS-style Selectors to apply a binding.

  1. < ?xml version="1.0"?>
  2. <spaceinvaders xmlns:html="">
  3.     <city name="metropolis">
  4.         <invader /><invader /><invader />
  5.         <defender />
  6.     </city>
  8.     <xbl xmlns="">  
  9.         <!-- import whatever global scripts you need  -->
  10.         <script src="AnimationLib.js" />
  11.         <script src="AjaxLib.js" />
  13.         <binding id="ship">
  14.             <implementation>({
  15.                 this.missiles: 10,
  16.          50,
  17.        = function(){...},
  18.                 this.move = function(direction){...}})
  19.             </implementation>
  20.         </binding>
  22.         <!-- bindings is attached to all invader elements -->
  23.         <binding element="invader" extends="#ship">
  24.             <implementation>({
  25.                 // invader logic...
  26.             })
  27.             </implementation>
  29.             <!-- replace the invader element with an image-->
  30.             <template>
  31.                 <html :img src="spaceInvader.png "/>
  32.             </template>
  33.         </binding>
  35.         <binding element="defender" extends="#ship">
  36.             <!-- deal with keyboard events -->
  37.             <handlers>
  38.                 <handler event="keypress" text="a">
  39.                     move("left");
  40.                 </handler>
  41.                 <handler event="keypress" text="d">
  42.                     move("right");
  43.                 </handler>
  44.                 <handler event="click" button="0">
  45.                     fire();
  46.                 </handler>
  47.             </handlers>
  48.             <template>
  49.                 <html :img src="defender.gif"/>
  50.             </template>
  51.         </binding>
  52.     </xbl>
  53. </spaceinvaders>

In the upcoming chapters of the primer, we want to show developers how XBL can be used with Ajax, how to transform, for example, an HTML table into an animated SVG graph. WAF is currently looking for people to help write the remaining chapters of the XBL 2.0 Primer.

Posted by Dion Almaer at 6:56 am

1.3 rating from 266 votes


Comments feed TrackBack URI

‘you will one day be able to’ – does this mean Opera, WebKitSafariAppleKDE, and IE have ligned up to support this?

it appears to be another way of doing the same thing with the side effect bloat/complicate browser implementations who choose to support it and raise barriers of entry into the space even more. all the bullet points above could just as well apply to HTML5/DOM..

i guess XUL is built in XBL or something? a nice diagram would be useful to show where this fits into place

Comment by c — July 25, 2007

why is xbl needed, i mean really. whats the point

Comment by Jaimz — July 25, 2007

if you read it, you’d see the point is to further separate content from presentation.

having just read the spec, id summarize XBL as an XSLT which instead of transforming to another XML document, transforms to an in-memory DOM tree, replete with event bindings etc. script tags are gone in favor of elements named like handler, binding, etc.

but.. you can already serve your content as JSON or XML, and transform it with your dom-generation lib of choice in JS. or serve semantically-uncluttered/minimal/crawler-friendly HTML and add your app goodness in the client and 99 times out of 100 it will be more readable than this ‘custom subset of DOM API hacked into custom XML element attributes aned node names’ since your lib was made by a hacker who values concise code, rather than ‘everything needs to be written in XML’.

im sure some hardcore XML fiend out there will find this cool though..if those exist anymore

Comment by ix — July 25, 2007

XUL uses XBL (1.0 I think) for many, many widgets (text boxes, autocomplete, toolbar buttons, dialogs… nearly everything). Gecko even uses XBL for html elements.

It’s like unobstrusive JavaScript… but with all the code for detecting the nodes to apply the code to moved from the script to the browser(‘s css engine).

Comment by malte — July 25, 2007

Cool! Being an ASP.NET developer (don’t shoot me), it reminds me of how we already do server-side XML templating and behavioral markup, but here it’s client-side and declarative of both the HTML DOM and Javascript behavior. Very nice. I would love to see this supported in web browsers.

Comment by Jon Davis — July 25, 2007

This sounds great. I love the handlers.

Comment by Richard Kimber — July 26, 2007

If you search W3C archives, you may find out that HTC (Hyper-Text Components) from Microsoft was evaluated for some time as standard. Now it’s clear that HTC proposal is abandoned (mostly by MS itself that put no effort into this project for more then 5 years).

XBL (or HTC) is in fact truly necessary, see comments above. However, I think it would anything but practical as final result:
1. Would IE ever support this? I bet the answer is “no”.
2. How it is aligned with other standards for W3C Web Applications initiative? Most importantly, is there any connection with xForms? It looks like W3C runs several competitive standards at the very same time…


Comment by Valery Silaev — July 27, 2007

Leave a comment

You must be logged in to post a comment.