Re: Should the base svg tag receive events?

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?

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.

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.

> [[
> 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.

> 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.

-Boris

Received on Friday, 13 August 2010 06:03:23 UTC