Quickfire gut reaction (beyond "dammit, do you want to remove all interesting topics from my presentation/workshop?")
On 16/01/2015 15:51, Rick Byers wrote:
I believe lots of websites still rely on these events for compat,
Which I believe is their entire "raison d'etre"...I'm sure it was a pragmatic solution taken by Apple at the time.
but we
should start thinking about how we could phase them out. Eg. maybe we
should define an API to enable/disable them and work towards making
disabling the default - at least in modern scenarios?
Two issues:
- the events are there for compat with "legacy" content...which is usually unlikely to be updated now. So default should be to have the compat events still enabled by default, no?
- how do you programmatically define/recognise (with heuristics) a "modern scenario"? I'd be weary of automagic behavior here. Also, there may be scenarios where even modern (recently built) sites somehow make use of mouse compat events (don't ask me why...) somehow (even if just to simplify their handling of stuff, e.g. setting a flag on touch* event, but leaving the actual functionality to happen on mouse* event).
Perhaps looking on load if any mouse listeners have been registered may be an initial approach (though it would fall foul of any listeners that are dynamically added at a later date).
We could pretty
easily get some experience with this now - eg. a flag in chromium which
disables the mouse* events on tap for sites we identify as not needing
"desktop workarounds" (i.e. based on the viewport)? Matt, would doing
something like this address your concern?
input-dev, WDYT - should we try to do some implementation
experimentation in chromium here? TECG, do you think this is a problem
worth tackling / potentially designing an API for?
Rick
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
Do you dispatch mouse events for websites that do not register any mouse event listener (are there such websites? I mean, ones that only register touch events)?By "dispatch", I mean, exercise the overhead and code path for hit testing.
Can we just have document.disableCompatibilityMouseEvents = true; for "very, very, very" expirienced developer which know what thay do? I mean if developer plan to use touchevents and knows that compatibility events will mess his/her work, why developer cannot just disable them at all by him/herself?
--
On Fri, Jan 16, 2015 at 11:21 AM, Arthur Stolyar <nekr....@gmail.com> wrote:Can we just have document.disableCompatibilityMouseEvents = true; for "very, very, very" expirienced developer which know what thay do? I mean if developer plan to use touchevents and knows that compatibility events will mess his/her work, why developer cannot just disable them at all by him/herself?Yep, that's one possible API shape. I hope that it's not just for "very" experienced developers though. I'd like to believe that the easy-to-use frameworks of the future would do this by default so that even the least experienced developers just never need to think about it.I'm not sure an API on document is the best pattern though - it implies that the decision can be made for the page as a whole, when often a page is built out of components with different expectations/assumptions. Maybe it should be a CSS property instead? Or maybe it should be a preventMouseEvents() method on TouchEvent?--
I am actually not sure this proposal is even the right way forward, really.There should not be touch only websites and without the compatibility mouse events, or Pointer Events, you must implement event registration for every input. I think the way forward is to avoid that.
These compatibility events can be considered as the 'legacy Pointer Events'. You can rely on them instead of registering events for every pointer inputs.
While these can be a problem when you do implement event registration for every pointer input, this is (unfortunately? fortunately? I am not sure) atypical.
The short term way of improving this would be to add a property on compatibility mouse events that regards them as simulated and the long term of improving this would be Pointer Events.
I think adding this developer toggler would be bad for two reasons -- It encourages touch (or specific input) only implementations (you get better performance if you disable compatibility mouse events and your primary audience is smartphones with touch screens, so this is enough. The hell with the rest).
- It can interfere with third party scripts you may add (even analytical ones), or any code that you do not control.
Most websites do not explicitly need touch events, but only mouse events (with the compatibility mouse events). So in the same vein, perhaps document.disableTouchEvents should be added.
Hi PhistucK,2015-01-16 18:46 GMT+02:00 PhistucK <phis...@gmail.com>:These compatibility events can be considered as the 'legacy Pointer Events'. You can rely on them instead of registering events for every pointer inputs.While these can be a problem when you do implement event registration for every pointer input, this is (unfortunately? fortunately? I am not sure) atypical.The short term way of improving this would be to add a property on compatibility mouse events that regards them as simulated and the long term of improving this would be Pointer Events.Pointer Events are good, but we do not talk here about them.I think adding this developer toggler would be bad for two reasons -- It encourages touch (or specific input) only implementations (you get better performance if you disable compatibility mouse events and your primary audience is smartphones with touch screens, so this is enough. The hell with the rest).This is possible aready by only using touchevents and do not using mouse events. Touch events does not has backcompatibility already, so if you will add right now only touch events, then desktop sites with mouse will not work anyway.
- It can interfere with third party scripts you may add (even analytical ones), or any code that you do not control.Yes. This is why this choise whould be on developer side, not on browser side. So developer can disable compatibility events or not. This is only optimization and not one should/might use it.
On 16/01/2015 16:57, PhistucK wrote:
Most websites do not explicitly need touch events, but only mouse events
(with the compatibility mouse events). So in the same vein, perhaps
document.disableTouchEvents should be added.
And why exactly? If your site does not register touch event handlers, then it makes no difference/does not need to be suppressed.
Touch events contain much more data and granularity than mouse events. If you disable them, perhaps the logic or memory used for obtaining and storing that data can be suppressed and the memory usage or performance may improve.
MouseEvent.prototype.simulated = true should be sufficient for this problem.
☆Phistu
On 16/01/2015 16:14, Rick Byers wrote:
On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke
<re...@splintered.co.uk <mailto:re...@splintered.co.uk>> wrote:
Quickfire gut reaction (beyond "dammit, do you want to remove all
interesting topics from my presentation/workshop?")
Heh heh - I guess it's kinda the point of the TECG to make input
handling so easy/obvious that it puts you out of a job <grin>.
The contortions you guys go through just so you can stick with your "no, Pointer Events have problems" ("no we won't admit it's purely because of Apple's reluctance") attitude is admirable nonetheless ;)
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"?
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);
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)
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
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).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?".