Re: Event handling in clipping conditions

Hi Doug,

   I'm a little confused on clipping with regards to element's that 
establish view-ports.
I get the impression that the WG seems to be adopting my suggestion on 
that point
(the implicit clip for a viewport element always clips events) in addition 
to the
clip-path clipping events for the visible pointer-event values.  Is my 
impression
correct?

schepers@w3.org wrote on 12/17/2008 01:25:18 PM:

> thomas.deweese@kodak.com wrote (on 12/10/08 7:09 AM):
> >> >> 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.
> 
> Cameron did not seem to think it would be hard to adapt the Batik code
> to match the more detailed description of clipping and pointer-events,
> so presumably this is not a blocker?

    Did I say the problem was in the code?  I was pointing out that 
currently clip is a strict subset of mask functionality.  You indicated 
that it wasn't and that implementations didn't treat it as such.  I was
making it clear that at least one implementation does exactly that. Adding 

this behavior to clip (without something similar in Mask) would break the 
current simple relationship (clip is just an optimized Mask).

> >    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).
> 
> The SVG WG doesn't see a conflict there.  Indeed, as you suggest, the
> initial value for such a property would be the same as the current
> behavior.  This is a pragmatic way of adding new properties.
> 
> So, this new potential value would be applicable to the <clipPath>
> element (as opposed to the current behavior, which is tied to the values
> on the "target" of the clip).  The initial value of the 'event-clip'
> property would be 'default' (or something), which would simply cede
> control of pointer-event behavior to the clipped elements.  There would
> be 3 additional values (please ignore the names for now), 'clip-area'
> (pointer events only on the areas not clipped), 'all' (pointer events on
> the clipped and non-clipped area), and 'none' (no pointer events).
> These values would probably override any "local" values, though I can
> also see a case for them being supplementary... that is, given the
> following:

   Except you can't easily break the relationship between visibility
and clip this way.  So you can no longer choose to cleanly extend 
pointer-events along the lines Robin suggested where it becomes a 
mini-syntax like:
        "(clipped|visible|fill|stroke|painted)*|none"

   Where each of those values sets a 'bit' that effects the element's
response to pointer-events.  The 'clipped' value would no longer make
sense since it was already tied to the "visible" bit being off.

> The members of the SVG WG thinks that though they are indeed orthogonal,
> yoking them in this way gives an intuitive and simple way to author
> content that behaves in a consistent way (an elegant hack).  The fact
> that the specification already yokes pointer-events with visibility
> makes this a natural extension.

   Since the WG agrees that clipping/visibility/events are all orthogonal
please pick a 'fix' for the current problem that allows you to treat
them as orthogonal in the future without usurping the current role
of the non-visible pointer-event values.

   I like the idea of adding a event-clip property down the road
but I think that the 'clip-visibility' option is a bad choice fore 
the default.  First without any way for  the 'clipper' to make 
absolutely sure events are clipped wrapping unknown content becomes 
difficult/impossible.  It also makes it 'really bad' for people to 
use  the 'hidden' pointer-event types unless they want their events 
to be completely unclipped.  So essentially all of my uses of it are 
suddenly 'bad' because I was simply trying to make unseen event
targets - which apparently the best practice for is now group opacity!

   Looking forward while I can see SVG Tiny adopting clip and 
interactivity/pointer-events in the near future it's less certain 
that it would adopt group-opacity (as that may require significant 
memory) so this workaround may be problematic for SVG Tiny in the 
future (unless you only allow zero and one).

> >    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.
> 
> How about a map where you can grab and drag clipped parts of the map
> into or out of the clip viewport, but location icons only pop up
> infobubbles when they are visible (inside the unclipped area)?

   This seems like a weak example as this is exactly what people
complain about with Batik not clipping content.  I'll allow that
within a page one might be able to make use of this but I don't
think it's a general use case.  In most cases the functionality 
will be harmless but I suspect far more people will 'trip' over 
it as the default than invoke it intentionally.  Once again I
don't have a problem with it as an option for event handling but
I think it will be a very problematic default value for future
specifications to inherit.

> But the more important part of this is not that different child elements
> could have different values... it's that authors have control over what
> the behavior is at all.

   The interesting thing is that I view this as removing author control.
I understand that this allows an author constructing a single complex 
document to have additional options that could prove useful.  But the 
single author case is a case where the author has lots of options for 
achieving various effects.  The case where an author doesn't control
it's "container" and needs to try and needs to "play nice" or the case 
where the author wants to contain arbitrary SVG content are tricker as 
it is difficult or impossible to impose rules on the other party.  For
these use cases (which I see as far more important) really the author
needs to be able to clip all events unconditionally.

> >       The problem is that this reuse of existing pointer-events values
> > means that a document that used 'visibility="hidden"' in conjunction
> > with 'pointer-events="fill"' to place event targets would suddenly 
have
> > those event targets have their events be unclipped.  Since I believe 
the
> > above set of properties is the 'best practice' for event targets I 
think
> > this is problematic as it would make such a document unable to be 
enclosed
> > in say a scroll-window (the case that triggered this whole issue).
> 
> I suspect that the use of that particular combination of elements and
> property values is not a common use case (though I'm happy to look at
> evidence to the contrary). 

    Please see my solitaire example in Batik:
 http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/samples/sydney.svg

      I have a event catcher that uses pointer-events="fill".

 http://svn.apache.org/viewvc/xmlgraphics/batik/trunk/samples/solitaire
 
    In particular solitaire/script/card.js and solitaire/script/pile.js

    where I use this technique to cover cards that are drawn from an
external file.  I've used this in a number of other cases (actually
more commonly for a glass pane) but they aren't publicly available.

    Also you can see that I've provided this suggestion for quite a
long time on the Batik mail-lists:

http://www.nabble.com/how-can-I-create-a-svg-with-transparent-background-in-batik--to16761410.html#a16829850
http://www.nabble.com/SVGOMGElement-and-coordinates--to5795044.html#a5795218
http://www.nabble.com/Changing-cursor-to24522.html#a24815
http://www.nabble.com/Event-listener-not-called-to14987344.html#a15304049
http://www.nabble.com/how-to-access-a-GraphicsNode-to18806392.html#a18827973
http://www.nabble.com/Weird-problem-using-translations.-to1228541.html#a1243408

    Also these examples use the 'non-visible' values which would also have
problems:

        http://support.adobe.com/devsup/devsup.nsf/docs/52492.htm
        Describes how to make text unselectable with a hidden rect.
 
 
http://heml.mta.ca/viewsvn/?do=diff&project=Heml&path=/trunk/web/xslt/heml/output/svg/map/animated_map.xsl&rev=670&oldrev=492&raw=1
        Interesting because it is using a non-visible pointer-events
to make the interior of a polygon that is only stroked sensitive since
it represents a button.

   I hope this starts to open your eyes to how often the non-visible
pointer-event values are used.  All of these uses would become worst
practice since it means the content couldn't be embedded safely in
a mashup.

> A more common and better practice would be
> to establish a viewport via a nested SVG element, which is not affected
> by these clarifications (a point I have clarified in the errata).  Also,
> instead of using 'visibility', the author could use 'opacity' to create
> hidden event hotspots.  So, for the great majority of those cases, there
> is an easy workaround.

   The fact that I must move from visibility="hidden", which is explicitly 

called out for exactly the needed behavior by the current text of 
pointer-events to 'opacity="0.0004"' (or perhaps "0" if implementations 
have finally gotten that right) based on the text of an errata or else 
face 
the possibility of causing problems for people that want to embed my 
content 
seems just wrong.

> Ultimately, we simply have to make a choice about the behavior in order
> to get interoperability, and we are choosing what we think best serves
> the needs of the authors.  However, we value your viewpoint, and will be
> following up with other implementers to make sure that what we are
> proposing is suitable for them, as well.  If it turns out that they too
> disagree with our judgment here, then we will revisit this at that 
point.

   I strongly encourage the WG if it feels it _must_ add event clipping to
SVG 1.1 to choose to make the default your "clip-area" value (that would 
have the added advantage that at least two implementations would then be 
conformant).  People who did not want event clipping could use 'mask' 
instead for SVG 1.1. Down the road you could add the 'clip-visibilty' 
(or I would call it 'clip-optional' and allow  pointer-events to be 
sensitive 
to  events outside the "optional" event clip region). 

   Thanks for taking the time to review my feedback.