Eyes Above The Waves

Robert O'Callahan. Christian. Repatriate Kiwi. Hacker.

Friday 7 March 2008

NOT A Cross-Browser Implementation Of XBL2

This project may be cool, but it doesn't --- and can't --- make the XBL binding nodes anonymous, which is the single biggest feature of XBL. Without anonymous nodes you lose a lot of the modularity and transparency benefits, and because you smash the original DOM you cripple the ability of the client to manipulate the DOM after the script has been applied.

So what we have here is a DOM preprocessor which uses XBL2 syntax, which does sound cool and useful, but it's not remotely an "implementation of XBL2". The blurb on the project's Web site is very misleading. It's also misleading when people who should know better blog as if the claim was true.


Sean Hogan
OTOH, if it quacks like a duck...
What are the use cases for modifying the DOM after the binding is applied?
Are there any that couldn't be satisfactorily addressed with functions added by the binding?
e.g. we already have different DOM interfaces for different elements: childNodes, removeChild(), rows, deleteRow(), options, remove()
I don't think anyone will balk at having: tabs, removeTab, etc
XBL2 (even a JS implementation) can standardize the way element behavior is enhanced. You can ditch toolkit specific attributes, elements. Just use good semantic HTML and change your behavior in the same way as you change your style-sheets.
The only new things I can see native XBL2 facilitating (apart from speed) are:
- dynamically switchable bindings, and
- safe cross-site widgets, but I doubt that the security implications have been fully thought out.
Of course, I could be very wrong. Plus I'm biased because I'm also working on a JS implementation of XBL2. See http://www.meekostuff.net/xbl2
I'd be quite interested in your thoughts.
Robert O'Callahan
> What are the use cases for modifying the DOM
> after the binding is applied?
Adding or removing items in an XBL-defined container?
Sure, you can add per-container APIs, but that makes XBL-defined containers distinctly second-class citizens, and makes life harder for developers who should be able to get by using only the regular DOM APIs.
Anonymity also helps developers by hiding binding implementation details from Firebug and other tools, and prevents developers from accidentally depending on binding implementation details, yielding more robust code.
Anonymity is also needed if you want to apply XBL easily to existing code, especially if that code is not under your control. XBL2 was specifically designed so that you can change the implementation of an element and be *sure* that you're not going to break anyone who's using it, even if you don't have their code in front of you, even if they hate you.
Again, I think this kind of JS preprocessing is cool. I just think this particular project is oversold.
Sean Hogan
Okay, so it's not worse than the current solutions.
And when native XBL2 implementations are available and there are a decent number of XBL2 bindings floating around, I suspect that there will be a significant subset (perhaps a majority) of those bindings that Just Work in JS XBL implementations. Maybe not in the edge cases, but in the majority of scenarios.
But I wonder how many sites are going to use XBL at all if it isn't usable on IE. From that perspective the JS implementations could even help save XBL.
Time will tell, unless it doesn't.
Brendan Eich
Could this become a propert XBL2 implementation with just one or two native helper functions?
Robert O'Callahan
Brendan: No. In XBL2 the anonymous nodes belong to their own bindings document, not the client's document. There are lots of other issues with providing full anonymity, like event propagation hiding the original target, CSS selectors working properly, etc.
Sean: yeah, these approaches could help drive XBL interest and adoption. That'd be great.
Laurens Holst
You’re pretty harsh. Is Mozilla even actively implementing XBL2? Any other browser?
Sean Hogan
Brendan: Are you asking if one of the JS implementations could be made into a browser extension that does comply?
I'm not sure if my approach would lend itself to this - I'd definitely be considering other solutions if I was to do this.
You are probably better off asking Mr Ilinsky about his implementation. I haven't implemented any of the shadow-tree stuff.
Anyway, I'm usually keen to show my ignorance. I'd want:
- effectively two DOM trees - the physical (what the user sees) and the virtual (where original document and scripts live).
- private properties on elements (or unique ID's).
- DOMSubtreeModified to work.
- hooks into the CSS engine.
- also style resetting / scoping.
- Oh yeah, and to be exempted from the same-origin policy.
I haven't given any thought to elements prior to insertion into the DOM. And probably other stuff too numerous to mention.
Anyway, I've convinced myself that my implementation isn't a good base for a conforming browser extension.
A lot of the complexity disappears for the (probably common) cases of bindings with no xbl:template or bindings attached to childless elements, which I think covers pretty much everything in web-forms2. Anyway, that is where I will be aiming with my implementation.
Brendan Eich
I'm asking what the simplest thing that would possibly "work" in the full sense roc rightly wants might be. What native APIs do we need for binding document, event propagation, etc., such that the code from ilinsky.com with added calls becomes a proper XBL2 implementation.
Maybe this is backwards, but it seems worth a moment's thought. I don't relish a full C++ XBL2 implementation if it's not needed, and if much of the code has already been written in JS.
Sean Hogan
The XBL implementation would need hooks into pretty much all the DOM accessors / modifiers so as to present the relevant DOM tree for the different contexts: bound-document, binding-documents.
You'd need JS sandboxes to create the binding document contexts. You probably already have that.
Event handling is the simplest part of the implementation. I'd be surprised if you need to add much. TextInput events?
You'd need hooks into the CSS engine, and the ability to block styles from applying in a shadow-tree.
There are some special elements like <input> which don't ever allow their children to be displayed (for obvious reasons). You'd need to find a work-around for that - they will be the most commonly bound elements.
Thoughts? You can contact me directly if you want. shogun70 westnet com au
I still have difficulty understanding why xbl2 is needed when Mozilla already has xbl, fwiw.
Robert O'Callahan
XBL1 is very poorly designed.