W3C home > Mailing lists > Public > www-svg@w3.org > November 2005

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

From: Chris Lilley <chris@w3.org>
Date: Thu, 3 Nov 2005 10:41:53 +0100
Message-ID: <1174897302.20051103104153@w3.org>
To: "L. David Baron" <dbaron@dbaron.org>
Cc: www-svg@w3.org

On Thursday, November 3, 2005, 1:41:15 AM, L. wrote:

LDB> On Wednesday 2005-11-02 17:39 +0100, Chris Lilley wrote:
>> 
>> On Tuesday, May 3, 2005, 11:09:51 PM, David wrote:

>> LDB>   I see three possibilities:
>> 
>> LDB>  1. The conditional processing attributes are processed on the
>> LDB>     referenced element and all 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.

LDB> This is what I meant by (1).  In my points (1), (2), and (3), I was
LDB> essentially referring to whether the conditional processing attributes
LDB> on a given element would be ignored or not.  My concern was that it was
LDB> unclear whether the definition of svg:use that I quoted implied that
LDB> certain conditional processing attributes should be ignored.

Okay.

>> 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> I wasn't referring to recursively applying the parent's conditional
LDB> processing attributes to the children, but rather to applying each
LDB> child's conditional processing attributes to itself.

Ah, understood. Thanks for clarifying what you meant.

>> LDB> It should be clear in section 5.8.1 [1] or in section 5.6 [2]
>> LDB> which of these is correct.
>> 
>> The quoted text above from 5.6 seems to make that clear.

LDB> The concern was that what was unclear was that "do not prevent elements
LDB> from being successfully referenced by other elements" could be
LDB> interpreted to mean more than just referenced:  i.e., that the
LDB> conditional processing attributes are ignored.

Okay. No, it does mean referenced; whether they get rendered or not
depends on conditional processing attributes, value of display property,
use of switch, on the referenced element. The important thing is that it
does not depend on the value on the parent of the referenced element.

>> 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> I think it would help if the sentence I originally quoted:

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> were followed by something like:

LDB> # However, the conditional processing attributes in the content that
LDB> # must appear to be deep-cloned into the generated tree are processed
LDB> # normally.

Good suggestion, thanks.

LDB> (I'm a little unsure of the terminology to use since the whole concept
LDB> of deep cloning is within a "has the same visual effect as if" clause.)

Its hard to talk explicitly about shadow trees, but that is what is in
fact being described here.

LDB> -David





-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Thursday, 3 November 2005 09:42:10 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:32 GMT