Re: Should the base svg tag receive events?

----- Original Message ----- 
From: "Boris Zbarsky" <bzbarsky@MIT.EDU>
To: "Domenico Strazzullo" <nst@dotuscomus.com>
Cc: <www-svg@w3.org>
Sent: Monday, August 23, 2010 7:51 AM
Subject: Re: Should the base svg tag receive events?


> On 8/13/10 1:08 PM, Domenico Strazzullo wrote:
>> The currentTarget is the element
>> on which the event was registered;
>
> Yes.
>
>> if that element is not suitable as
>> target then the implementation ignores (rather than discard) the event.
>
> There is no concept of "not suitable as target" in DOM Events.  For a 
> bubbling event, all ancestors of the event target will have the event 
> bubble to them (unless stopPropagation is called).

I buy this. Then remains the question of the agent's behavior in terms of
determining the "suitability" of an element as to making the object (not
target) of manipulations or operations defined in the handler. The situation
of "not suitable" can never arise because an element can always make the
object of DOM manipulation, this independently of its status in respect of
the event (event.target or event.currentTarget or no status) and because of
its status of inheriting descendant, and, independently of the fact that the
element:
  a) was a child, or only child, displayed or not, of its container, whether
<svg> or <g> or other,
  b) was appended dynamically to an otherwise empty container and not
present

at the time the event listener was registered.

In the second situation the event could only be registered on the container.
Applications relying on this mechanism would break if the DOM spec is
overridden.

Equally important is the fact that, if I'm not wrong, SMIL allows an
animation to be triggered by a pointer event, by registering a listener on
any element whose ID is passed as reference.

Could there be slight confusion for some between event registration and
event dispatching, propagation and handling?

>
>> 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
>
> Well, what would you expect the target to be in that case?

I was reading the wording of the spec. I approve the <svg> and <g> elements
to be event.target.

>
>> To say that this would be the right way is arbitrary. A target cannot be
>> the nearest ancestor in any case.
>
> Well... the target of a click event should be some EventTarget (vacuous 
> statement there).  But for every click that happens, a click event needs 
> to fire.  The only question is where to target it.  Once you decide what 
> the target is, DOM Events takes over from there in terms of what event 
> listeners fire.

As you stated, there is no concept of "not suitable as target" in DOM
Events. It remains that a target of an event cannot be anything else than
itself, excluding any other possibility. That's where the notion of
currentTarget comes in. As I said, I'm fine with the container assuming the
status of event.target where none of its children are displayed or in the
absence of them. It will not affect the good functioning and predicted
behavior of a program.

>
>> 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
>
> The target is the same in both phases, by definition of the phases. It's 
> an invariant of the given event dispatch.

Yes. I still don't know the origin.

Domenico


>
> -Boris
>

Received on Tuesday, 24 August 2010 11:16:07 UTC