- From: Erik Dahlstrom <ed@opera.com>
- Date: Wed, 02 Feb 2011 16:12:54 +0100
- To: "Dirk Schulze" <vbs85@gmx.de>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, "Doug Schepers" <schepers@w3.org>, "www-svg@w3.org" <www-svg@w3.org>
On Wed, 02 Feb 2011 14:15:35 +0100, Dirk Schulze <vbs85@gmx.de> wrote: > > Am 02.02.2011 um 13:37 schrieb Erik Dahlstrom: > >> On Wed, 02 Feb 2011 12:49:29 +0100, Dirk Schulze <vbs85@gmx.de> wrote: >> >>> >>> Am 02.02.2011 um 11:21 schrieb Erik Dahlstrom: >>> >>>> However, a thing to note is that filters aren't meant to affect >>>> pointer-events processing at all, for the purposes of hit detection >>>> it's as if there was no filter applied [2]. >>> >>> One possibility would be to take the filter region for pointer events. >>> But some SVG's take the complete viewport of the root SVG element as >>> filter region, because this solves the problem of a web developer to >>> determine the correct clipping region for drop shadows. It would be >>> much more helpful (but still not perfect) to just use the affected >>> area for pointer events. The problem is, that the specification does >>> not define how to determine this region (just the filter or primitive >>> regions for clipping), so it can't be defined that this region should >>> be used. >> >> I'm not sure I follow what you mean here. Are you saying you'd want >> filters to have an effect on pointer-events processing? > At least another definition would be better: > > <svg xmlns="http://www.w3.org/2000/svg" > xmlns:xlink="http://www.w3.org/1999/xlink"> > <defs> > <filter filterUnits="userSpaceOnUse" id="filter" x="0" y="0" width="100" > height="100"> > <feFlood flood-color="red"/> > </filter> > </defs> > <rect x="100" width="100" height="100" fill="green"/> > <rect x="100" width="100" height="100" filter="url(#filter)" > style="cursor:pointer"/> > </svg> > > The filtered object has the pointer-event. The user wants to press the > green button. In reality he will press the red button, because we still > take the bounding box of the filtered element for pointer-events. And in > my eyes this is a security issue, since the user expect another behavior > and this could be misused. I don't really see how that's any different from say an invisible rect capturing the events. ... > I have not read the discussion about CSS3 pointer events yet, not sure > if the discussion is somehow related to this topic here, sorry. But in > my eyes it is always problematic to handle a pointer event on invisible > areas of objects. That would remove large parts of the pointer-event property values (as has been done for the pointer-event property's application to html). You can specify "pointer-events=all" though, and it doesn't care about what 'visibilty' is. > On the other hand I fear that we end up analyzing every image (e.g. > intermediate images for masks, or filters) if a certain point/pixel in > it is fully transparent or not. This could be a really big performance > problem. Indeed, that's the main rationale behind the decision to not have filters affect pointer-event processing. > The same occurs to your discussion about rasterized images. The question > if we could take opacity=0 is difficult as well. The difference between > 0, 0.001 and 0.01 are not very high and depend on the contrast to the > background as well. If we just take an opacity of 0 for determine if we > handle the event or not, we would run into the same problem. Yes, that's more or less the reason behind the text you see in the SVG1.1F2 spec today: [[ By contrast, a mask (like a filter) is not a binary transition, but a pixel operation, and different behavior for fully transparent and almost-but-not-fully-transparent may be confusingly arbitrary; as a consequence, for elements with a mask applied, pointer-events must still be captured even in areas where the mask goes to zero opacity, or a filter makes the element invisible. If an author wishes to achieve an effect where the transparent parts of a mask allow pointer-events to pass to an element below, a combination of masking and clipping may be used. ]] Cheers /Erik -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 2 February 2011 15:13:35 UTC