W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] Hit regions and events

From: Rik Cabanier <cabanier@gmail.com>
Date: Wed, 5 Mar 2014 11:29:45 -0800
Message-ID: <CAGN7qDAJYkPFTZtwe3dfzdRXcyMxFDeMBdF5SP1yc-yRp5BWBg@mail.gmail.com>
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

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
Received on Wednesday, 5 March 2014 19:30:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC