replace mobile detection from screen size to physical ability

[Alexufo]

Due my issue #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

[gingerchew]

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!

[Voileexperiments]

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.

[Alexufo]

@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.

[Voileexperiments]

@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.

[Alexufo]

@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?

[gingerchew]

@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?