IE11 on touchscreen laptop gives arguably false negative

[patrickhlauke]

This is arguably a tricky situation, as even with the real MQ4 feature this is a grey area (though I seem to remember discussions about dynamically matching this depending on what the user actually uses): on a touchscreen Win8 laptop, maxTouchPoints is usually around 10, so it will identify this as a device that does not support non-emulated hover. However, the user can obviously be using the trackpad or attached mouse. It's more of a philosophical issue of: if the device can be seen as having two equally primary input modes (touchscreen AND trackpad/mouse), which one should match?

[cvrebert]

It's ultimately something that UAs should decide using their greater knowledge, since MQ4 currently implies that they'll have to choose only 1 UA-wide primary pointer at a time for the purposes of the hover and pointer media features (whereas the Pointer Events spec defines a primary pointer per each pointer type). But we're acting as the UA in this case, so...

Since, in a touch-conscious ecosystem, it seems like :hover should only be used for progressive enhancement (and the primary purpose of this shim is for toggling :hover styles), I think it's reasonable to err on the side of "does not support true hover" in the "multiple 'primary' pointing devices" case. In general, this project deems :hover stickiness to be sinful and wants to err on the side of avoiding it, which is why e.g. we default to "does not support true hovering" when JavaScript is disabled. In the MS Surface case, the user could decide to switch to the touchscreen at any moment and AFAIK (would love to be proven wrong) there is currently no viable way to detect that switch. There's no explicit or implicit "primary pointer changed" event in any spec that we could listen for.

Aside: It would be nice for the shim to be more dynamic, at least for forward compatibility. I suppose it would be better to, if the hover media feature is natively supported, listen for changes in that media query via MediaQueryList.addListener. Then the browser could of course dynamically toggle it according to whatever heuristic it likes.

[patrickhlauke]

There's no explicit or implicit "primary pointer changed" event in any spec that we could listen for.

indeed...mainly because win8 considers these inputs equipotent, rather than trying to classify them as primary, secondary, etc. but, as i said, this is more an issue with the entire MQ4 hover approach than with your specific shim.

[cvrebert]

Well, creating a UI operable by multiple significantly different input mechanisms simultaneously sounds difficult at best, so the equipotentcy approach has its own issues, but anyway...

I'm gonna classify this as "working as intended" but that it warrants being documented.

[patrickhlauke]

👍 (also note this may become more of an issue as more hybrid touch AND mouse devices come along...sorry, but it's one of my primary interests/bugbears https://patrickhlauke.github.io/getting-touchy-presentation )

[cvrebert]

Slide №96's image is upside-down?

[cvrebert]

Also, cool beans: https://developer.mozilla.org/en-US/docs/Web/Events/click$revision/715347

[patrickhlauke]

Slide №96's image is upside-down?

yes, it was a visual "sigh" at the fact that Safari does not even suppress 300ms in the brute force user-scalable=no example.

Also, cool beans: https://developer.mozilla.org/en-US/docs/Web/Events/click$revision/715347

btw, note that Apple's documentation about "clickable elements" and "making elements clickable" is incorrect, so that should also be changed on MDN - using the exact example that Apple have in their documentation, claiming that it needs at least an empty onclick, actually works just fine without anything else - see example https://patrickhlauke.github.io/touch/ios-clickable/ and slide 166 http://patrickhlauke.github.io/getting-touchy-presentation/?full#166 (but yes, for the event delegation part, the info at moz is now correct)