- From: Olli Pettay <olli@pettay.fi>
- Date: Thu, 22 Dec 2016 11:54:24 +0200
- To: Rick Byers <rbyers@chromium.org>, "public-touchevents@w3.org" <public-touchevents@w3.org>
- Cc: Dave Tapuska <dtapuska@chromium.org>, sunyunjia@chromium.org, Kartikaya Gupta <kats@mozilla.com>, Philip Jägenstedt <foolip@chromium.org>
On 12/22/2016 04:16 AM, Rick Byers wrote: > Hey, > One of the big problems with TouchEvents has been that some websites still assume that support for the TouchEvent API implies a mobile device without > any mouse support (and so clicking with a mouse will not work). > > Chrome has long had a hack to partially work around this where we enable touch support (including the TouchEvent API) only when we detect the presence > of a touchscreen on startup. With our work on pointer events and trying to address complaints of customers who plug in a touchscreen after startup, > we've recently overhauled that logic <https://bugs.chromium.org/p/chromium/issues/detail?id=644318>. The principle now is that we're applying the > hack JUST to the legacy APIs used primarily for feature detection [1]. Sites that follow the guidance > <https://hacks.mozilla.org/2013/04/detecting-touch-its-the-why-not-the-how/> of always listening to both TouchEvents and MouseEvents using modern > addEventListener style instead of the DOM0 'on' attributes will now work reliably without being impacted by the web compat hack here. Sites that > condition to special-case "'ontouchstart' in window" will continue to behave as before. > > IMHO this is a good compromise between platform rationality and the web compat issues and I'm pretty disappointed I didn't think to try this years ago > ;-). If this works then rather than rely on the (often buggy and unhelpful) touchscreen detection, I'd probably attempt to simplify this > <https://bugs.chromium.org/p/chromium/issues/detail?id=392584> by having the legacy feature detection APIs consistently disabled on desktop and > enabled on mobile (while still being overridable from chrome://flags for special cases). > > If this sticks, I'd like to encourage other browsers with desktop implementations to give it a try and get it formalized as expected behavior in the > spec. Thoughts? > > Rick > > [1] For completeness the set of APIs that are hidden in Chrome when there is no touchscreen are > <https://cs.chromium.org/search/?q=%22RuntimeEnabled%3DTouchEventFeatureDetection%22&sq=package:chromium&type=cs>: > on GlobalEventHandlers (window, Document, HTMLElement, SVGElement): > ontouchstart, ontouchmove, ontouchend, ontouchcancel > Document.createTouch > Document.createTouchList > document.createEvent("TouchEvent") (throws) > So event handlers are hidden but can one still set them? Or how does this actually work? Are event handlers just not there at all and Document.create* either when touchscreen isn't detected initially? What about interface objects? Are they visible in the global scope? `if ("TouchEvent" in window)` is one way to detect the feature (IMO the right one even), though not sure how often that is used. -Olli
Received on Thursday, 22 December 2016 09:54:55 UTC