- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 5 Mar 2014 11:29:45 -0800
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>
On Wed, Mar 5, 2014 at 2:27 AM, Robert O'Callahan <robert@ocallahan.org>wrote: > On Wed, Mar 5, 2014 at 5:11 PM, Rik Cabanier <cabanier@gmail.com> wrote: > >> On Tue, Mar 4, 2014 at 6:51 PM, Robert O'Callahan <robert@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.
Received on Wednesday, 5 March 2014 19:30:10 UTC