[whatwg] Hit regions and events

[Rik Cabanier]

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

> On Tue, 4 Mar 2014, Rik Cabanier wrote:
> >
> > Ok. It seems odd that the events are following the dom of the fallback
> > elements and not of the hit regions.
>
> It's what events normally do. I guess we could make this more elaborate,
> but it's not clear what the use case is. Can you elaborate?


The weirdness is that the pseudo hit region DOM can be different from the
fallback dom.
So, if b is a child of a, but the fallback element for b is not a child of
the fallback element for a, you won't get the event on a if you hit b.


> > > 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.
>
> I don't understand. How is the current text not explicit? Are you
> concerned about interfaces that inherit from MouseEvent?
>
>
> > > > Probably only mouse and touch events should be intercepted and
> > > > forwarded.
> > >
> > > Currently touch events are not routed. Should those be added?
> >
> > Yes.
>
> I couldn't really see a sane way to do it (e.g. consider if two touches
> change at the same time, but they started on different regions on the same
> canvas). Do you have a proposal for how to make touch event rerouting work
> for canvas regions?


The touch class [1] could be updated with a region string.
As you move your fingers, the id would reflect what regions your fingers
are on.


> > > > 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
> >    except for having the tabindex attribute specified
> >
> > Would that not include text fields?
>
> How would it include text fields? Can you elaborate on what you mean? I
> don't really follow.


Never mind. I reread the spec and this is covered.

1: http://www.w3.org/TR/touch-events/#touch-interface