[whatwg] Hit regions and events

[Rik Cabanier]

On Wed, Mar 5, 2014 at 2:27 AM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Mar 5, 2014 at 5:11 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> On Tue, Mar 4, 2014 at 6:51 PM, Robert O'Callahan <robert at 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.