Open Alexufo opened 3 years ago
This is an interesting idea, on top of being able to use CSS, there is also matchMedia
which has event listeners for changes in capabilities.
Unfortunately, checking for hover: hover
using @media
can be tricky and isn't as specific as we think. I'm speaking from personal experience rewriting a website to meet AAA accessibility standards.
Thankfully, there are the properties any-pointer
and any-hover
. CSS-tricks did a more in depth write up here
I'll include most of the take away code snippets.
@media (any-pointer: coarse) {
/* at least one of the pointer inputs
is coarse, best to make buttons and
other "touch targets" bigger (using
the query "defensively" to target
the least capable input) */
}
@media (any-hover: hover) {
/* at least one of the inputs is
hover-capable, so it's at least
possible for users to trigger
hover-based menus */
}
Or you can use the and
operator inside of a @media
and look for more specific support:
@media (pointer: coarse) and (any-pointer: fine) {
/* the primary input is a touchscreen, but
there is also a fine input (a mouse or
perhaps stylus) present. Make the design
touch-first, mouse/stylus users can
still use this just fine (though it may
feel a big clunky for them?) */
}
@media (pointer: fine) and (any-pointer: coarse) {
/* the primary input is a mouse/stylus,
but there is also a touchscreen
present. May be safest to make
controls big, just in case users do
actually use the touchscreen? */
}
@media (hover: none) and (any-hover: hover) {
/* the primary input can't hover, but
the user has at least one other
input available that would let them
hover. Do you trust that the primary
input is in fact what the user is
more likely to use, and omit hover-
based interactions? Or treat hover
as something optional — can be
used (e.g. to provide shortcuts) to
users that do use the mouse, but
don't rely on it? */
}
Any of these can also be checked for using the matchMedia
API I referenced earlier.
This is much more to consider than just @media (hover: hover)
. I do agree, using CSS instead of JavaScript is a win win. Since GLightbox is in the process of updating to v4, I'll have to bring it up with the maintainer 😊
Thank you for bringing this up!
This is a MASSIVE issue because the window width threshold used for mobile detection would treat iPad Pro as desktop, making various touch-related interactions unusable on iPad Pro. Hence it's not even working as intended.
@Voileexperiments I disagree. iPad Pro as desktop and any other devices hybrid devices must think about his API for browsers by themselves. Like they did compatibility for all websites for 4k screens. I suppose, they will provide touch physical event in @media as priority even you will duplicate stream (or moving browser to second screen ) to tv screen or projector or any second screen
Any way, browsers moving to provide detection of physical ability of screens in css. Detection of touch events by screen width is dead end.
@Alexufo I don't think the most common use for iPad Pro is to use it as a hybrid device (it's not even the default use case), so my point was still valid.
It doesn't matter anyway, since the fact still stands that the photo view becomes unusable in iPad Pro, and my point is that this issue affects more use cases than it seems.
@Voileexperiments I never seen ipad pro but It is touch device. Touch events will be detected with css. Why you think detection touch events of window width better?
@Voileexperiments Correct me if I'm wrong, but it sounds like the issue you are bringing up here is that detecting a "touch-enabled" device based on the window.width
of the device using a fixed threshold of x
will cause issues on iPad Pro.
Since iPad Pro's window.width
is larger, both portrait and landscape, than x
, GLightbox does not view iPad Pro devices as "touch-enabled".
However, if a device's window.width
is larger than x
, it will "turn off" swiping and instead reveal buttons as it would on a desktop device. Those buttons will work on all devices, touch, mouse, pen, keyboard, whatever.
Are you having an issue where GLightbox flat out doesn't work on an iPad Pro, even the buttons I just mentioned?
Due my issue https://github.com/biati-digital/glightbox/issues/188 I suppose to replace mobile detection from window width to touch physicals ability. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/hover
I think it will be cool and lighter for browsers