Figure 1. Structure of an XBL Document
This practical guide provides you with the knowledge required to effectively use the XML Binding Language 2.0. It introduces both the basic and advanced concepts of XBL and describes its syntax and scenarios that should be considered best-practice. It also describes the purpose of the language elements described in the XBL 2.0 specification.
XBL describes the ability to associate elements in one document with script, event
handlers, styles, and more complex content models in another document. You can use
XBL to re-order and wrap content so that, for instance, simple HTML or XHTML markup
can have complex CSS styles applied without requiring that the markup be polluted
with multiple div elements. In addition, if you are a programmer, you
can use XBL to implement new DOM interfaces, and, in conjunction with other
specifications, it enables arbitrary XML tag sets to be treated as "widgets"
(pluggable user interface components).
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the [DATE] First Public Working Draft of the XBL 2.0 Primer: An Introduction for Developers. This document is produced by the Web Application Formats (WAF) Working Group (WG). This WG is part of the Rich Web Clients Activity and this activity is within the W3C's Interaction Domain.
Web content and browser developers are encouraged to review this draft. Please send comments to public-appformats@w3.org, the W3C's public email list for issues related to Web Application Formats. Archives of the list are available. The editor's draft of this document is available in W3C CVS. A detailed list of changes is also available from the W3C CVS server.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
Please note that at the time of writing there are no implementations of XBL 2.0 publicly available, so everything in this document is untested.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
The move in Web development towards avoiding the table element for
layout has led developers to consider how to exploit other HTML elements, CSS, and
JavaScript to achieve complex layouts. To a large extent, this move has been fueled
by proponents of the Web 2.0 movement who promote the importance of having highly
accessible content that is both adaptive and provides an engaging user experience.
However, a new problem has emerged where by Web documents are now heavily 'polluted'
with the semantically-neutral div element and complex JavaScript and CSS
that is hard for authors to maintain.
The XML Binding Language 2.0 (XBL) is a declarative language that can be used together with existing or new Web documents to enhance their presentation, behavior, accessibility, and maintainability. This Primer is designed to provide you with the practical knowledge required to use XBL effectively in your work. It introduces both the basic and advanced concepts of XBL and describes its syntax and best-practices usage scenarios. It also describes the purpose of the language elements described in the XBL specification document.
The primary intended audience for the Primer is Web developers: that is, anyone who has some experience working with HTML, CSS, JavaScript, and perhaps some exposure to XML. This assumes that the reader is familiar with those, and other related Web development techniques and technologies. A second intended audience are XML developers who are considering XBL as a tool to enhance the behavior and programmatic functionality of DOM elements. Where relevant, we make note of advanced functionality of XBL specifically for XML developers or advanced Web developers.
We have written this document as a series of tutorials for developers who want to learn XBL in a 'hands-on' manner. We have made every effort to write this in a relaxed style that should be understandable by a large audience. While this is not a technical specification and it does not include any implementation details or requirements, this may still be a useful introduction to the concepts of XBL for people who are intending to implement the XBL specification.
Need to revise this section later!!!
XBL is a powerful and sometimes complex language with many features. In order to effectively demonstrate the relevant aspects of the language, we have split the primer into 6 chapters:
Conventions used in this document... any preferred conventions (eg. code conventions? figure styles? any exemplar Web sites?)? please suggest some.
XML Binding Language (XBL) 2.0 is a mechanism for extending the presentation and
behavior of a document. XBL 2.0 is based upon the original XBL 1.0 specification created
and implemented by Mozilla, though it has been significantly redesigned and is not
backwards compatible. One of the goals of XBL is to allow you to directly enhance the
user experience of Web documents without needing to overuse structuring elements,
such as the div element, in your HTML.
XBL provides various mechanisms to dynamically pre-load and include new content
and style sheets into a document, and to enhance HTML or XML elements with scripted
functionality. For example, an HTML input element can automatically
validate user input via a custom script that is bound to it using XBL. These features
potentially translate into a richer end-user experience and documents that are easier
to code, style, and maintain.
XBL is structured into several different components. The bindings are used to attach presentation and behavior to an element, and the scripts are used to define helper functions used by the bindings. The bindings are comprised of templates, event handlers, API implementations and resources (figure 1).
Figure 1. Structure of an XBL Document
A binding is a way to attach presentation and behavior to an HTML or XML element. The concept is similar to the way we already style elements using CSS and attach event listeners to them with JavaScript, but by adding an extra layer of abstraction in between simplifies the development process. Bindings are not a way to replace existing authoring tools like CSS and JavaScript, but rather an enhancement to them.
There are four main aspects of a binding: templates, handlers, implementations and resources.
Bindings can be attached to elements in several ways using:
element' attribute of the binding element via a
CSS-style selector [SELECTORS],binding' property in CSS,addBinding()' method in a script.We discuss these three attachment methods below.
To create a binding using the element
attribute of a binding element you need to specify a selector. It’s the
same type of selector that is used in CSS, so it’s very easy to understand.
This binding will be attached to all elements that match the selector: #nav
li.
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding element="#nav li">
<implementation>...</implementation>
<template>...</template>
<handlers>...</handlers>
<resources>...</resources>
</binding>
</xbl>
The
'binding' property can be used in your CSS to attach a
binding, in exactly the same way you apply any other other style to an element.
bindings.xml:
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding id="demo">
<implementation>...</implementation>
<template>...</template>
<handlers>...</handlers>
<resources>...</resources>
</binding>
</xbl>
The style sheet:
#nav li { binding: url(bindings.xml#demo); }
addBinding() methodElements will implement the ElementXBL
interface, which defines three methods: addBinding(),
removeBinding() and hasBinding(). The
addBinding() method can be used to attach a binding to an individual
element using a script, like this:
var e = getElementById("example"); // Get the element
e.addBinding("bindings.xml#foo"); // Attach the binding
It is also possible to check if a binding has been attached using the
hasBinding() function.
if (e.hasBinding("bindings.xml#foo")) {
// Do something
}
Bindings can also be detached using the removeBinding() function.
e.removeBinding("bindings.xml#foo");
As stated earlier, handlers offer an improved way to declare event listeners (eg. mouse and key events).
The following example illustrates some typical unobtrusive scripting
techniques to attach event listeners, including both the window.onload
property and the addEventListener() function.
window.onload = function() {
var nav = document.getElementById("nav");
var li = nav.getElementsByTagName("li");
for (var i = 0; i < li.length; i++) {
li[i].addEventListener("mouseover", doSomething, false);
}
}
Another common method is to use the HTML onevent
attributes, like the following.
<li onmouseover="doSomething();">...</li>
There are advantages and disadvantages to both methods, but the former is generally considered better because it separates the behavior layer from the markup. However, the latter is a simple declarative syntax that can be quite convenient in some cases.
In XBL, instead of requiring authors to use a script to search for the elements,
the event listeners are attached to those that the binding is attached to. XBL
provides a simple declarative syntax which also continues to separate the behavior
layer from the semantic markup layer. Event listeners are declared using both the handlers
element and its child handler
elements. For example, this binding will be attached to all li elements
within an element with id="nav".
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding element="#nav li">
<handlers>
<handler event="mouseover">
doSomething();
</handler>
</handlers>
</binding>
</xbl>
If present, only one handlers element is allowed within a
binding, but it can contain as many child handler elements as required,
to capture as many different events as you like. This binding declares a single event
handler that listens for the mouseover event. When the
mouseover event is fired on a bound element (i.e. an element to which
this binding is attached), the handler is invoked in effectively the same way it
would have been using the other methods shown above.
There are often times when you only want to handle an event under certain
conditions. For example, when you want to capture a click event and do
something only when the user clicks the left mouse button; or capture a keyboard
event and perform different functions depending on which key was pressed. In
traditional scripting techniques, you have to check the values of certain properties
using if or switch statements in your function, like the
following.
function doSomething(e) {
var code;
e = e || window.event;
code = e.keyCode || e.which;
switch(code) {
...
}
}
Much of that involves handling of incompatibilities between legacy browsers, but even if all browsers supported the DOM Events standard, it is still quite complicated. XBL addresses this by providing a simple declarative syntax for describing these conditions using attributes on the handler element.
In the following example, separate handlers are provided for handling
the
keypress events depending on which character was entered. The
first handles the character a, the second handles b.
If any other character was entered, neither of these two handlers will be
invoked.
<handlers>
<handler event="keypress" text="a">
doSomethingA();
</handler>
<handler event="keypress" text="b">
doSomethingB();
</handler>
</handlers>
Similarly, in the following example, the handler will only be invoked when the user left clicks while holding the Shift key down.
<handlers>
<handler event="click" button="0" modifiers="shift">
doSomething();
</handler>
</handlers>
There are several other filters that can be used. The following list is a subset of the available attributes for this purpose. These are expected to be the most commonly used filters because they cover the majority of mouse and keyboard event usage on the Web today.
buttonbutton="0 2" matches either the left or
right mouse buttons.click-countclick-count="2" matches
double clicks.textmodifierskeykey-locationstandard, left, right and
numpad.Templates are used to control the presentation of a document. They can be used to reorder and restructure content in the document without affecting the underlying DOM.
Templates are created using the template element within a binding.
The templating model allows you to combine elements from the document with additional
elements in creative ways, removing the need for unnecessary and extraneous elements
to be added to the original document. You could, for example, use XBL to extract the
data from an HTML table and present it as a chart using SVG.
An important concept to grasp is that regardless of what content you include in the template, the template does not alter the semantics of the original document. For example, in an HTML document, a heading could be bound to a binding with a template containing an SVG image. The bound element still semantically represents a heading, only its presentation has changed from plain text to an image. That concept shouldn't be too hard to grasp, that example (in principle) is not much different from any of the widely used image replacement techniques, it only differs in implementation.
The XBL content element can be used to insert content from the
document into the template. The includes attribute value is a selector,
used to select which elements to insert into the tree at that location. The
div element is provided as a generic structural element that you can use
for any purpose you like.
When elements are bound, the contents of their binding’s template are cloned and appended to them as children, creating shadow trees. Shadow trees exist outside of the normal DOM and are thus transparent to ordinary DOM processing. In other words, shadow trees are rendered as though they were part of the original document, but do not actually exist within the document itself.
<body>
<div id="main">...</div>
<div id="nav">...</div>
</body>
Using XBL, the content can be reordered and restructured, which will allow for more complex styles to be applied.
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding element="body">
<template>
<div id="container">
<div id="left"><content includes="#nav"/></div>
<div id="right"><content includes="#main"/></div>
</div>
</template>
</binding>
</xbl>
This will create the following shadow tree.
Need a diagram
The implementation element describes a set of methods and properties
that are attached to the bound element. That is, a way to enhance the bound
element’s DOM interface. For example, if you wanted to add custom
validation to a HTMLInputElement, you would need to do the following in
JavaScript:
var customInput = document.createElement("input");
myInput.max_value = 56;
myInput.checkValue = function() {
// Custom validation
};
That example illustrates the basic way in which we can add properties and methods to an already existing HTML element. Exactly the same technique can already be used to add properties and methods to an element, and this is similar to what the implementation element is designed to do. The equivalent to the example above in XBL would be.
<xbl xmlns="http://www.w3.org/ns/xbl">
<binding element="#customInput">
<implementation>
({
max_value: 56,
checkValue: function() {
// Custom validation
}
})
</implementation>
</binding>
</xbl>
In the HTML you would have:
<input type="text" id="customInput"/>
In this example, the binding is attached to elements matching the selector:
#customInput.
Resources include style sheets and additional files that are used by the binding, such as images, audio and video. The style sheets are used to add style to the binding’s template.
This section is incomplete
The XBL script element, which is similar to the script
element in HTML, can be used to define helper functions for your bindings.
Just like in HTML, scripts can either be script resources using the
script element's src attribute and declare as many script
elements as you need:
<xbl xmlns="http://www.w3.org/ns/xbl">
<script src="example.js"/>
<script><![CDATA[
function foo(){
example(); // Assume this is defined in example.js
...
}
]]></script>
...
</xbl>
In the following example, the doSomething() function that is defined
in an XBL script element will be automatically called when binding
foobar is attached to an element.
<xbl xmlns="http://www.w3.org/ns/xbl">
<script>
function doSomething(){...};
</script>
<binding id="foobar">
<implementation>
({
xblBindingAttached: function() {
doSomething(); // Calls the function defined in the script element
}
})
</implementation>
</binding>
</xbl>
The default scripting language is JavaScript. Other languages may be used by
specifying them with the script-type attribute on the xbl
element. Since JavaScript is the most common scripting language on the Web,
the default will usually be acceptable to most authors.
Functions and variables defined in the XBL script element are scoped
to the XBL document, so they cannot be accessed from the bound document. Conversely,
for security reasons, functions defined in the bound document cannot be invoked from
within the XBL document. For example, the following will not work:
<html xmlns="http://www.w3.org/1999/xhtml">
<xbl xmlns="http://www.w3.org/ns/xbl">
<script>
function bar(){...}
foo(); //error, foo is undefined!
</script>
</xbl>
<!-- script in the XHTML namespace -->
<script type="text/javascript">
function foo(){...}
bar(); //error, bar is undefined!
</script>
</html>
To be written...
To be written...
XMLHttpRequestTo be written...
To be written...
To be written...
To be written...
This section will be done once the rest is done.
The editors would like to thank the following people for their contributions to this specification: