[whatwg] Hit regions and events

[Ian Hickson]

On Fri, 28 Feb 2014, Rik Cabanier wrote:
>
> Reading the hit region spec [1] on event handling, I was wondering how 
> event bubbling is supposed to be handled. Let's say you have the 
> following markup:
> 
> <canvas id="cnv">
> <a id="a" href="..."></a>
> <a id="b" href="..."></a>
> </canvas>
> 
> and the following code:
> 
> var ctx = document.getElementById("cnv").getContext("2d");
> var a = document.getElementById("a");
> a.addEventListener("click", function(){...});
> var b = document.getElementById("b");
> // draw region for a
> ctx.addHitRegion({control: a, id: "a"});
> // draw region for b
> ctx.addHitRegion({control: b, parentID: "a"});
> 
> Now, if there's a mouse click for control b, should the event be handled 
> by the handler for control a?

What do you mean by "a mouse click for control b"?

If you mean a click on the region for b, then isn't the algorithm for 
routing mouse events on canvases unambiguous here?

Step 3 gets the region for b, step 5 gets nothing interesting, step 7 gets 
the "b" element, step 8 sets the target to that element, and step 9 
dispatches it.


> Also, should event from the fallback content bubble out of the canvas 
> element or should it act as a barrier?

Since the HTML spec doesn't say anything about this, the DOM spec applies, 
and so bubbling behaviour is as per normal for the event.


On Mon, 3 Mar 2014, Rik Cabanier wrote:
>
> The current hit region specification doesn't state what events are routed
> to the fallback content.

It states "When a MouseEvent is to be fired at a canvas element", which 
seems pretty unambiguous.


> Probably only mouse and touch events should be intercepted and 
> forwarded.

Currently touch events are not routed. Should those be added?


> Thinking a bit more about this feature, it's a bit weird how events are 
> rerouted. Does this happen in any other place in the browser?

Bindings and (in the future, there's a pending bug on this for DOM) 
seamless iframes are two places that come to mind.


> For instance, if the fallback is an edit control and the user 
> drag-selects some text on the canvas, is it expected that this text is 
> also selected in the edit control?

You can't validly include a text field in canvas fallback precisely 
because of this kind of thing. See:

   http://whatwg.org/html#best-practices


On Tue, 4 Mar 2014, Rik Cabanier wrote:
>
> Talking to roc, event retargeting will be very complex to implement.

Why would it be complicated?


> To make it simpler for authors and browser vendors, we should not intercept
> the events. Instead, just keep sending them to the canvas object but add
> the region's ID to it.
> If the author wants to do the retargeting, he could easily do this in JS.

Having the event rerouted makes life significantly easier for authors. For 
example, it means they don't have to do any hit testing or click 
management for buttons, checkboxes, radio buttons, etc. It all just works.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'