RE: [SVGMobile12] 5.8.1: interaction of conditional processing and use is unclear

Chris's email refers to the definition of "rendering tree". We did not a
definition for "rendering tree" in the Last Call draft, but we will have
one in the next draft:

Rendering Tree

    The set of elements being rendered when the painters model is
applied to an SVG document fragment. The following elements in the
fragment:

        * a 'defs' element
        * elements whose 'display' property is set to 'none
        * elements with one or more test attributes that evaluate to
false
        * direct children of a 'switch' element, other than the child
that evaluates to true

    and their children, are part of the SVG document fragment, but not
part of the Rendering tree (and thus do not get rendered). Elements with
zero opacity, or no fill and no stroke, or with the visibility property
set to hidden, are still in the rendering tree. The copies of elements
referenced by a 'use' element, on the other hand, are not in the SVG
document fragment but are in the rendering tree.

Jon


-----Original Message-----
From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
Of Chris Lilley
Sent: Wednesday, November 02, 2005 8:40 AM
To: L. David Baron
Cc: www-svg@w3.org
Subject: Re: [SVGMobile12] 5.8.1: interaction of conditional processing
and use is unclear


On Tuesday, May 3, 2005, 11:09:51 PM, L. wrote:

LDB> Section 5.8.1 of SVG Tiny 1.2 contains the following sentence:
LDB> # Similar to the 'display' property, conditional processing
attributes
LDB> # only affect the direct rendering of elements and do not prevent
LDB> # elements from being successfully referenced by other elements
(such as
LDB> # via a 'use').

LDB> It is clear from this that conditional processing attributes do not
LDB> prevent an element from being referenced by a 'use' element (i.e.,
they
LDB> do not make the reference invalid per [3]).

Yes.

LDB>   However, it is not clear
LDB> what this sentence implies about the processing of the cloned
LDB> non-exposed DOM tree attached to the 'use' element.

The specification says:

A 'use' element has the same visual effect as if the 'use' element were
replaced by the following generated content:

    * In the generated content, the 'use' will be replaced by 'g', where
    all attributes from the 'use' element except for x, y and xlink:href
    are transferred to the generated 'g' element. An additional
    transformation translate(x,y) is appended to the end (i.e.,
    right-side) of the transform attribute on the generated 'g', where x
    and y represent the values of the x and y attributes on the 'use'
    element. The referenced object and its contents are deep-cloned into
    the generated tree.

(it then gives an example). So, if there are conditional attributes on
the referenced element, they will be copied into this shadow tree.
Similarly, if there are conditional attributes (or display:none) on a
parent, the attributes on the parent do not have an effect because they
are not copied.



LDB>   I see three
LDB> possibilities:

LDB>  1. The conditional processing attributes are processed on the
LDB>     referenced element and all its descendants.

LDB>  2. The conditional processing attributes are processed on the
LDB>     descendants of the referenced element but not on the referenced
LDB>     element itself.

LDB>  3. The conditional processing attributes are not processed on the
LDB>     referenced element nor any of its descendants.


Looking at the specification text quoted above, we can see that the
answer is

4) The conditional processing attributes are copied, and then processed,
on the copy of referenced element.

There is no need to recursively apply them on the children. Its the same
as with the non-inherited property 'display' - it stops the children
being in the rendering tree anyway.

LDB> It should be clear in section 5.8.1 [1] or in section 5.6 [2] which
of
LDB> these is correct.

The quoted text above from 5.6 seems to make that clear.

LDB>   (I don't think (3) makes much sense, but it actually
LDB> seems to me to be what the specification currently says.

We don't think that is the case; "all attributes" is clear.

As a follow-on from your comment, we clarified the definition of the
rendering tree to specifically note the cases you mentioned.

Thanks for your comment, please let us know within two weeks if this
does not address your comment.

LDB>   The Adobe SVG
LDB> plugin seems to implement (2).)

LDB> -David

LDB> [1]
LDB>
http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/struct.html#Conditiona
lProcessingOverview
LDB> [2]
LDB>
http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/struct.html#UseElement
LDB> [3]
LDB>
http://www.w3.org/TR/2005/WD-SVGMobile12-20050413/linking.html#HeadOverv
iew





-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Wednesday, 2 November 2005 18:02:43 UTC