- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 20 Mar 2012 10:30:22 +0100
- To: www-svg@w3.org
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