W3C home > Mailing lists > Public > www-svg@w3.org > October 2004

Re: Question on sXBL and ownerDocument

From: Peter Sorotokin <psorotok@adobe.com>
Date: Wed, 06 Oct 2004 14:02:46 -0700
To: Boris Zbarsky <bzbarsky@MIT.EDU>, www-svg@w3.org
Message-id: <>

At 11:40 AM 10/6/2004 -0500, Boris Zbarsky wrote:

>I was looking at the sXBL draft and noticed that the shadow nodes' 
>ownerDocument points to the sXBL document.  As a result, one can have 
>nodes which have ownerDocument set to a document that they are not really 
>"in" (in the sense that traversing the parentNode chain will never reach it).

 From the Core DOM perspective shadow trees are just branches that hang out 
on a side and are not connected to any document tree (calling 
cloneNode(true) on any branch would produce something like that, so there 
is nothing unusual for Core DOM). All "glue" is provided by XBL.

>I understand the reasons for this decision, and I agree with them, but it 
>does lead to some ambiguities in interpreting certain constructs.  I'll be 
>sending more mail on this when and if I run into these issues, but for a 
>start consider the following scenario:
><template> "contains child nodes that can be in any namespace".  Say I 
>have an <xhtml:img> in the template that has a usemap attribute 
>set.  Where should the <xhtml:map> element be searched in?  The sXBL 
>document, or the ownerDocument of the element that the binding is attached to?
>I'm leaning towards searching in the sXBL document, since the shadow 
>content should not be making assumptions about the structure of the 
>document it's attached to... is that correct?

Your conclusion is correct, it should be ownerDocument (that is the basic 
reason why ownerDocument must be preserved for the shadow tree - this is 
even bigger issue for SVG than for XHTML). Other things of this nature are 
@font-face CSS declarations, and all SVG resources (font-face element, 
color profiles, symbols, clip paths, gradients, patterns, filters and 
vector effects).


Received on Wednesday, 6 October 2004 21:02:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:03 UTC