Re: [sXBL] Various issues in the sXBL draft -- section 4

Ian Hickson wrote:
>>The part that talks about setting xml:base means that it should be set 
>>on the children of the clone of the <template> element, right?
> 
> The spec seems clear: 
> 
> # The xml:base data of the cloned nodes must be set so that the baseURI of 
> # nodes in the resulting shadow tree is the same as their pre-cloning 
> # counterparts.
> 
> Is that ambiguous?

It's not clear whether xml:base should be set on all the cloned nodes, the 
shadowTree node, the shadowTree node's kids, or what.  I believe all three of 
those would have the same effect at first, conforming to the above text (since 
the parentNode of the clone of a kid of <template> is the shadowTree), but would 
respond differently to later DOM changes.  Hence it would be good to specify the 
exact behavior here,

>>What happens if the prebind event detaches the binding?  I assume that 
>>the setting of the xblShadowTree attribute should be skipped in this 
>>case; that's worth spelling out, probably.
> 
> Since this is an edge case, we want to make this simplest for 
> implementors. What do you think would be simplest here?

I'm not actually sure....   I've not put enough thought into how I'd implement 
this stuff yet.

>>Are mutation events required, allowed, or prohibited from firing during 
>>the shadow tree reconstruction that follows modification of a <template> 
>>subtree? Further, are shadow trees that were explicitly modified via the 
>>DOM also destroyed and completely reconstructed when the <template> 
>>subtree is modified?
> 
> To your second question, yes. Is this not clear?

It wasn't obvious to me, no.

> To your first question, as far as we can tell, it doesn't matter. There 
> would be no way to catch those events anyway. Do you agree?

That depends on whether there are mutation listeners on the shadow tree nodes 
themselves, no?  If there are, they would catch the events...

>>I think my personal preference is that CSS selectors apply based on the 
>>Core DOM parent/child/sibling links...  the processing model described 
>>means that XBl-defined widgets that actually interleave content would 
>>pretty seriously affect the styling of the non-shadow DOM nodes.
> 
> This section now reads as follows:
> 
> --------------8<---------------------------------------------------------
> A>B
> 
> If B.parentNode is an insertion point, let X be B.parentNode.parentNode, 
> otherwise let X be B.parentNode.

I'm not quite sure why this is necessary...  In what case will B.parentNode be 
"an insertion point"?  And does it matter _which_ insertion point?

> If B.previousSibling is an insertion point, it doesn't match B, otherwise, 
> it matches if B.previousSibling is A.

Again, I'm not sure what this is trying to address.

What about CSS3 selectors?  That's in CR, so browser vendors are attempting to 
implement them....

-Boris

Received on Sunday, 3 July 2005 19:45:28 UTC