RE: Pointer Events and click

On the telecon today, consensus was that this issue has resolved itself on this thread.  For tracking purposes, I opened bug 20240 for this in Bugzilla [1], included the some of conversation we had here, and resolved it "WORKSFORME."

If you feel this issue hasn't been addressed completely, please feel free to reactivate the bug.

Thanks!

-Jacob

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20240

-----Original Message-----
From: Jacob Rossi [mailto:Jacob.Rossi@microsoft.com] 
Sent: Tuesday, December 4, 2012 8:04 AM
To: olli@pettay.fi; Scott González
Cc: Daniel Freedman; public-pointer-events@w3.org
Subject: RE: Pointer Events and click

>> FYI, in Gecko it is all about the target of the mousedown and up. They must be the same element (per DOM 3 Events).

Same in IE. I believe this behavior for click is interoperable (with perhaps exceptions for the <button> element).


-----Original Message-----
From: Olli Pettay [mailto:Olli.Pettay@helsinki.fi]
Sent: Tuesday, December 4, 2012 7:23 AM
To: Scott González
Cc: Jacob Rossi; Daniel Freedman; public-pointer-events@w3.org
Subject: Re: Pointer Events and click

On 12/03/2012 03:10 PM, Scott González wrote:
> On Sun, Dec 2, 2012 at 6:27 PM, Jacob Rossi <Jacob.Rossi@microsoft.com <mailto:Jacob.Rossi@microsoft.com>> wrote:
>
>     " There are cases in which a developer would want to conditionally react to a click based on pointer movement" sounds to me like the uses cases
>     delve into gesture recognition, which is out of scope for our charter.
>
>
> I don't have a major concern either way, but I just wanted to note a 
> case in jQuery UI where we care about conditionally forcing a click 
> based on pointer movement, but we don't actually care about gestures.
> We have a button widget which can build on top of various markup. When applied to a checkbox or radio, we visually hide the form control and style the label. Browsers generally have some tolerance for movement during a click. At least in Firefox, there is a noticeable difference in the tolerance allowed when clicking on a checkbox vs. clicking on a label associated with a checkbox.

FYI, in Gecko it is all about the target of the mousedown and up. They must be the same element (per DOM 3 Events).



> This is likely to make text selection of the label prevent toggling 
> the checkbox. However, since we're treating the label as a button, 
> we're not concerned with text selection and would like the larger movement tolerance that comes with the form control itself. The only way to work around this is to listen to mousedown/up and then check if a click or change event occurred on the checkbook and if not manufacture one.
>
> I believe this is the only place in jQuery UI where we conditionally care about clicks based on movement, so I don't have strong feelings either way.
> I do agree with everything else Jacob has said. In general, I don't 
> think we should use "developers are familiar with X from Touch Events"
> as a strong argument for anything in Pointer Events as the majority of developers are not familiar with Touch Events and many that are familiar with them have complaints about them.

Received on Tuesday, 4 December 2012 19:04:48 UTC