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.
Comments
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.
> 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.
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.
/be
Sean: yeah, these approaches could help drive XBL interest and adoption. That'd be great.
~Grauw
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.
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.
/be
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