Specify what browsers do on non-touch devices

[zcorpan]

See whatwg/dom#227 (comment)

It appears that all browsers essentially disable support for touch events on non-touch devices. I suggest the spec should reflect this reality and say what the expected behavior should be in that setup.

[patrickhlauke]

This behavior is more of a workaround to circumvent badly coded sites that make the naive "if touch events, it must be a mobile/touch-only device, so we only bind to touch events and not to mouse or click" approach that seems to be so pervasive.

In fact, some desktop browsers on laptops/computers with touchscreen don't expose touch events at all in some cases, as too many sites then also assume touch-only and break mouse/trackpad/keyboard interaction.

Not sure if codifying this user agent heuristic/self-defence mechanism in the spec itself would help solve the fundamental problem of sites having crappy code, or if codifying it would make sites even more justified in their approach (which would still fail in the desktop scenario).

Maybe adding an informative (non-normative) note could be useful nonetheless? /cc @RByers

[zcorpan]

I think having the spec pretending that the problem doesn't exist doesn't help at all in moving towards a solution for it. I would love to live in a world where all browsers supported touch events and no Web site makes assumptions around the size of the screen depending on the presence of touch events, but that's not the world we're living in today. Not specifying this and hoping it will go away is like not specifying the navigator object because people use it for browser sniffing and we think browsing sniffing should die... I think it's the wrong way to go about it. We should specify reality even if we don't like it, imo. :-)

[patrickhlauke]

Sure, i'm guessing it's the difference between adding a non-normative note in the spec (i.e. "current browsers do this"), vs having the spec mandate this behavior as part of the normative spec text itself (i.e. "browsers HAVE to do it this way").

[scottgonzalez]

What do browsers do with other events that are conditional on hardware? For example, deviceproximity from Proximity or levelchange from Battery Status which the user agent may know about but the hardware doesn't support?

[patrickhlauke]

For proximity, the spec says

Not all devices contain a proximity sensor, and when there is no proximity sensor, this API is still exposed to the scripting environment but it does nothing.

Testing this in Firefox on my Surface 3 (which, as far as I know, doesn't have the relevant sensor) using https://www.audero.it/demo/proximity-api-demo.html the API is indeed exposed, but returns no meaningful data when queried.

[patrickhlauke]

Touch Events may be "special" in that they've historically been abused by developers as a shorthand for "it's a mobile device" (same way that small screen sizes are often abused in media queries as a similar shorthand).

[RByers]

Yeah touch events are very strange in this regard because historically the API was available only on mobile browsers and so mere feature detection served as a proxy for detecting mobile devices. Given that we're not likely to be able to fix this anytime soon, I support adding something to spec (normative or otherwise, not sure it matters).

[zcorpan]

If it's normative and non-ambiguous then it's testable (e.g. can test that the entire feature set is disabled in the right way) and new implementations (e.g. servo) don't need to reverse engineer other browsers to get web compat.

Disabling support for something can be done in several ways, and if the feature interacts with other features then it becomes unclear what should happen if the spec only has a vauge note about this issue.

As an example, I just fixed the dom spec to throw NotSupportedError for createEvent (instead of TypeError which it happened to require before without considering that TouchEvent could be undefined). This could use a spec hook from the touch events spec to make it clearer.

[patrickhlauke]

Sorry, revisiting this quite a few months later...I'm still leaning more towards a non-normative note, clearly explaining what current browsers do (not expose the API on non-touchscreen devices) and why (for compatibility reasons / to stop sites from breaking). Browsers are free not to follow this behavior from the non-normative note, but then it's up to them to worry about site compat.

[patrickhlauke]

Bumping once more in light of Firefox's current decision to enable TE on non-touch devices (see https://twitter.com/FxSiteCompat/status/808779763804471296 and https://www.fxsitecompat.com/en-CA/docs/2016/touch-event-support-has-been-re-enabled-on-windows-desktop/). @RByers is it worth drafting out both an informative note ("traditionally browsers only exposed TE on actual touch devices") as well as a more specific guidance on what a UA should do in terms of disabling TE cleanly if the UA so chooses (i.e. whether the whole API should simply not be there, of it the API should be there but throw a specific type of error if an authors tries to use it, etc)?

[staktrace]

Bumping once more in light of Firefox's current decision to enable TE on non-touch devices

Not sure if I'm misinterpreting what you're saying, but Firefox is enabling TE only on devices that support touch. That is, TE will disabled on OS X, and enabled on Windows/Linux if and only if the hardware supports it. (It can also be enabled via the Firefox devtools, but that's a special case.) In the cases that the hardware doesn't support touch, we won't expose the API at all (i.e. window.TouchEvent and friends will not exist).

[staktrace]

Also for the record, we've run into a couple of cases where websites assume touch support == mobile (and therefore don't register mouse listeners when they need to) but so far the incidence of this is low enough that we aren't too concerned. Our evangelism team is reaching out to sites on a case-by-case basis and encouraging them to fix their sites so they don't assume touch == mobile.

[patrickhlauke]

@staktrace oh my bad, i completely misinterpreted the Firefox announcement (serves me right for skim-reading it).

[teddink]

@staktrace I will be very interested to know if you run into interop issues when this is enabled on desktop OS devices with touch. Microsoft Edge (and IE, for that matter) still had touch events turned off for desktop primarily because we saw too many interop issues of that type where sites assumed touch == mobile. Hopefully the ecosystem has improved in that regard now enough that the interop issues will be low. If the interop issues have reduced, we could consider turning on touch events on Edge desktop as well, but in the end we would rather developers use pointer events.