Re: Event handling in clipping conditions

Hi Thomas,

On Dec 4, 2008, at 22:52 , Thomas.DeWeese@Kodak.com wrote:
> www-svg-request@w3.org wrote on 12/04/2008 10:43:58 AM:
> > [[
> > 14.3.6 Clipping paths and geometry
> > [...]
> > With regards to pointer-events, while the visible parts of a clipped
> > element receive pointer events normally, parts of a clipped element
> > which are outside the extent of the clipping path must be treated  
> as if
> > they have a 'visibility' property value of 'hidden'. Therefore, an
> > element which has 'pointer-events' property values which depend  
> upon the
> > visibility of the element (i.e. 'visiblePainted', 'visibleFill',
> > 'visibleStroke', 'visible') will not receive pointer events for the
> > occluded parts of the element.
>
>    So does this apply to Mask as well, which has _exactly_ the same
> appearance implications in many cases?  If so at what level of
> opacity does the Mask stop transmitting events?

It's not about the appearance implications, display none, visibility  
hidden, and opacity 0 all have the same appearance implications but  
different semantics, and behave differently. I'd expect mask to work  
like opacity, but that's just my personal opinion.

> > We believe that this is the most consistent and predictable  
> behavior,
> > and that it should be relatively simple to implement.
>
>    It's not very consistent with the mask element.  And implementing
> it with mask may not be relatively simple to implement...

In what way is the behaviour not consistent with mask?

>    There are of course other cases that have similar issues like
> filters where the actual geometry can be offset from the apparent
> geometry.
>
>    My personal opinion is that content authors should handle these  
> cases
> with 'hidden' event targets that gives them much more control over the
> behavior they desire.

I don't think that's a very nice solution, it forces people to update  
things twice whenever they script or animate. And even if it were a  
solution, UAs still need to have properly defined interoperable  
behaviour for hit testing in all cases.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Friday, 5 December 2008 09:30:12 UTC