Re: Phasing out mouse compatibility events on tap?

Let me take a stab at summarizing this long thread:

1) There are lots of websites that depend on the compatibility mouse events
fired on a tap, and it seems likely we'd be able to change that in any
reasonable timeframe.  Therefore we're stuck firing these by default (and
our ability to make dev's life simpler is therefore limited).

2) If we did have an API for disabling compat events, folks agree that we'd
still always want to fire "click" events.  But even those click events
should have some way to identify them as being fired from touch events.
Therefore we want something like the firedFrom API regardless.

3) There isn't really a compelling performance argument for an up-front
suppression rather than relying on 'firedFrom'.  Normally it should be
possible to re-use hit-test results across multiple events.

Note that in chromium we've had some trouble with this as sites often
depend, for example, on changes that occur in a mousemove or mousedown
handler being reflected in the results of the hit-test for the mouseup
handler.  But this just means the hit-test caching needs to be smart enough
to get invalidated on DOM/style mutation.  *Jacob, *does IE do some
sophisticated caching like that?

4) In composition scenarios, the decision whether to "fire" a compatibility
event may need to be different for each event handler.  So in the limit you
end up with an API that is virtually equivalent to this trivial polyfill
over top of firedFrom (and therefore really only adds complexity):

Element.prototype.addEventListenerNoMouseCompat(type, handler, useCapture) {
  this.addEventListener(type, fuction(e) {
    if (!type.startswith("mouse") || !e.firedFrom("TouchEvent"))
      handler(e);
  }, useCapture);
};

5) Still it would be nice for apps to be able to opt-out from features
whose only benefit is legacy compatibility (where such decisions can be
made for an application as a whole).  We should be thinking about how the
long-term future web platform can be as rational as possible (Matt's
motivation I think).

I think Matt's goal is laudable, but in this case I don't see how we
achieve it without risking adding more harm than good.  Maybe this should
really be part of a larger discussions around patterns for the web platform
here in general?  IE has a compat-hack system for opting specific sites
into old behavior, but I don't think that's appropriate for major features
- in part because it doesn't scale since most of the power is centralized
with the browser implementer (vs. each web developer).   I believe both the
Windows and Android platforms have gotten a lot of benefit out using the
"target version" information embedded in an application to opt-out of
legacy compat behavior (i.e. once you show you've tested your app against a
particular platform version, the hacks necessary for compatibility with
older versions are disabled).  The web platform unfortunately doesn't have
a single linear version number that apps can target, but perhaps we could
be working towards something with the same benefit.  Eg. I can imagine a
mechanisms for apps to globally opt-out of specific legacy behaviors, and
then some group that standardizes common names for groups of legacy
behaviors (eg. maybe "html6" opts out of 100 agreed-upon legacy behaviors -
extending what's been done with doctype).  If we had a general pattern like
this to leverage, then I think the risk/benefit tradeoff would be very
different.  But clearly now we're talking well outside the scope of this CG.

I'm happy to help drive a broader discussion on this problem in some more
appropriate forum if folks are interested.  Thoughts?

So for now I think the most productive discussion is "in the long-run, do
>> we think you should be able to write responsive web apps that don't fire
>> these events, and if so what might an API to opt-out of them look like?".
>>
>
> Not sure what this has to do with responsive web apps. The compatibility
> events aren't' dispatched often and shouldn't cause any real world
> performance issues (you need to do hit testing for click anyway, and in the
> most common case you could just cache the hit testing result and use that
> for all the events).
>

 Sorry, by "responsive" I meant "sites that automatically adapt for
different form factors - i.e. phones vs. laptops".  If you're designing
your site from scratch to work well with both touch and mouse input, then
the compatibility mouse events provide no value to you.


On Sun, Jan 18, 2015 at 6:04 AM, Sangwhan Moon <smoon@opera.com> wrote:

> On Sun, Jan 18, 2015 at 6:58 PM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
>
>> On 18/01/2015 05:36, Sangwhan Moon wrote:
>>
>>  I'm with Olli on this one. Also, with some browsers implementing the
>>> changed model and some not (I can't see Safari or Presto changing at
>>> this point), I can't see how this would make life significantly easier
>>> for content authors.
>>>
>>
>> I admit that even I can only see a marginal advantage here, particularly
>> as to solve "double click handling" authors will still need the "this event
>> is a compat event / the result of a touch event" API discussed separately,
>> so they'll still need to modify their code regardless (at which point they
>> can add a "is this a derived event" check to their mouse* handler functions
>> too - unless we ARE saying that's a performance hit).
>>
>> Not trolling, but wondering: with regards to Presto, are there any
>> browsers on touch devices still using Presto? Old Android devices not
>> capable of upgrading to Chromium-based Opera? (I'm guessing older desktop
>> installations, as well as TVs and STBs, but these don't have touch events,
>> so would be unaffected by this proposed change)
>>
>
> While disclosing the number isn't possible for obvious reasons, I just
> checked and yes, there is a notable amount of active installations on
> Android as of today. I don't know much about the other platforms though.
>
> I'm even seeing quite a few people posting reviews today. (this is no
> secret, since the reviews are public)
>
> As for Safari, I'm working on the assumption that Apple - since they
>> steadfastly refuse to consider Pointer Events - have tacitly /
>> off-the-record agreed to try and make Touch Events environment more
>> powerful instead by implementing (or at least considering) these sorts of
>> changes...(or rather, that the chances are much greater for them to
>> implement an extension to TE rather than PE).
>>
>> 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
>>
>
>
>
> --
> Sangwhan Moon [Opera Software ASA]
> Software Engineer | Tokyo, Japan
>