Re: Should the base svg tag receive events?

I really think that on this subject the spec is clear and I don't see any 
contradictions either. The implementers obviously found it clear also, since 
their implementations have the same behavior. Aren't we forgetting the 
currentTarget property? The currentTarget is the element on which the event 
was registered; if that element is not suitable as target then the 
implementation ignores (rather than discard) the event. Yes, only, the major 
implementations, excluding ASV, do not ignore, which I personally think is 
good news. See the 5th paragraph below.

A <g> container is specifically designed, among other things, to act as a 
group (great!). It's the most convenient place where to set 
attributes/properties to be inherited by all of its children whenever they 
are eligible for a particular attribute/property. I don't think we need the 
example of 50,000 text elements with font-size 7pt or click event or 
pointer-events on each of them.

An <svg> element is also a super group with funky properties. You can 
register pointer events on it.

As much as a group cannot be the target of pointer events, it is not the 
target of transformations either. If we set a transformation on an empty 
group we are not likely to see much happening. Likewise, if we register 
events on an empty group nothing visual happens. But we can still query the 
currentTarget property, and rightfully so! If the spec says that a container 
element cannot be the target of pointer events, it does not say anywhere 
that pointer events cannot be registered on them, or does it? The first is a 
description of status and behavior, the second is an operation, they do not 
relate and are not mutually exclusive or contradictory in any way.

Note that in Opera, Firefox, Chrome and Safari, pointer events registered on 
an outmost svg container with no graphical elements (strictly empty), do 
trigger the event handler(s). In ASV they don't. It's interesting that both 
the currentTarget and the target properties designate the svg element, 
whereas to be strict only the currentTarget should (or perhaps it is said 
somewhere that in the absence of target then currentTarget will assume the 
status of target?). The event must trigger because nowhere it is said -that 
I'm aware of- that if a container does not have any element in it qualifying 
as target for pointer events, i.e. a graphical element, it should cease to 
be the currentTarget. Simply think of elements that may be appended 
dynamically, which justifies that a group be initially empty.

> The right way to define this is to say that a DOM event is always 
> dispatched, but that the target when there are no graphical elements under 
> the pointer is the nearest ancestor of the root SVG element that's 
> sensitive to events or something.  There are probably other ways to define 
> it too, but what the spec has now seems pretty clear and isn't right.

To say that this would be the right way is arbitrary. A target cannot be the 
nearest ancestor in any case. What you really need is to check where the 
capturing phase originates, is it the svg document or the Document object 
(as: parent, window)? I honestly don't know. Then you can check with the 
bubbling phase also; if the capturing phase originates at the level of the 
Document object  then the bubbling phase should also end up there. If this 
is true and any of the ancestors have a specially registered capturing event 
handlers (setting the third parameter to true) then there you have it your 
event. I'm sure others have experimented with this.

Domenico Strazzullo


----- Original Message ----- 
From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
To: "Doug Schepers" <schepers@w3.org>
Cc: "Kevin Ar18" <kevinar18@hotmail.com>; <www-svg@w3.org>
Sent: Friday, August 13, 2010 2:22 PM
Subject: Re: Should the base svg tag receive events?


> On 8/13/10 3:19 AM, Doug Schepers wrote:
>>> Per the letter of the SVG spec right now, that event should not even be
>>> fired. In particular, a click listener added on the window should not
>>> fire at all when the viewport is clicked after loading that document. I
>>> would be very surprised if any browser implemented that behavior,
>>> though; it seems pretty broken to me.
>>
>> Why's that? It seems very logical to me, actually... there's nothing to
>> click on, therefore, there should be no pointer events.
>
> Because if I click somewhere in the window, the window itself should get a 
> click event.  Breaking that doesn't seem reasonable.  The only question is 
> what the target of the event should be.
>
>> Are you referring to this?
>> [[
>> If a target element for the pointer event does not exist, then the event
>> is ignored.
>> ]]
>
> Yes.
>
>> I don't interpret that to mean that the event is discarded for any
>> content outside the SVG context... rather, I read it to mean that in
>> that case, SVG doesn't do anything with the action... the action is
>> ignored, and not treated as an interaction with the SVG content. Put
>> another way, SVG doesn't intercept the event, and it should be treated
>> normally by whatever is "below" the SVG fragment.
>>
>> To be honest, I find it a bit difficult to interpret that as saying
>> anything about the events or DOM of some host document; SVG doesn't
>> usually say anything at all about the behavior of host languages. Did I
>> miss something else?
>
> Look, the spec says that you do one of two things.  Either you take the 
> input and dispatch a DOM event through the normal DOM event dispatch path 
> or you "ignore the event".  If your interpretation is taken that this is 
> just talking about SVG and that host languages should do their own 
> additional thing, then the only way to make things "work" in the case when 
> SVG ignores the event is if the embedding document itself defines that 
> events must be dispatched to a DOM node indepedently of what SVG does. 
> But in that case, clicking on a graphical element in SVG will dispatch two 
> DOM events: one to the graphical element and one to something in the 
> embedding document.  That's clearly wrong.
>
> The right way to define this is to say that a DOM event is always 
> dispatched, but that the target when there are no graphical elements under 
> the pointer is the nearest ancestor of the root SVG element that's 
> sensitive to events or something.  There are probably other ways to define 
> it too, but what the spec has now seems pretty clear and isn't right.
>
> I'm out for the next week, so the next reply, if needed, will be laggy, 
> but not because I'm ignoring you.
>
> -Boris
>

Received on Friday, 13 August 2010 17:09:16 UTC