Re: Should the base svg tag receive events?

Hi, Boris-

Boris Zbarsky wrote (on 8/13/10 2:02 AM):
> On 8/13/10 1:07 AM, Doug Schepers wrote:
>> The SVG root should not receive any mouse events if none of its
>> graphical children has received the event. Any implementation which does
>> treat the SVG element as if it can receive pointer events is
>> non-conforming. Note that Opera, at least, does seem to exhibit the
>> correct behavior.
>
> How do you figure?
>
> <svg xmlns="http://www.w3.org/2000/svg">
> <script>
> document.documentElement.addEventListener("click", function() {
> alert('clicked')}, false);
> </script>
> </svg>
>
> Load that in Opera, then click anywhere in the viewport. I see an alert.
> Do you not?

You're right, I misinterpreted the results of the test case Kevin posted 
before.  I wrote a new test [1] that demonstrates that Opera and FF 
behave the same (which I contend is incorrect behavior).


> 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.  Pragmatically, 
I can see a use case for allowing it, as I said, but the way it's 
defined now does seem reasonable.


> Furthermore, per the letter of the SVG spec right now (SVG 1.1 section
> 16.4), if an SVG fragment is included in an XML document and a user
> clicks inside the SVG fragment but not on any graphical element, the
> click is silently discarded and no click event is fired to any element,
> whether in the SVG fragment or outside it. I happen to think this was
> not at all the intended behavior in the spec, but that's what it says
> the right behavior is.

Are you referring to this?
[[
If a target element for the pointer event does not exist, then the event 
is ignored.
]]

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?


>> [[
>> For each pointer event, the SVG user agent determines the target element
>> of a given pointer event. The target element is the topmost graphics
>> element whose relevant graphical content is under the pointer at the
>> time of the event.
>> ]]
>
> Right, but as I pointed out above this section of the spec makes no
> sense in various situations. Which means that UAs have to ignore this
> paragraph some of the time, and then the only question becomes when it
> should be ignored...
>
> I agree that Gecko's behavior here should probably be changed, but the
> spec needs some serious rewording to actually specify what I think you
> think it's supposed to be saying.

Clearly, there are different interpretations of that section, so we 
should rework it.  In general, SVG was worded only to define what 
happens in SVG, not in HTML, or in some combination of HTML and SVG; I 
think they were careful there not to impose behavior on another 
technology, to a fault.  But I think we agree that those overlaps do 
need to be specified in order to get logical, consistent, and 
interoperable behavior, especially with SVG moving toward tighter 
integration with HTML, CSS, etc.

Tomorrow, when I'm more awake, I'll take a stab at clarifying what that 
section should say.  If anyone has any concrete suggestions, I'll be 
happy to integrate them.


>> We will spell this out more explicitly in SVG 2.
>
> Please do. ;)
>
>> In the meantime, the
>> sections I cite above should be sufficient justification for fixing this
>> bug in any browsers with this bug. It's possible we could even clarify
>> this in SVG 1.1 2nd Edition, if that would help.
>
> It'd help to make the spec actually say what it means to say, for sure.

Will do, thanks for the feedback.


[1] http://www.schepers.cc/svg/blendups/overlay/test/content.xhtml

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Friday, 13 August 2010 07:19:26 UTC