s web applications replace web pages on the Internet, there are a number of approaches that are being taken to add new functionality to these sites. One approach, the one perhaps most heavily used by applications, is programmatically controlling different parts of a web page via scripts and user events. In most cases, this process creates some form of binding on elements after the fact, which can often lead to fairly messy java-script code both in terms of long blocks of scripts and inline event handlers calling those java-script functions.
However, there’s another approach that may have the potential to both simplify your applications and contribute significantly to reuse. The idea behind it is deceptively simple: in a web page’s CSS page, you define what’s called a behavior, a script that binds to a given behavior language document written in mixed XML and java-script called the XML Binding Language (XBL). Once the page loads, any element that’s associated with that particular rule will gain the behavior, essentially acting as a new “element” with its own presentation, its own responses to user input, and its own underlying data.
XBL has been floating around in various incarnations since the early 2000s. Microsoft created a type of binding called behaviors in the late 1990s, but the technology never really caught on with other browsers. In early 2003, XBL was introduced in Firefox as one way of building extensions using the XML User-interface Language (XUL), though XBL wasn’t formally specified as a standard outside of Firefox. XBL bindings have worked in Firefox web pages almost from the inception of the browser, but again, other vendors didn’t follow suit.
In 2006, Ian Hickson of Google published the first version of the XBL 2.0 specification as part of the W3C Web Application Formats Working Group, based in part upon the Mozilla XBL 1.0 language but aimed towards rectifying a number of the design issues that tended to cause problems with the Firefox implementation. XBL 2.0 has been a candidate recommendation since 16 March 2007, but has been waiting for the required two formal implementations of XBL 2 to be submitted that are considered a necessary precondition for a working draft to become a formal recommendation (typically after a short “Proposed” status for final comments).
Mozilla announced in 2008 that they were looking to have an XBL 2 version likely with their 4.0 release … this effort is underway now, and it’s very likely that they will achieve this goal, especially with a formal candidate recommendation status that’s unlikely to change its underlying functionality.
Google, for it’s part, took an alternative route that’s similar to the approach they took recently with the SVG Web project. Rather than waiting for other browser vendors to adopt XBL 2, they’ve recently created a java-script based XBL2 code project at http://code.google.com/p/xbl/, with the code designed in such a way that it will work across any browser. Currently it supports all major browser versions produced within the last four years. While it doesn’t completely mitigate the requirement for scripting, implementing it within your web page only requires the addition of a single script element in the header of the document:
[xml][/xml]
Once included, any behaviors that are defined within the CSS stylesheet will be invoked, regardless of browser. Additionally, the xbl.js library (available from the project site above) also performs a check before calling the library to see if XBL2 support is enabled natively. If it is, then the code will defer to the (presumably browser optimized) XBL library that’s native to that platform.
Declaring a Twitter XBL Element
An interesting exercise, echoing something I’ve done previously on this site, is to build a mechanism that would take Twitter feeds and display the most recent messages in a person’s “friends” channel within a website. This isn’t a pure client solution: it assumes that there is a proxy on the same server as supplies the initial web page that communicates with twitter and passes a JSON stream back to the client. However, the
A typical web page that uses XBL can often seem remarkably clean and straightforward. In the case of the Twitter app, for instance, the code would look as follows:
Twitter Test Twitter Test
This is a Twitter Test.
What's perhaps most noteworthy here is the near absence of apparent java-script code, with the exception of the XBL library binding itself. The
where twitter.xml is the name of the file containing the XBL while #twitter indicates the XBL [xml]binding[/xml] with that particular id attribute within the file.
One effect of this is a clear separation of concerns, and a corresponding simplicity of code -- without the need for complex, undifferentiated HTML intermixed with code, the HTML content can be much simpler and easy to follow. This opens up the idea of navigational elements, header and footer elements and so forth simply being defined (or in some cases redefined) as XBL extensions.
In this case, the application so embedded presents itself as a set of input boxes for username and password to the respect Twitter account, a button for sending the content, and then a pane showing the most recent tweets. Once every thirty seconds, the application auto-updates (Twitter.com keeps auto-updates down to no more than 150 per hour, so thirty seconds between queries (120 per hour) fits within that envelope).
Additionally, the
Figure 1. Twitter Test: The link will appear in the frame.
Building a Basic Binding
The binding xml file itself consists of a containing [xml]
The