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

On 05/05/2011 04:28 PM, Olli Pettay wrote:
> On 04/16/2011 02:20 AM, Ryosuke Niwa wrote:
>> On Fri, Apr 15, 2011 at 2:54 AM, Olli Pettay <Olli.Pettay@helsinki.fi
>> <mailto: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
>> <mailto: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.
>
>
> Still one thing. 'click' event is there to capture clicks, not
> mousedown, mousemove[0-*], mouseup. It is quite strange if a
> "click" might actually mean something closer to drag.


DOM 2 Events specifies click event in a bit different way:
"A click is defined as a mousedown and mouseup over the same screen 
location. " But the idea is still the same. "click" event is for a 
click, not random mousedown, mousemove, mousemove, mousemove, ..., mouseup.




>
>
>
>>
>> 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
>>
>
>
>

Received on Friday, 6 May 2011 09:50:38 UTC