Re: Should the base svg tag receive events?

Hi Doug,

I agree, I started off by accepting the specification but then I justify and 
agree with the implementations behavior, which simply bypasses the spec. 
That is because I was underestimating the viciousness of those paragraphs 
(and was also trying to be fifty-fifty which never works for me!). Here goes 
without compromises.

SUBJECT 1 – ON PROPAGATION

http://www.dotuscomus.com/test/events/content.xhtml

I extended your example to squeeze some more information out of it. A few 
observations:

- Registering the event on the html document.documentElement only, will 
never trigger the handler when clicking on the embedded svg.

- Registering the event on the embedded svg document.documentElement will 
never show any awareness or means of accessing its parent node, the <object> 
tag, or any of its ancestors, whether in the ascending or descending order.

- As last object of the alert I have tried all the possibilities to access 
the parent document, using these words in all combinations: 
evt.currentTarget; parent; window; parentNode; document; documentElement; 
etc.

- window.document returns "object Document" when clicking on the html, but 
"SVGDocument" when clicking on the svg.

- In all other cases, clicking on the svg returns either "object SVGElement" 
or "object SVGSVGElement"

Note also, as an example, that parent.print() prints from the html but not 
from the svg, while instead it prints from a standalone (not embedded) svg. 
Although window or parent are recognized as "object DOMWindow" I didn't find 
anything that I could do with them.

"En passant", let's note that for Opera and Firfox the embedded svg is 
transparent, but for the webkit it's not.

Result:
There is no communication or awareness between the "hosting document" and 
the document embedded through the <object> tag. The former does not consider 
the latter as operating anywhere else than in its own scope and the latter 
operates strictly in its own scope (I'm not sure if scope is the right term 
here). Therefore the events phases and propagation are limited to the scopes 
into which the events where defined/registered.

This result is what I observed as browsers' behavior, I don't mean to imply 
that it is right or wrong. My opinion would be that yes, the communication 
up and downstream should be made possible.


SUBJECT 2 – ON THE SPEC'S POINTER EVENTS

Isn't the svg spec being a little abusive in this case? I really think it 
is. It seems like an attempt  to interfere with the client-side javascript 
versions as  defined in relation to html, and in short with the DOM2 event 
models. I even wonder if the spec was not doing this inadvertently, because:

1) I don't have the impression the proposal was designed. Proof is the fact 
that a great number of related issues are not addressed, the currentTarget 
property being just one of the most immediately apparent.
2) If the proposal was well thought and self-conscious it would/should have 
been "clearly" and "unequivocally" exposed within the javascript binding 
documents and its annexes.
3) Important: the proposal does not advance any justification or design for 
breaking the client-side javascript practices as established in relation to 
html or the DOM2 event models.
4) It seems like no real measure of the implications and consequences was 
taken.
5) The section does contain many contradictions, some of which have been 
pointed out in the thread, and the language seems tortured and obscure 
compared to the rest of the spec.

To extend on point 5, if it was the intention to use the word "target" in 
reference to the "target" property of the "event" object, then that should 
have been clearly and unmistakably specified, using a strictly technical 
language, preferably the same as in [1], where that property is referred to 
as the event's target, not the target element. There's a big difference, you 
know! Also, by using in places "target element" in italic, dematerializes 
the association of the word "target" with the target property of the event 
object, which was probably the intention of the authors the way I understand 
it now. I always interpreted the somewhat casual language as an information 
to the authors to not expect wonders if an event handler attempts to carry 
out *some* operations on non graphical elements. Who could possibly imagine 
that the authors would have simply forgotten to consider an important number 
of other possible operations? The drag&drop has been evoked, but also bring 
to front, dynamically appending-removing nodes, display=none to 
display=block, as well as many others.

I assume that the implementers didn't find any viable reason to break the 
client-side javascript in relation to html or the DOM2 event models. It 
seems that they simply did not consider.

The document http://www.w3.org/TR/SVG11/ecmascript-binding.html (which 
doesn't seem to exist anymore) specifies that SVGSVGElement implements the 
EventTarget interface.

I hope we can avoid it, but if necessary we can take every single sentence 
at [1] 1.2.2 Event capture and see that the svg spec does break it.

The statement:
"For all UI event-related features defined as part of the SVG language via 
event attributes or animation, the event model corresponds to the event 
bubbling model described in DOM2 [DOM2-EVBUBBLE]. The event capture model 
from DOM2 [DOM2-EVCAPTURE] can only be established from DOM method calls."
Unless I'm really way out, doesn't that obliterate 16.4 altogether?

The statement:
"The event is either initially dispatched to the target element, to one of 
the target element's ancestors, or not dispatched, depending on the 
following:"
If I go by the spec, in particular the impossibility to be the target of 
pointer events for non graphic elements, the above is an antithesis and the 
list that follows that statement has no reason to exist. Try this: a target 
is and remains a target; if there's no target then how can a non target be 
considered, or not, a target if there's not supposed to be an event through 
which the user agent is supposed to determine if a target is indeed one, in 
the absence of an event resulting from the absence of a target? The dog is 
biting its tail.

This being the state of the facts and because of the argument at point 3, I 
would recommend that the whole section be purely and simply removed. It has 
absolutely no reason for being. If there is a valid reason for it to exist 
that I don't know of, I would like to know it as I, as well as others, might 
be missing something important.

If such reason is exposed here and now, and if it fails to gather the 
general consent of authors and implementers, or if no valid reason is 
exposed, then the spec must conform to the common practices and the observed 
browsers' behavior by recognizing them as standards (my recent post 
http://tech.groups.yahoo.com/group/svg-developers/message/63966 comes very 
handy here). Otherwise the implementations must be arbitrarily forced to 
comply, with all the consequences that that implies.

Perhaps the best solution to this would be, like Doug suggests, a background 
for svg and possibly group containers (initially opaque!!). But there too, 
the case of a graphic element with display=none in an otherwise empty svg or 
group where a click is supposed to reveal the object as well as many other 
issues must be carefully evaluated.

[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html

Domenico Strazzullo




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


> Hi, Nico-
>
> I'm not clear on where you stand on this issue.  Could you break it down 
> to use cases, including the case where SVG overlaps HTML content? [1]
>
> [1] http://www.schepers.cc/svg/blendups/overlay/test/content.xhtml
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG and WebApps WGs
>

Received on Monday, 16 August 2010 10:35:44 UTC