-
-
Notifications
You must be signed in to change notification settings - Fork 18
IE11 on touchscreen laptop gives arguably false negative #2
Comments
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 Since, in a touch-conscious ecosystem, it seems like 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 |
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. |
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. |
👍 (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 ) |
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
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 |
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?
The text was updated successfully, but these errors were encountered: