Specify what browsers do on non-touch devices

[zcorpan]

See https://github.com/whatwg/dom/issues/227#issuecomment-211365756

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.

[RByers]

I propose we mark the APIs historically used for mobile device detection as deprecated:

• ontouch* members on window, document, Element
• document.createTouch, document.createTouchList (already deprecated)
• document.createEvent("TouchEvent") (not mentioned by the spec at all today)

They should be supported only by mobile devices for legacy web compat reasons. Sites wishing to do real cross-device TouchEvent feature detection should use if (window.TouchEvent). Chrome would then change to consistently expose these APIs only on mobile and not desktop, while otherwise fully supporting TouchEvents on all platforms in all situations (removing our error-prone hardware-detection-on-startup hack).

Thoughts?

[patrickhlauke]

with regards to the on* members...is this in line with other things like onmouseover, onclick etc? are these also marked as legacy (in whatever spec that would be)? or would this create some kind of exception?

[zcorpan]

onclick et al are not marked as legacy; they are defined in HTML.

https://html.spec.whatwg.org/multipage/webappapis.html#handler-onclick

It seems ontouchstart as a content attribute is not defined, and checker.html5.org gives an error for it. cc @sideshowbarker

[sideshowbarker]

It seems ontouchstart as a content attribute is not defined, and checker.html5.org gives an error for it

Yeah if no spec defines it as a content attribute, then it’s necessary for the checker to report it as an error.

I propose we mark the APIs historically used for mobile device detection as deprecated:

• ontouch* members on window, document, Element
• document.createTouch, document.createTouchList (already deprecated)
• document.createEvent("TouchEvent") (not mentioned by the spec at all today)

All sounds good to me. But however it’s done, it’s important we make clear in the spec what the status is of the ontouch* content attributes (not just the IDL attributes). If we clearly define the content attributes as obsolete, then I can have the checker emit a specific more-helpful error message for them.

But also to be clear: Note that the HTML spec doesn’t have a “deprecated” category for conformance; instead it only has “obsolete” and “obsolete but conforming”. In terms of the checker behavior, “obsolete” cases cause the checker to emit an error, while “obsolete but conforming” cause the checker to instead emit just a warning.

Anyway, I would be happy to write up a PR for the spec change around this all, once we have agreement on what we want to do here.

[patrickhlauke]

the various ontouchstart etc are defined here https://w3c.github.io/touch-events/#extensions-to-the-globaleventhandlers-interface - how would one also define content attributes, rather than just IDL attributes?

and to be clear, I assume we'd still want to keep the content attributes (so that authors CAN still do <button ontouchstart="something()">...</button> or whatever)? or is this suggesting that we just kill this off altogether?

[sideshowbarker]

the various ontouchstart etc are defined here https://w3c.github.io/touch-events/#extensions-to-the-globaleventhandlers-interface - how would one also define content attributes, rather than just IDL attributes?

If they are attributes allowed on any HTML, element, then they would be defined by adding them to the list of attributes here:

https://html.spec.whatwg.org/multipage/dom.html#global-attributes:event-handler-content-attributes

If they’re instead allowed only on specific elements, then we would need to update the per-element sections of the HTML spec to add them; for example, see here:

https://html.spec.whatwg.org/multipage/sections.html#the-body-element:concept-element-attributes

But if we want to define them as obsolete, then we’d need to instead add them to one of these:

• https://html.spec.whatwg.org/multipage/obsolete.html#non-conforming-features
• https://html.spec.whatwg.org/multipage/obsolete.html#obsolete-but-conforming-features

[mustaqahmed]

@eirage is working to change Chrome to expose these APIs on mobile only, as Rick mentioned above.

[RByers]

@staktrace what do you think of the proposal in https://github.com/w3c/touch-events/issues/64#issuecomment-327671775 as a better way to balance the compat / functionality concerns on non-mobile touchscreen devices? If we can prove that the compat tradeoff is reasonable by shipping this in Chrome, do you think Firefox would be interested in doing the same thing (to address the compat issues you mentioned).

@patrickkettner, any thoughts for Edge? Given you guys don't enable touch events on desktop at all at the moment, if we can show that this limited form of enabling is web compatible (enabling without the discouraged feature detection APIs doesn't break any sites which that work when fully disabled) might you be interested?

[staktrace]

@RByers Personally I'm not a huge fan of removing some of the APIs and leaving others, but I don't feel too strongly about it. It'll make the touch API even more inconsistent and we're going to have to live with that inconsistency for a long time. Do we have data on how many sites are still assuming touch == mobile, and whether that has declined over time?

That being said @smaug---- and @mingchou I believe were both ok with this change and I'll defer to them on this matter. We have bug 1412485 on file for the API removal.

[annevk]

I ran into this again, is there a primitive defined that essentially means "mobile" that DOM could branch on for createEvent()?

cc @domenic

[patrickhlauke]

the problem is "define what 'mobile' means" which is generally a question that belies further sweeping assumptions (small screen, no keyboard/mouse only touch, slow connection).

is it perhaps not sufficient to add a non-normative note that leaves it up to user agents whether they expose the API or not, and for authors to feature-detect rather than rely on its presence (and to have a good hard think first about why they're trying to determine this and if really they should be checking the thing that they're making assumption on - viewport size etc - rather than using "touch" as a proxy)?

(unless i'm misunderstanding the question)

[annevk]

I think it's fine to have something like

User agents have an associated boolean mobile, whose value is implementation-defined.

and then use that concept to conditionally expose various things. And maybe clarify in a note what it means in practice. (Not sure if we want to go all the way to IDL support, but maybe...)

[patrickhlauke]

that sounds to me like a weirdly bad take. just feeds into the odd "mobile / not mobile" distinction which has always been blurred anyway (is a tablet "mobile"? up to which size? is a surface when in tablet mode a "mobile"?)

especially if this is going to be something new, why not instead educate authors that no, there is no such thing as "mobile". ask yourself what you're actually trying to determine, and then test for that instead.

[patrickhlauke]

if it's a genuine "does this device really have a touchscreen" question, then checking window.navigator.maxTouchPoints>0 should do it, no?

[annevk]

I mean, how would you suggest we underpin the notion that document.createEvent("TouchEvent") sometimes throws? That requires some kind of primitive, no? (If it's always the same as window.navigator.maxTouchPoints maybe that is the primitive. Is that the case?)

[patrickhlauke]

is this a primitive exposed to JS authors, or are we talking something that'd be browser-internal? like essentially a "has touch screen" kind of flag?

[annevk]

It's exposed through various APIs, such as the one I listed, but not directly no. Again, it's a way to address this issue...

[patrickhlauke]

...which, now that i'm remembering the original point of this discussion, wouldn't help (and neither does window.navigator.maxTouchPoints), because then THAT would be truthful, whereas the point here was to lie to prevent the whole naive assumptions that developers had cargo-culted onto the presence of touch events in the first place.

so, if it's something internal, maybe be quite upfront and call it "fullyExposeTouchEvents" or something (with explanation, wherever that's defined, that this is to prevent those naive feature checks)

[annevk]

If user agents only use it for that, that seems reasonable.

[patrickhlauke]

so, pardon my naiveté ... where and how would this be spec'd? in touch events? elsewhere?

[annevk]

Touch events seems fine to me, but we could also put it in HTML if it affects more than touch events.

@smaug---- do you know?

[smaug----]

This sounds more like TouchEvents specific. In Gecko the pref which controls some of the exposed parts is called dom.w3c_touch_events.legacy_apis.enabled I wonder if the spec could use some the same naming, at least that 'legacy' and explain that it is supposed to be used on mobile only.

And at least in Gecko this is very unusual stuff and I think only Touch Events have anything like it.

WebIDL side is https://searchfox.org/mozilla-central/search?q=nsGenericHTMLElement%3A%3ALegacyTouchAPIEnabled&path= createEvent has https://searchfox.org/mozilla-central/rev/de782976bf97669f1e8edee59e7a2398154efe06/dom/events/EventDispatcher.cpp#1312

[patrickhlauke]

any initial suggestion/draft PR to show how this sort of thing would be specified in Touch Events spec would be welcome - happy to then tweak/refine the words, but - not being super familiar with the more technical points, and what shape they'd need to take in a spec - would apprecitate an initial skeleton of this. @smaug---- would you have the time/inclination to do this? or point me in the direction of something similar in another spec?

[annevk]

Something like:

A <a>user agent</a> has an associated boolean <dfn export for="user agent">legacy tough events</dfn> whose value is <a>implementation-defined</a>.

And then elsewhere we could branch on that. Does that help?

[zcorpan]

I propose we mark the APIs historically used for mobile device detection as deprecated:

• ontouch* members on window, document, Element
• document.createTouch, document.createTouchList (already deprecated)
• document.createEvent("TouchEvent") (not mentioned by the spec at all today)

The document.createTouch and document.createTouchList APIs are not supported in browsers (anymore?).

The other two bullet points is the complete list of features in Chromium that depend on the "legacy touch events" concept (RuntimeEnabledFeatures::TouchEventFeatureDetectionEnabled in Chromium), as far as I can tell. The list of event handlers is: ontouchcancel, ontouchend, ontouchmove, ontouchstart.

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/document.cc;l=5448 https://source.chromium.org/chromium/chromium/src/+/main:out/Debug/gen/third_party/blink/renderer/bindings/modules/v8/v8_document.cc;l=9830 (+similar for window and elements)

[zcorpan]

PRs: ​​https://github.com/w3c/touch-events/pull/111 and https://github.com/whatwg/dom/pull/1071