Re: Phasing out mouse compatibility events on tap?

On Fri, Jan 16, 2015 at 4:04 PM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> On 16/01/2015 18:08, Matt Gaunt wrote:
>
>> The end goal of my comment is: what does a sane API look like - touch
>> events result from touch, mouse events result from mouse, nothing more,
>> nothing less.
>>
>> I agree doing compat events is great for older sites and we shouldn't
>> try and guess if the site is "old" or not - it's too late in the game
>> for that to be using anything like the viewport meta tag.
>>
>
> DOCTYPE switching, perhaps? I jest, of course...
>
>  So how about we just move to having an api to disable compat mouse
>> events? I would love this and by default, no behavior change.
>>
>
> My preference would definitely be a new method, a la e.
> preventMouseCompatibilityEvents() (or something a bit more terse, but I'd
> rather be explicit enough to avoid confusion).
>
> Only question is: as "click" is currently handled as a compatibility event
> as well in the TE model, would the above also kill "click"?


Why do you say click is handled as a compatibility event?  I consider TE to
be pretty similar to PE in the regard that "mouse*" events are for compat,
but "click" supplies real semantics / value outside of compat (it's the
"activate" or "tapGesture" event IMHO).  So personally if we had a method
called "preventMouseCompatibilityEvents" I would NOT want it to effect
"click".


> I guess it wouldn't be a deal-breaker if it did, mind, and would keep
> things straightforward enough (i.e. wouldn't change the definition of
> "compatibility event" - after we specify that definition in the TE
> Errata/v.2). In fact, if it did, that would also make the naive


> var clickEvent =  ('ontouchstart' in window ? 'touchend' : 'click');
> blah.addEventListener(clickEvent, function() { ... }, false);
>

Whoa - detecting a 'tap' is more involved than that in practice. You don't
want your 'click' function to fire for every swipe, or fire multiple times
after a multi-touch, right?

pattern redundant, and instead allow for BOTH touchend and click to be
> added as event listeners, since the click could be explicitly suppressed.
>

> foo.addEventListener('touchstart', function(e) {
>     e.MouseCompatibilityEvents();
>     ...
> }, false);
>
> /* doubled-up event listeners */
>
> foo.addEventListener('touchend', someFunction, false);
> foo.addEventListener('click', someFunction, false);
>
> This is conceptually very similar to some of the current advice (for iOS
> and old Android WebKit at least, where no other method to remove the 300ms
> delay is available - see http://patrickhlauke.github.
> io/touch/tests/results/#suppressing-300ms-delay)
>
> foo.addEventListener('touchstart', function(e) {
>     e.preventDefault();
> }, false);
>
> /* doubled-up event listeners */
>
> foo.addEventListener('touchend', someFunction, false);
> foo.addEventListener('click', someFunction, false);
>
> but without the side effect that preventDefault() has of also killing
> scrolling, zooming, etc.
>
> Anyway, sorry, rambling away...but hopefully makes some kind of sense.
>
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>