Re: Finished ISSUE-2364, ACTION-2834, Regarding Pointer Events on the Root

On Thu, 03 Feb 2011 05:55:15 +0100, Doug Schepers <schepers@w3.org> wrote:

> Hi, folks-
>
> Cameron McCormack wrote (on 11/24/10 5:48 PM):
>> ISSUE-2364 - ACTION-2834 on DS
>>    SVG 1.1 may be ambiguous about the root element acting as a proximal
>>    event target
>
> To resolve this issue, as discussed on the telcon and at the F2F, I have  
> changed the description of pointer event processing to be more precise  
> and separate different aspects; added definitions for 'pointer' and  
> 'hit-testing'; and clarified that this spec doesn't define root-element  
> event processing in embedded content, but that it will be defined in a  
> future spec.
>
> I only changed the master, not the publish draft.
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, WebApps, and Web Events WGs

[[
Note that the svg element is not a graphics element, and should not be the  
target of pointer events, though events may bubble to this element. If a  
pointer event does not result in a positive hit-test on a graphics  
element, then it should evoke any user-agent-specific window behavior,  
such as a presenting a context menu or controls to allow zooming and  
panning of an SVG document fragment.
]]

I think this should be removed, because it doesn't add anything IMHO. And  
if it's informative (which is what it sounds like to me) then it should be  
clearly labeled as such.

Besides, the UA might want to have context menus for e.g rightclicking on  
particular elements even if there was a positive hit-test.

The Events processing section is a bit more clear, but:

[[
4. If the element and the event type are associated with the activation or  
cancelation of declarative animation, and if no CSS property currently  
applied conflicts with the animation, the effects of that animation must  
be applied to the relevant element;
]]

This is a new point, and it's unclear, "if no CSS property currently  
applied conflicts with the animation"?

[[
5. If the element is a hyperlink (e.g., it is a child element of an 'a'  
element), and the pointer event is of a type that activates that hyperlink  
(e.g. via a mouse click), and if the hyperlink traversal changes the  
context of the content (e.g. opens a different document, or moves the  
pointer away from this element by moving to another part of the same  
document), then no further processing for this element is performed;
]]

Should have used the old wording "If a hyperlink is invoked in response to  
a user interface event, the hyperlink typically will disable further  
activation event processing", the point being that a UA may prevent  
invoking the link traversal e.g to provide text-selection of some  
textcontent in the hyperlink subtree. I think that is useful behavior.

Another minor thing, usually title tooltips are shown after a slight  
delay, while the css pseudoclasses are immidiate, suggesting that points 2  
and 3 should swap order.

In the section "The 'pointer-events' property":

[[
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.
]]

This translates to: "The 'mask' and 'filter' properties have no effect on  
pointer-events processing (it's as if they were not specified)." which  
IMHO would be more clear (recent threads on www-svg indicate some  
confusion even with the above wording).

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, 16 February 2011 09:37:48 UTC