W3C home > Mailing lists > Public > www-svg@w3.org > July 2006

Re: [SVGMobile12] Issue SVGT12-479 (used to be issue SVGT12-175) is STILL not resolved

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Mon, 24 Jul 2006 20:56:20 -0500
Message-ID: <44C57A44.1070509@mit.edu>
To: Andrew Shellshear <andrews@cisra.canon.com.au>
CC: www-svg@w3.org

Andrew Shellshear wrote:

 >Boris Zbarsky wrote:
>>   Given a DOM tree, make a list of all SVG document fragments
>>   present in that DOM tree; for each SVG document fragment,
>>   list all nodes belonging to that SVG document fragment.


> ...and this is no good because the "must not" makes it unclear as to 
> whether it's even allowed in the DOM tree.  How about replacing it with:
> In SVG Tiny 1.2, nested 'svg' elements are unsupported elements and 
> therefore won't be rendered.

This is fine as a general statement, but not really related to the definition of 
an "SVG document fragment" as far as I can tell..

> ...as the intention is that you *can* have whatever DOM tree stuff you 
> like (including nested svg elements) but they won't be rendered, and 
> that each SVG document fragment consists of an svg element and 
> everything that is beneath it.

So if you _do_ have nested 'svg' elements, there is only one "SVG document 
fragment" around, right?  Even _that_ is not obvious from the spec.

> Would that suit?  If not, perhaps you could suggest some text?

So _if_ I understood this correctly, what we're trying to define-by-examples is 
something like:

   An "SVG document fragment" is a subtree of a DOM tree that satisfies the
   following properties:

     1)  It has a single root, which is an 'svg' element.
     2)  Its root is not the descendant of any other 'svg' element.

   Note that some parts of an SVG document fragment may not be rendered; see
   detailed rules in sections [insert refs here].

I'm not sure whether you want to exclude non-SVG-namespace kids of nodes that 
are in the SVG document fragment; that probably depends on how the term is used 
in the spec and what the intended behavior is.

> No, no - I'd rather fix it so that you *are* satisfied.

Sounds good to me.  ;)

Received on Tuesday, 25 July 2006 01:56:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:09 UTC