W3C home > Mailing lists > Public > www-svg@w3.org > December 2008

Re: Event handling in clipping conditions

From: <thomas.deweese@kodak.com>
Date: Thu, 11 Dec 2008 06:23:14 -0500
To: cam@mcc.id.au
Cc: www-svg@w3.org
Message-ID: <OF73B4DC3E.D10C8F28-ON8525751C.003C7A62-8525751C.003E819A@knotes.kodak.com>
Hi Cameron,

> Thomas DeWeese:

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

Cameron McCormack <cam@mcc.id.au> wrote on 12/11/2008 03:33:11 AM:

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

   I don't have strong feelings on this but my inclination would be
to restrict it to the implicit clipping path.  Primarily because I
suggested leveraging the overflow property (which only applies to 
that clip AFAIK) to control event clipping behavior.

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

   The cases I was thinking of were mostly simpler things like an
element that for graphical reasons uses clip to create a hole in
the middle but 'the hole' should still be sensitive to 
events.  Perhaps there are others.
Received on Thursday, 11 December 2008 11:23:23 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:41 GMT