Neil's Place

March 30, 2012

XBL Forward

Filed under: Mozilla — enndeakin @ 4:50 pm

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.

About these ads

10 Comments »

  1. “I don’t feel that consensus on anything beyond a basic set of features will happen any time soon, or at all” … why do you feel that? Is there anything particularly *wrong* with Web Components? If so, it would be great if you could provide feedback.

    “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.” … I think probably you should care about Web development. Mozilla should prefer to invest in technologies that will be part of the open Web platform, over those that won’t.

    Comment by rocallahan — March 30, 2012 @ 5:12 pm

  2. Nice to see XBL being developed again – in the last few years it was basically in “maintenance mode” with any change proposal answered by “this will have to wait for XBL2″.

    Concerning your spec, section “Content Include Filters”: insertion points aren’t currently restricted to tag matching, they accept XPath expressions as per spec and one can specify attributes for example. It doesn’t quite work reliably however (I analyzed the issue a while ago but don’t remember it was exactly).

    Comment by testtrev — March 30, 2012 @ 6:12 pm

  3. The descriptions of XBL and other related technologies always try to say that they allow the construction of widgets in ways that CSS and JavaScript doesn’t. Why not just enhance CSS and JavaScript so it can?

    Comment by Anonymous — March 30, 2012 @ 6:46 pm

  4. Coded XBL many years ago. IMHO, XBL is not that easy to read. As far as I understand, the biggest advantage of XBL is self-contained modules encapsulation. Just keep the main DOM slick. That’s what shadow DOM and scoped styles are trying to solve. Web component is larger topic. It’s a great opportunity to ditch XUL and XBL, no?

    Comment by fxwan — March 31, 2012 @ 6:28 am

  5. I don’t really care which one it will be but I truly believe a XBL-like technology is highly needed on the Web and that should be the main argument taken into account.

    Comment by sonny — March 31, 2012 @ 7:40 pm

  6. For your needs – improving XUL – it seems obvious that improving the current XBL implementation is the quickest way forward.

    For the needs of web-pages, javascript libs, etc I think the Web Components approach is more appropriate because the smaller features will be:

    - independently useful
    - more quickly implemented
    - used in unpredicted ways which will give better feedback on how XBL should really be specified.

    I suspect that, once Shadow DOM and Mutation Observers are implemented, javascript libs will fairly quickly fill in the gaps.

    Anyways, let a thousand flowers bloom. http://www.phrases.org.uk/meanings/226950.html

    Comment by Sean Hogan — April 1, 2012 @ 9:00 pm

  7. We have a Remote XUL app (well, suite of apps) which relies heavily on XBL (12k+ lines of it). With Remote XUL being deprecated we began to create an XBL2 version using Sergey Ilinsky’s JS implementation – the lack of a real shadow DOM caused some issues, but nothing we couldn’t work round. Our hope was that we could use the JS library as a shim until browser vendors began to implement native versions, but it became obvious that no browser vendors were actively working on it. With the ESR release of Firefox we have a period of stability and assurance for Remote XUL that has caused us to stop our XBL2 development and just wait to see what happens. We’re desperately hoping that either XBL2 will pick up steam, or that _something_ else (Web Components?) will come along to serve the same purpose.

    If Web Components has some traction and is likely to see adoption in other browsers, then I would suggest going with that. I like XBL/XBL2, but I’d rather back the horse that stands a chance of winning. You may be thinking mainly about the internal benefits for Gecko/XUL, but if you can also create something that is useful for the web at large, then why not? You’re likely to produce code that gets more widespread testing which can only be good for everyone, and it may even make it more approachable (or worthwhile) for other developers to work on.

    The web at large desperately needs a cross-platform component model, and I’d love to see your history and experience with XBL feeding into that process. It will be better for Gecko in the long run, too.

    Comment by xav12 — April 2, 2012 @ 7:35 am

  8. As we are moving to more and more “HTML5″ UI design, we badly feel, e.g. in B2G discussions, but also with web app developers in general, that templating in various forms as well as widget design, theming, extension and creation are recurring topics that a technology like XBL2 or web components could cover at least to some degree. I’m pretty sure we will need something to move there at some point.

    Is there any way we could sit down with that guy/team from Google who came up with web components stuff and maybe find out some way together how we can create something that fulfills both his and our (XBL) requirements? In the light of HTML5 being the future, I think using our collective experience from XBL etc. and put it into something new that can end up as a spec would be quite a good way to go. (And, yes, sorry, I guess that comes out as some kind of option 4 or your three.)

    Comment by Robert Kaiser — April 2, 2012 @ 8:49 am

  9. With add-ons devs moving away from XUL (and being encouraged to by Mozilla), the only real winner of improving current XBL is Firefox. I would certainly describe myself as a XUL programmer and have used XBL extensively, but more and more I am programming for the Web these days. The features from XUL I would love to see the most in HTML are the box model (on it’s way with flexbox and other initiatives) and XBL.

    For approaches #1 and #2, though not ideal in their current form, they are at such an early stage that there is still plenty of room for re-shaping. This would be a good area for Mozilla to lead.

    Comment by bwmk — April 2, 2012 @ 12:34 pm

  10. Neil, I would like to turn the disadvantage you listed for Web Components into an advantage:

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

    Let’s frickin’ make sure that the design issues are addressed! The line is open, and all you need to do is pick up the phone (or erm.. email :) Let’s work together. The reason why only Googlefolk is driving Web Components now is because no other vendors had shown active interest in getting their hands dirty. And that makes me sad, because a one-sided view is guaranteed to miss important use cases.

    As for option #3, I shudder at the thought of you guys to considering a one-off implementation of some binding mechanism that only works in Firefox. That seems like a step back. Faster, sure. But faster in the wrong direction.

    Comment by Dimitri Glazkov — April 18, 2012 @ 3:03 pm


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Shocking Blue Green Theme Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: