[whatwg] Hit regions and events

[Rik Cabanier]

On Tue, Mar 4, 2014 at 3:53 PM, Ian Hickson <ian at hixie.ch> wrote:

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

Ok. It seems odd that the events are following the dom of the fallback
elements and not of the hit regions.


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

That's not all that clear :-)
Maybe it's better to state explicitly which events are routed.


> > Probably only mouse and touch events should be intercepted and
> > forwarded.
>
> Currently touch events are not routed. Should those be added?
>

Yes.


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


I saw you extended the list of fallback elements to include:


   -

   an element that would not be interactive
content<http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content>
except
   for having the
tabindex<http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#attr-tabindex>
attribute
   specified


Would that not include text fields?


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

I'm still trying to find that out. I was surprised too.


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