Fw: Should the base svg tag receive events?

----- Original Message ----- 
From: "Domenico Strazzullo" <nst@dotuscomus.com>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: <www-svg@w3.org>
Sent: Tuesday, August 24, 2010 1:15 PM
Subject: 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 15:09:53 UTC