W3C home > Mailing lists > Public > www-svg@w3.org > March 2012

Re: getEnclosureList() and getIntersectionList() - rendering vs geometry

From: Erik Dahlstrom <ed@opera.com>
Date: Tue, 20 Mar 2012 10:30:22 +0100
To: www-svg@w3.org
Message-ID: <op.wbgp0wjmgeuyw5@localhost.localdomain>
On Mon, 19 Mar 2012 23:01:24 +0100, Jennifer Yu  
<Jennifer.Yu@microsoft.com> wrote:

> Hi folks,
> It was pointed out to me that one of our test cases around  
> getEnclosureList() and getIntersectionList() is incorrect . I'd just  
> like some clarification around the right behavior before we go update  
> it. Should getEnclosureList() and getIntersectionList() reflect the  
> rendered content (with filters, masking, etc) or shape geometry? I found  
> this old thread  
> http://lists.w3.org/Archives/Public/www-svg/2009Nov/0015.html that  
> doesn't appear to be very conclusive. The spec definition refers to  
> "rendered content" but that seems a bit vague to me, especially when  
> compared to the definition for getBBox() which is more explicit.
> Thanks!
> Jen

Definition of the intersection/enclosure methods:
[[ Each candidate graphics element is to be considered a match only if the  
same graphics element can be a target of pointer events as defined in  
‘pointer-events’ processing. ]]

Then, for filters, from the definition of pointer-events:
[[ The ‘filter’ property has no effect on pointer-events processing, and  
must in this context be treated as if the ‘filter’ wasn't specified. ]]

And for mask:
[[ By contrast, a mask is not a binary transition, but a pixel operation,  
and different behavior for fully transparent and  
almost-but-not-fully-transparent may be confusingly arbitrary; as a  
consequence, for elements with a mask applied, pointer-events must still  
be captured even in areas where the mask goes to zero opacity. ]]

I think it's rather clear that the intent is to not just look at the bbox  
geometry but to follow the same processing model as we have for  
pointer-events. We should probably add a defintion of rendering tree[1]  
like we have in SVG Tiny 1.2 going forward.

[1] http://www.w3.org/TR/SVGTiny12/intro.html#TermRenderingTree

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 20 March 2012 09:31:05 UTC

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