Re: Some filter effects specification review comments

Hi Erik,


From: Erik Dahlstrom <ed@opera.com<mailto:ed@opera.com>>
Date: Wed, 22 Jun 2011 04:36:15 -0700
To: "robert@ocallahan.org<mailto:robert@ocallahan.org>" <robert@ocallahan.org<mailto:robert@ocallahan.org>>, Adobe Systems <vhardy@adobe.com<mailto:vhardy@adobe.com>>
Cc: "public-fx@w3.org<mailto:public-fx@w3.org>" <public-fx@w3.org<mailto:public-fx@w3.org>>
Subject: Re: Some filter effects specification review comments

On Tue, 21 Jun 2011 15:51:12 +0200, Vincent Hardy <vhardy@adobe.com<mailto:vhardy@adobe.com>> wrote:

On 6/21/11 4:46 PM, "Erik Dahlstrom" <ed@opera.com<mailto: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 see. Is your point that if you have a text-shadow with a text that is not showing (for some reason), then the effect is similar: no interactivity on the shadow and it is equally misleading as the issue(s) I am raising?

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.

>> I think there is a difference because with text shadow, the original source graphic (the text) is always composited with the filtered output (the shadow). It is equivalent to having all filters ending with an feMerge which a the SourceGraphic always the top feMergeNode. In filters, we do not always have the original graphic showing and I think it is a significant difference.

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.

>> I agree this is also a problem, but I think it is a bit different. In the case of opacity, the issue is that the graphic may not be seen by the end user. So there is a question of whether or not we should have event sensitivity on the parts that are invisible. The issue I am raising with filters is that the rendering may be moved to a different location and that throws off the interactivity (in a different way).

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 think this is an interesting idea. If we went that route, it might be good to figure out a way to bind the two things easily (I.e., say that the element's event filter is derived from the element's filter).


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.

>> Yes, that is another event issue, and an important one too. I think the one I raised could become important as filter effects get more widely implemented and performant.

Vincent

[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