Re: Event handling in clipping conditions

Hi Thomas.

Thomas DeWeese:
> 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.

Correct.

So the current state of some implementations are:

  * Firefox and Opera both clip pointer events.
  * WebKit and Batik don’t clip pointer events.

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

Here’s the kind of thing Thomas is talking about:

  http://mcc.id.au/temp/2008/clip-window.svg

You can’t scroll the contents of the viewport around, but you can notice
that in WebKit or Batik mousing over the part of the link that is
outside the viewport results in the link being highlighted.

I agree with your assessment that the WG’s proposed change would break
this use case (in UAs where pointer events currently are clipped).

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

Would this also include if a ‘clip-path’ were specified on the viewport-
creating element?  Or would it just be the implicit clipping path from
the overflow:hidden viewport?

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

If the window/viewport use case is the only one we’re worrying about,
then I think I’d rather have the solution where pointer events are
always clipped, regardless of the value of ‘pointer-events’.  And then
introduce a separate property that determines if clipping does in fact
affect events.

With the WG’s proposal, you could clip geometry but not events with
pointer-events="fill".  Were there particular use cases that we wanted
to handle with this (which might affect my opinion in the previous
paragraph)?

Thanks,

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 11 December 2008 08:34:07 UTC