Subject: [sXBL] Various issues in the sXBL draft -- section
6 - msg#00079

I'm somewhat wondering what security issues, if any, there are in the XBL DOM. My first instinct is that all access to any of the XBL DOM properties must have same-origin security checks... but that makes it hard to create reusable bindings that pages load from a single location. Then again, perhaps that's desirable.

I'd love to hear people's thoughts on this.

6.1

The term "nodes that support XBL" is used here without being defined. It's not clear to me what nodes should implement the NodeXBL interface... Should Element nodes? Text nodes? Comment nodes? Attribute nodes? Document nodes? Entity reference nodes?

In the definition of xblChildNodes, the term "true children" is used. This term is not defined anywhere. Perhaps the documentation should simply clarify that this is the list of all nodes that have the given node as an xblParentNode, in their flattened-tree order?

It's not completely clear to me how xblScopedChildNodes differs from xblChildNodes. Which nested bindings should be ignored, exactly, to determine this nodelist?

I'm not quite sure why the xblFirstElementChild, xblLastElementChild, xblPreviousElementSibling, xlbNextElementSibling are needed.... Are there really very common use cases for these?

6.2

Just extending Event is perhaps a bit of an issue, from my perspective as a Mozilla implementor. Since the interface is part of a W3C Recommendation and has been for years, it's part of the frozen API Mozilla exposes. As such, we cannot change it. If it does get extended like this, we will probably do what we did when DOM3 Core extended the DOM2 Node interface -- put the new methods on a totally different interface (XBLEvent, probably), and make it possible to get from an Event to an XBLEvent via binding-specific casting methods.

Clearly implementations that postdate the creation of this specification would not be operating under any such constraints. At the same time, I'm not sure whether it's good precedent that specifications should just extend interfaces defined in other specifications. Even doing it for DOM3 vs DOM2 was problematic, as you can see; consider what happens if several working groups all extend Event in different ways.

6.3

I assume getElementByID means "descendants in the DOM Core sense" when it talks about only searching the shadowTree element and its descendants, right? That may be worth clarifying.

What is the behavior if an empty string is passed in? Would it match, say, an <html:div id=""> but not an <html:div>? I don't believe the DOM Core specs are very clear on this issue either...

-Boris