Re: [whatwg] Hit regions and events
On Wed, Mar 5, 2014 at 5:11 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 4, 2014 at 6:51 PM, Robert O'Callahan rob...@ocallahan.org wrote: The question remains: what should happen in Rik's example? More generally, is this event rerouting supposed to be able to trigger browser default event handling behavior, or only DOM event dispatch? The spec implies that default event handling is supposed to take place. ie: With a control, they can make routing events to DOM elements automatic, allowing e.g. clicks on a canvas to automatically submit a form via a button element. Likewise, if the region is backed by an a element that represents a hyperlink, clicking on that region should navigate you to that link. I don't really understand why that would make the implementation more difficult though. Wouldn't we get this for free by retargeting the event? The problem is that if these retargeted events can trigger default browser behavior, the browser has to be able to compute the position of the event relative to the new target DOM node, and it's not clear how to do that. Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Hit regions and events
On Wed, Mar 5, 2014 at 2:27 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Wed, Mar 5, 2014 at 5:11 PM, Rik Cabanier caban...@gmail.com wrote: On Tue, Mar 4, 2014 at 6:51 PM, Robert O'Callahan rob...@ocallahan.org wrote: The question remains: what should happen in Rik's example? More generally, is this event rerouting supposed to be able to trigger browser default event handling behavior, or only DOM event dispatch? The spec implies that default event handling is supposed to take place. ie: With a control, they can make routing events to DOM elements automatic, allowing e.g. clicks on a canvas to automatically submit a form via a button element. Likewise, if the region is backed by an a element that represents a hyperlink, clicking on that region should navigate you to that link. I don't really understand why that would make the implementation more difficult though. Wouldn't we get this for free by retargeting the event? The problem is that if these retargeted events can trigger default browser behavior, the browser has to be able to compute the position of the event relative to the new target DOM node, and it's not clear how to do that. The target node is not updated per the spec; it will still be the canvas element: If there is a control, then target the event object at control instead of the canvas element. so, the position will always be relative to the canvas element, not the region.
Re: [whatwg] Hit regions and events
On Tue, Mar 4, 2014 at 3:53 PM, Ian Hickson i...@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
contenthttp://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#interactive-content
except
for having the
tabindexhttp://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.
Re: [whatwg] Hit regions and events
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hit regions and events
On Tue, Mar 4, 2014 at 6:07 PM, Ian Hickson i...@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
Re: [whatwg] Hit regions and events
On Wed, Mar 5, 2014 at 12:53 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Feb 2014, Rik Cabanier wrote: 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 The question remains: what should happen in Rik's example? More generally, is this event rerouting supposed to be able to trigger browser default event handling behavior, or only DOM event dispatch? Rob -- Jtehsauts tshaei dS,o n Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.rt sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
Re: [whatwg] Hit regions and events
On Tue, Mar 4, 2014 at 6:51 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Wed, Mar 5, 2014 at 12:53 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Feb 2014, Rik Cabanier wrote: 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 The question remains: what should happen in Rik's example? More generally, is this event rerouting supposed to be able to trigger browser default event handling behavior, or only DOM event dispatch? The spec implies that default event handling is supposed to take place. ie: With a control, they can make routing events to DOM elements automatic, allowing e.g. clicks on a canvas to automatically submit a form via a button element. Likewise, if the region is backed by an a element that represents a hyperlink, clicking on that region should navigate you to that link. I don't really understand why that would make the implementation more difficult though. Wouldn't we get this for free by retargeting the event?
Re: [whatwg] Hit regions and events
On Tue, 4 Mar 2014, Rik Cabanier wrote: On Tue, Mar 4, 2014 at 6:07 PM, Ian Hickson i...@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's not really a fallback DOM. The events don't bubble through the regions if they're not attached to a control. The parent chain is just a convenient way of managing related regions. 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. So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hit regions and events
On Tue, Mar 4, 2014 at 8:10 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Mar 2014, Rik Cabanier wrote: On Tue, Mar 4, 2014 at 6:07 PM, Ian Hickson i...@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's not really a fallback DOM. The events don't bubble through the regions if they're not attached to a control. The parent chain is just a convenient way of managing related regions. OK 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. So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? yes. This is not all that different from how the mouse events work with hit regions. You'd get a mouse enter as you enter the canvas with the mouse. As you move over the canvas, you will get more mouse move events with different region id's and target elements. There will be no separate mouse enter/leave events when you enter/leave a region.
Re: [whatwg] Hit regions and events
On Tue, 4 Mar 2014, Rik Cabanier wrote: So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? yes. Yes... what? I don't understand. This is not all that different from how the mouse events work with hit regions. It's different in the important sense that there's only one mouse pointer, but there can be multiple ongoing touches. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Hit regions and events
On Tue, Mar 4, 2014 at 8:30 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 4 Mar 2014, Rik Cabanier wrote: So what would you do in the case where you start two touches on different regions, then move them at the same time to two other different regions at the same time? What would you put in the touchmove event's object? The touches attribute [1] of the touch event would contain 2 touch elements. Each touch element would have as target the canvas element and contain the id of the hit region. As you move, the touch elements would update their id as you enter other regions. Basically, everything is the same, except you hit test each touch and if there's a hit, fill in the id. This is not all that different from how the mouse events work with hit regions. It's different in the important sense that there's only one mouse pointer, but there can be multiple ongoing touches. Each touch acts conceptually like a mouse pointer. 1: http://www.w3.org/TR/touch-events/#widl-TouchEvent-touches
