- From: Erik Dahlstrom <ed@opera.com>
- Date: Wed, 22 Jun 2011 13:36:15 +0200
- To: "robert@ocallahan.org" <robert@ocallahan.org>, "Vincent Hardy" <vhardy@adobe.com>
- Cc: "public-fx@w3.org" <public-fx@w3.org>
On Tue, 21 Jun 2011 15:51:12 +0200, Vincent Hardy <vhardy@adobe.com> wrote: > On 6/21/11 4:46 PM, "Erik Dahlstrom" <ed@opera.com> wrote: ... >> How is this different from say a span element that has a text-shadow >> that >> >> is somewhere far off? >> >> <style> >> #test { text-shadow: 100px 0 0 blue } >> </style> >> <span id="test" onclick="alert('clicked')">Click here</span> > > In the case of a shadow, the text is still showing, so you can click on > it > and it behaves as expected. Well, you could hide the text with another shadow (to make it blend into the background), or hide the actual sensitive area with some other element/property. > In the case of feOffset, there may be no > indication at all as to where the actual sensitive area is. I still think it's very similar to text-shadow, which also takes an offset. > I get your point that it can already confusing to click on the shadow and > not see anything happen. I would expect filter and text-shadow to behave much the same way wrt event sensitivity. In any case without the ability to specify an alpha-threshold for the event sensitivity (as previously discussed for pointer-events) it's not very interesting I think. Also note that SVG 1.1 only requires alpha-level hittesting on raster images, and it excludes a number of properties from affecting the result, e.g the 'opacity' property. The security implications of allowing alpha-level hit-testing on mixed-origin images (due to DOM methods being capable of extracting the pixel information via hit-testing) [1] is an issue that would need to be solved at the same time. Thinking about this some more, is there any reason to believe that someone wouldn't rather want say an 'event-filter' property, separate from the 'filter' property, but with the same syntax (or perhaps more limited), so that you could apply two different filters, one for event-processing/hit-detection and one for purely visual output? I guess I've heard the opposite side weigh in more on this whole event sensitivity topic, people wanting to capture events on areas that were not the same as the visual output, usually a larger area that isn't always the same as the geometry of the element at hand or even the visual output. One common way to solve such scenarios is to use another "invisible" element for capturing the events. [1] http://www.w3.org/Graphics/SVG/WG/track/issues/2071 -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Wednesday, 22 June 2011 11:36:59 UTC