Re: Some filter effects specification review comments

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