[whatwg] Hit regions and events
cabanier at gmail.com
Tue Mar 4 18:39:23 PST 2014
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
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  could be updated with a region string.
As you move your fingers, the id would reflect what regions your fingers
> > > > 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.
More information about the whatwg