Re: Event handling in clipping conditions

Hi Doug,

> The SVG WG has been talking about this whole issue.  Rather than come
> back immediately with a conclusion, we would like to discuss it with you
> and others more on-list first.

   Thanks.

>> www-svg-request@w3.org wrote on 12/04/2008 10:43:58 AM:
 
> >> I'd expect mask to work  like opacity, but that's just my
> >> personal opinion.

> > thomas.deweese@kodak.com wrote (on 12/5/08 6:38 AM):

> >    Sure, but I would argue that given the wording in the spec one
> > could easily decide that an element with opacity="0" should not
> > receive events if it's pointer-events is any of the 'visible*'
> > values; "Will not receive pointer events for the occluded parts
> > of the element".

Doug Schepers <schepers@w3.org> wrote on 12/09/2008 03:49:24 AM:

> We certainly didn't intend to convey that... can you suggest a better
> way of wording it?

   Therefore, an element which has 'pointer-events' property values 
which depend upon the 'visibility' property of the element (i.e. 
'visiblePainted', 'visibleFill', 'visibleStroke', 'visible') will not 
receive pointer events outside of the clipping region, regardless of
the setting of the 'visibility' property.  Within the clipping region
the 'visibility' property acts normally on event sensitivity.

   Of course this will need to be rewritten/augmented to clarify
the relationship between the clip-path element and the event target.

> >> In what way is the behavior not consistent with mask?

> > from 14.3.1 Introduction:
> > 
> >      A clipping path can be thought of as a mask wherein those pixels
> > outside the clipping path are black with an alpha value of zero and 
> > those pixels inside the clipping path are white with an alpha value 
> > of one (with the possible exception of anti-aliasing along the edge 
> > of the silhouette).
> 
> This strikes me more as an explanatory metaphor, rather than an
> implementation (or authoring) direction.  The basic concepts are
> similar, but they diverge from there.

   Well in Batik we actually do turn clip into a mask when 
shape-rendering="geometricPrecision" on the clipPath element, 
giving fully anti-aliased edges on the clip path[1].  For performance
we also support the more common 'hard edged' clip as well.

> >    The two features are combined in one chapter in the specification.
> > Really this addition to the standard is the first instance where a
> > significant _semantic_ difference between the two elements is 
introduced
> > (clipping effects events as well as rendering).
> 
> The visual effect is similar, so it does make some sense to bundle them
> together.  However,  masks have a closer similarity to filters, in that
> they are both raster operations, than on the geometric rendering effects
> of clipping paths.

   I doubt any SVG engine treats clip as a geometric rendering effect. 
All engines I am aware of handle clip as a raster operation, typically as
some sort of runs/boxes of unclipped _pixels_.  This is faster and more
compact than a full mask but is very different from treating it as a
geometric effect (which would involve geometric intersection of the
vector geometry).  Often the rasterization is limited to the bbox of the
clip path which is vaguely vector oriented but the same optimization 
applies to mask.

> >    Really the SVG standard should (eventually) have a defined set of
> > properties that actually act on events that is orthogonal to 
rendering.
> > Trying to tie the two together is just too likely to cause unintended
> > side effects.  A really nice SVG 1.2 solution would be and 
'event-clip'
> > property that can either reference a clipPath element, or have the
> > value 'clip-path' (which uses what ever clip-path is referencing).
> > 
> >    My fear is that this quick fix will make that future 'clean'
> > solution to the problem more complex and likely not backwards
> > compatible.
> 
> The SVG WG has talked about more nuanced attributes to modify events
> based on raster effects such as those with filters, and we may still do
> this.  The proposed errata wording doesn't seem to close any doors
> regarding this.

   This change ties clip path to event propagation directly, perhaps
worse it ties the visibility values for pointer-events to clipping. 
I'm not sure how you would fix that later unless you simply broke 
backwards compatibility, or end up with a default special 'backwards
compatibility' value (as mentioned in my other message).

> In fact, we originally discussed doing the very same thing with clipping
> effects.  But I don't personally think that we need to add special
> attributes when the desired behavior can be achieved more simply.  As
> you mention, the combination of 'pointer-event' values captures most (or
> all?) behaviors that users could want from clipping paths regarding
> pointer events... If you can think of cases that aren't covered, that
> would be helpful in determining if we have made the right decision here.

   See my other note.

> >> And even if it were a solution, UAs still need to have properly 
defined
> >> interoperable behaviour for hit testing in all cases.
> > 
> >    I would argue the standard already has an interoperable behaviour.
> 
> The fact that we encountered different behavior from WebKit/Safari and
> Firefox and Opera regarding how pointer-events are treated, and what the
> effect was on the bounding box, shows that we didn't have
> interoperability.

    So let me put it this way.  What was the justification for these
implementations clipping events?  What part of the SVG 1.1 specification 
lead them to believe this was the correct implementation?

   There is no way to keep an implementer from doing anything they want.
Is it really incumbent on the specification to say 'clipping does not
effect events'?  If so then it must list every other feature of SVG
that doesn't effect events, of course standards aren't written that way.

   Anyway this is a moot point as the WG has clearly decided to make
the standard conformant with implementations.

> >    Aside from all the above I have an actual question on 
implementation
> > of the proposed errata.

> That's a good point we should clarify.  Do you have an opinion?

   See my other note.

> I can definitely see where you are coming from here, wanting more
> general control over how pointer-events are treated within a given
> clip... but I can also see wanting finer control at the target-element
> level.  There are use cases for both.

   I don't really see a use case where some of the children of an 
element should have event's clipped and others shouldn't.

> If we do add a way to control pointer events at the level of the
> clipPath itself, we can provide values that override the behavior at the
> clipped-element level.  This would provide for more author options.

   Sounds complex to me (in some cases we stop all event propagation
in some cases we have to mark the event as clipped but continue to
propagate, getting the processing order right seems complex).  It also 
wouldn't address the fact that the proposed errata mixes 
visibility='hidden'
and clipping which I think are distinct cases.