[whatwg] Hit regions and events

Ian Hickson ian at hixie.ch
Tue Mar 4 18:07:35 PST 2014

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?

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

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

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

More information about the whatwg mailing list