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