Re: Event handling in clipping conditions

Hi Thomas,

On Dec 5, 2008, at 12:38 , Thomas.DeWeese@Kodak.com wrote:
> www-svg-request@w3.org wrote on 12/05/2008 04:29:35 AM:
> > It's not about the appearance implications, display none, visibility
> > hidden, and opacity 0 all have the same appearance implications but
> > different semantics, and behave differently.
>
>    When I read the quoted part of the errata it seems pretty clear
> that it tying the concept of pointer events that refer to the
> 'visibility' of the element to the actual visibility
> of the element.

I disagree that it is clearly doing any such thing. It is tying the  
concept of pointer events to the visible and non-visible parts of  
clipped elements.  I guess that maybe the wording could be improved by  
talking solely of occluded and included parts of the clipped element,  
but "visible" is more intuitive (literally) and the paragraph is clear  
in what it references: "the visible parts of a clipped element", "the  
occluded parts of the element", etc.

http://dev.w3.org/SVG/profiles/1.1F2/errata/errata.xml#clippath-pointer-events

> > I'd expect mask to work  like opacity, but that's just my
> > personal opinion.
>
>    Sure, but I would argue that given the wording in the spec one
> could easily decide that an element with opacity="0" should not
> receive events if it's pointer-events is any of the 'visible*'
> values; "Will not receive pointer events for the occluded parts
> of the element".

This discussion has happened before. I recall various noises about  
float precision being made, though I'm sure that those could be  
addressed. I disagree with your conclusion but I agree that there  
maybe could be a tightening up of the spec's terminology to avoid  
confusion here. I would see this as three levels:

- Removed from the rendering and hit testing (display)
   This concerns the display property.

- Removed from the rendering but not from hit testing (visibility)
   This concerns the visibility property, and what is clipped (in  
other words, things that are removed from rendering in a discrete  
fashion).

- Things that are not removed from the rendering, even though there  
may be invisible (opacity)
   This concerns opacity and anything continuous such as masks. It  
doesn't matter that there are corner cases (opacity set to zero, a  
mask with only two distinct levels that could be done as a clip), you  
may optimise the underlying implementation but conceptually you're  
still compositing.

These three levels all have different uses, and different semantics.  
Mixing them seems to me as if it would be likely to cause more  
confusion than not. You don't receive half a click at opacity 0.5, you  
shouldn't receive a zeroth of it at opacity 0.

The pointer-events section of SVG 1.1 already hurts my brain — I know  
I'll never remember all those options, it's almost worth implementing  
a mini-language at this point. But it affords a whole lot of control  
over handling pointer events, and doesn't indicate to me that we need  
to change the rules to add opacity in the mix.

> > >    It's not very consistent with the mask element.  And  
> implementing
> > > it with mask may not be relatively simple to implement...
> >
> > In what way is the behavior not consistent with mask?
>
>    <clipPath id="clip1">
>      <rect x="0" y="0" width="640" height="480"/>
>    </clipPath>
>    <g clip-path="url(#clip1)"> <!-- Doesn't recieve events outside  
> rect -->
>         ....
>    </g>
>
>    <mask id="mask1">
>      <rect x="0" y="0" width="640" height="480"/>
>    </mask>
>    <g mask="url(#mask1)"> <!-- Does recieve events outside rect -->
>         ....
>    </g>
>
>    These two snippets have effectively identical results on the
> image, the difference being that the mask will likely have anti- 
> aliased
> edges.

I agree that this erratum provides them with *different* behaviour,  
but not that it makes the behaviours inconsistent.

>  Honestly I think that clipping is simply a lightweight version
> of mask, so I think adding this extra baggage to clip retroactively
> is really not good.  In fact the standard it's self seems to support
> this view (from 14.3.1 Introduction);
>
>      A clipping path can be thought of as a mask wherein those  
> pixels outside the clipping path
> are black with an alpha value of zero and those pixels inside the  
> clipping path are white with
> an alpha value of one (with the possible exception of anti-aliasing  
> along the edge of the silhouette).

I don't think that "can be thought of" is a stringent statement of a  
conformance requirement. This is an author-oriented blurb, and even  
then it is cautious to say that a clipping path "can be thought of" as  
a mask (presumably because it's a simple way of introducing the  
concept), not that it is one.

>    The two features are combined in one chapter in the specification.
> Really this addition to the standard is the first instance where a
> significant _semantic_ difference between the two elements is  
> introduced
> (clipping effects events as well as rendering).

If they weren't semantically different why does the spec include both?  
As you very aptly demonstrated with your example above, you can take  
pretty much any <clipPath> and rename it to <mask> and you will get  
the exact same rendering. In fact, you would save eight characters for  
each definition, and five for each instantiation. Was <clipPath>  
introduced simply to make authors type more?

I think the erratum merely addresses an oversight from that distinction.

>    My fear is that this quick fix will make that future 'clean'
> solution to the problem more complex and likely not backwards
> compatible.

I understand your concern but I don't think that it applies in this  
case. Furthermore, I don't necessarily disagree that the WG could add  
more control over the relationship between events, geometry,  
rendering, etc. but as I indicated above, there already is a fair  
amount of control, and I'd like any such introduction to be backed by  
a simple example of something that can't be done easily enough today.

> > And even if it were a solution, UAs still need to have properly  
> defined
> > interoperable behaviour for hit testing in all cases.
>
>    I would argue the standard already has an interoperable behaviour.
> The standard makes no reference to clipping with regards to hit  
> testing,
> why someone would decide that they should added such a thing when it  
> is
> totally absent from the standard makes no sense to me.  I understand  
> that
> a number of UA agents decided to do just that but it doesn't make it
> correct.  Going this route wouldn't even require an errata it would
> simply be a clarification.

If people understood it differently then the spec has a problem. To  
you it's obvious that clip-path is a mask and therefore shouldn't  
interact with hit testing, to me it's obvious that it's a geometric  
operation and naturally restricts hit testing. We were both on the WG  
for substantial amounts of time, and contributed a substantial amount  
of work on its products. Now think of the poor kittens who weren't and  
are trying to implement. Whichever way the final decision goes this  
requires an erratum, not just a "clarification" (which I'm not sure is  
so different from an erratum in the first place).


-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Tuesday, 9 December 2008 12:24:55 UTC