- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Mon, 24 Jul 2006 20:56:20 -0500
- 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. ;) Thanks, -Boris
Received on Tuesday, 25 July 2006 01:56:33 UTC