[sXBL] Various issues in the sXBL draft -- section 6

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

Received on Tuesday, 29 March 2005 06:02:15 UTC