Re: Event handling in clipping conditions

Hi Robin, Doug,

     I want to respond to a few issues in the various threads but I think 
most of those are interesting but more back store to the basic issue
(where honestly I doubt any of us is going to seriously sway the others).
So let me focus on the current proposal from the WG because I think it
is fairly seriously flawed.

     The current primary WG proposal is that pointer-events on the
target element can control event clipping for that element.  So if 
pointer-events has any of the 'visible' values then it will not receive
events that fall outside of any parent's (or selves) clip region.

      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).

       The alternate proposal was that pointer-events on the element with
the clip controls if that clip element clips events.  This is more 
attractive 
to me as it doesn't have the same issues with 'unknown' embedded 
content causing problems.  However I think this will have more problems 
if you decided to add more event controlling properties/elements.  After 
all it would seem weird to have "event-clip='pointer-events'" as the 
default 
value - it could be done but it seems ugly.

       Based on that I would like to make a potentially simpler counter 
proposal  that also covers the major use cases but will likely need to be 
extended in future versions of the SVG standard.  Only have the clip of 
elements that create a view-port clip events.  If overflow="visible" then 
they 
wouldn't clip events (in cases where you wanted graphical clipping but not 

event clipping you could add a 'g' with a clip that matches the viewBox of 

the view port creating element as the first child.  This doesn't support 
clipping 
events but not clipping content (but I think that is an unusual use case).

      Obviously this isn't as flexible as allowing arbitrary clip paths 
for events but
I think it handles the major case for event clipping which is 
view-porting.