Re: Click event on button element when event targets of the associated mousedown and mouseup are different

On Fri, Apr 15, 2011 at 2:54 AM, Olli Pettay <Olli.Pettay@helsinki.fi>wrote:
>
> Nope, it is not the DOM 3 Events definition of click which leads to that
> bug. It is the hit testing. In Firefox hit testing leads mouse events to be
> dispatched to button element and click event dispatching to
> work per the spec also in this case.
>

Oh, sure.  I didn't mean that Firefox's behavior is due to DOM Level 3
Events.  I only referred to it to be the cause of the WebKit bug.

On Fri, Apr 15, 2011 at 2:59 AM, Olli Pettay <Olli.Pettay@helsinki.fi>
 wrote:
>
>  Nope, it is not the DOM 3 Events definition of click which leads to that
>> bug. It is the hit testing. In Firefox hit testing leads mouse events to
>> be dispatched to button element and click event dispatching to
>> work per the spec also in this case.
>>
>
> I could still add that the reason for Firefox's behavior is HTML 4 spec
> "Buttons created with the BUTTON element function just like buttons created
> with the INPUT element, but they offer richer rendering possibilities"
>

I see. That's a reasonable argument. In fact, IE7 / IE8 seem to have the
same behavior.

Should D3E define hit testing? I feel like D3E is a better place to spec
this than HTML5 but I'm not even sure if we can spec precisely because there
might be some platform/browser-specific behavior that needs to be
maintained.

Now putting hit-testing problem aside, do you think we should only fire a
click event when target nodes match?

If there are no strong oppositions, *I'd like to propose to change the spec
to always fire click events on the lowest common ancestor* so that websites
can at least catch the event on button element in the said situation.

IE9 seems to special case button element and doesn't fire click event when
mousedown happens inside button and mouseup happens elsewhere but that's an
edge case that might not be worth spec'ing right now.

- Ryosuke