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

On Mon, 28 Mar 2005, Boris Zbarsky 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?


> If, at a later point in time, script changes the xbl:base attribute of 
> those elements to a relative URI, how is that URI resolved?  Are they 
> treated effectively as roots, so that it's resolved relative to the base 
> URI of their ownerDocument?

xml:base actually already covers this, but we've added the following 
section:

# 4.5. Shadow Content and xml:base
# 
# This section is intended to re-iterate what the xml:base specification 
# already states, in case there is any question about how xml:base 
# processing should work in shadow trees.
# 
# Relative xml:bases on nodes in shadow trees are resolved relative to 
# their parentNode, or the ownerDocument if there is no parentNode.


> 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?


> If I understand correctly, the parentNode of the kids of the shadowTree 
> node remains the shadowTree node, and the parentNode of the shadowTree 
> node is null, right?

Yes.


> 4.2
> 
> When doing the depth-first walk looking for matching content elements, 
> is it pre-order, in-order, or post-order?  I'm assuming the desired 
> behavior is pre-order (that is, use the first <content> element using 
> the standard DOM ordering on nodes).

Pre-order. (Now explicit)


> 4.3
> 
> 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?

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?


> 4.4
> 
> 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.
 
Now if X is the root of a shadow tree, it doesn't match B.
  
Otherwise, it matches B if X == A.


A B

Matches B if A>B matches B or C>B matches B and A C matches C.


A+B

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


A~B

Matches B if A+B matches B or if C+B matches B and A~C matches C. 
--------------8<---------------------------------------------------------


> 4.5
> 
> I'm not quite sure what "Sheets are always walked from the innermost 
> shadow scope to the outermost shadow scope" means, if the stylesheets of 
> the binding document don't affect the bound element or its non-shadow 
> descendants.  Is this a matter of shadow content nodes being styled by 
> sheets in the bound document? If so, that should be clarified.

That was an erroneous paragraph and has been removed altogether. It shall 
return in XBL2, probably.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 14 June 2005 12:01:16 UTC