XBL Forward

I’ve been working on investigating what it would take to make some improvements to XBL, either by implementing XBL 2 or something else. My motivation here is to improve the XUL widgets so that are easier to use, stabler and faster. I gave a talk at Fosdem outlining the various forms of XBL at present and possible routes forward in the future. There are three possible ways forward.

The first option is to implement the XBL 2 specification as is. There are two versions of this specification, the original one, created in 2007, and a newer version, created in 2010, that removes a number of features.

The advantages of this approach:

• Already has a complete specification that underwent some design already.
• To some degree, it builds on top of the existing XBL, so we may be able to build some features incrementally.

Disadvantages:

• As no other browser has implemented or attempted to implement it, there isn’t any reason to implement it as is.
• For internal use, a specification can restrict certain extended features that will be needed. These include connecting to native components as well as accessibility.

Approach two involves a set of new features being designed by Google, under the umbrella term Web Components.

Advantages:

• The design here is broken into several smaller features, rather than having one large feature. This may make doing the implementation in stages easier.
• Since Google is already working on this, it is likely an easier route to multiple compatible implementations.

Disadvantages:

• The features described aren’t necessarily better design, just different, and likely don’t encompass all of the design issues we’ve experienced.

A third approach is to take the existing XBL implementation, and simply improve the features that we don’t think are working as well, and enhance or replace those parts with implementations that are more robust, offer better performance and are easier to use. In addition, new features would be added to address shortcomings, generally from the XBL 2 specification or otherwise where they are useful.

Advantages:

• Likely easier to implement, as it builds on top of an existing implementation.
• It has no constraints on others to design or agree on a specification, so features can be designed to fit our needs

Disadvantages:

• The main disadvantage is that is use would be limited to Mozilla’s own use internally.

I’ve spent much time over the last few months trying to determine which approach is best.

XBL belongs to a larger class of application that is attempting to allow for component creation, abstract representation and general templating mechanism. There are many tools and libraries available both running on a client and a server that attempt to provide these types of features. XBL attempts to solve specific use cases, but doesn’t attempt to solve others. One way to design XBL would be to allow it to solve the more complete set of component and template generation features.

For example, the documents for Web Components describe some examples of templating, which XBL doesn’t address directly. Although it doesn’t specify a syntax, it gives an example containing a tag written as: <li class=”${importance}”>. This implies that some form of value substitution is desired. XBL only provides attribute substitution in a limited form. Does this mean that XBL should be extended to allow a more sophisticated template mechanism to allow the markup structure to be changed in more powerful ways?

Naturally, the more features added, the more complicated the implementation will become. More importantly, it becomes much more difficult for multiple implementations or their users to agree on a common syntax. Indeed, the presence of Web Components and multiple XBL specifications implies that such agreement is difficult. Another example of this is persistent storage in a browser. Several variants have been proposed and/or implemented, including a key/value storage mechanism (localStorage), an SQL database syntax, and IndexedDB. There are probably others, and some use cases are not covered by all of these. Do we simply choose one or some of these and ignore the remaining use cases?

Mozilla hasn’t shown any interest in implementing XBL 2, and neither have any other browsers. So it seems to me that XBL is one of those areas where having a specification hasn’t served much purpose.

If I were implementing the future of XBL today I would favour approach three that will get useful functionality implemented faster. This is for several reasons, one, is that I don’t feel that consensus on anything beyond a basic set of features will happen any time soon, or at all. Two, spending extensive amounts of energy working on trying to create and/or expand on some form of multi-vendor specification isn’t interesting to me, as I don’t care about web development. Third, since I’m talking about what I would do if I were implementing it, it’s the simplest way to improve the XUL UI widgets we have.

I wrote the start of a feature page.