- 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