[mediaqueries] Consider exposing "mobileness" as a media query

[zcorpan]

See whatwg/html#8224 (comment)

Mobileness is exposed in navigator.userAgentData.mobile: https://wicg.github.io/ua-client-hints/#getters

Right, but that's not exposed as a media query, right? Perhaps the best solution would be to expose mobileness in a media query? I'm sure there's some context for why that's not already there, but I don't know what it is.

Has this been considered?

The definition in the Client Hints spec seems a bit vague to me, but I believe most browsers have an internal mobileness concept which affects rendering of some things, in particular <select> and <select multiple>.

Maybe browsers should do something else like key off of viewport size and pointer MQ?

cc @mfreed7

[frivoal]

Not terribly clear to me what this query is supposed to mean. There are quite a few characteristics typically associated with mobile devices already exposed through media queries. Presumably the request for one more means that what we have now is insufficient… but insufficient in what way?

[zcorpan]

I'm not sure they're insufficient. It seems browsers already have somewhat different rendering for select between mobile and tablet, where the difference I think is mostly viewport size:
whatwg/html#8224 (comment)

Still, the mobileness concept exists in implementations and in the CH spec. I can imagine a few possible scenarios:

• Browsers remove most of the mobileness concept and instead use existing MQs (maybe viewport size + pointer) for default rendering differences between mobile/tablet/desktop. We remove navigator.userAgentData.mobile. We'll still be stuck with a "mobile" signal in the UA string for web compat.
• We add a MQ for "mobileness" as defined in CH, and browsers use it (maybe in combination with viewport size MQ) for default rendering differences between mobile/tablet/desktop. We keep navigator.userAgentData.mobile.
• We keep the status quo.

[tabatkins]

We already had "mobile-ness" in the (now deprecated) media types. Media types had their own specific issues, but for detecting mobile devices specifically, the type just wasn't very coherent. There's no firm boundary between a phone and a tablet, or a tablet and a laptop (particularly those that can fold the screen back to switch into a tablet-like mode).

Between size and pointer we capture most of the differences; anything missing which has a demonstrated use-case we're more than willing to entertain adding a new MQ for.

[Crissov]

What’s a mobile device anyway? Is it the same as a moving or movable device?

• Is a laptop mobile, if you only ever use it on your desk?
• Does it become mobile when you are using it while riding a train at 300 km/h or on board a plane at 800 km/h?
• Is a car entertainment system or ”GPS“ navigation system mobile when used by the driver at 50 or 100 km/h?
• Does this change while standing in a parking lot?
• Is it different for the screens for passengers sitting in the backseats?
• Is a phone’s mobileness different for when you are sitting at a bench or walking down a street at 5 km/h?
• Does a tablet become less mobile when its smart cover is folded as a stand or when a physical keyboard gets attached to it?

For several of those scenarios, user distraction and focus are relevant factors while designing user interfaces. They are different from whether direct interaction with a touchscreen is possible. They are also different from how big the screen is or what is its orientation and how far away it is from the user’s eyes. Several mobile devices do not even have a screen, but are audio-only (and hardly any of them consider CSS).

[domenic]

I think people are getting a bit lost in the theorizing here...

The fact of the matter is, browsers expose a single mobileness bit in their user agent string. People use this to build websites in various ways, including e.g. server rendering. @zcorpan suggests that maybe browsers also control some other things with this single bit. (Which I know to be true in some areas, although I don't know for sure about the cases he mentions, like select menu.)

Maybe they shouldn't use this bit to style websites! In which case the CSSWG can decide not to expose it as a media query. Then people who really want it will just server-render <html data-mobile="${isUserAgentStringMobile()}"> and use :root[data-mobile="true"] { ... } instead of the media query.

But maybe such styling is a legitimate use case, and should be supported with a first-class media query! If user agents themselves use it for e.g. <select> styling, as @zcorpan suspects, then that's a strong hint that it might be legitimate after all.

To recap, we're talking specifically about the existing mobileness bit that user agents definitely have and already expose through other means. We're not talking about relitigating the definition of mobileness.

[zcorpan]

Thanks @domenic

@mfreed7 can you confirm whether <select> styling depends on this bit in chromium?

[Crissov]

Maybe they shouldn't use this bit to style websites! In which case the CSSWG can decide not to expose it as a media query.

That would be exactly my point. The current idea of mobileness is severely flawed and should not be exposed as a MQ verbatim.

[tabatkins]

Right, we deprecated the media type and didn't reproduce it in a MQ (instead reproducing the axises of variation people actually want to respond to) precisely because it's an incoherent concept and never what you actually want. There are many axises of variation you can possibly care about (screen size, existence of a pointer or hover capability, etc) and while there is a meaningful clustering of those values into something we call "phones", there's more than enough overlap in device capabilities that addressing that cluster is usually doing your users a disservice. Small screen layouts are usually desirable when a desktop user has a narrow window at the side of the screen, hover-less layouts are useful when webpages are displayed on TVs despite having desktop-ish sizes, etc.

If browsers have more differences than what are currently covered by appropriate MQs, and there's a reasonable use-case for exposing those differences to authors, we can add MQs to cover them. But I don't think the logic behind deprecating the media type is invalid.

[mfreed7]

Thanks @domenic

@mfreed7 can you confirm whether <select> styling depends on this bit in chromium?

In Chromium, the <select> changes behavior based on #ifdef ANDROID type C++ code, which in practice should map fairly closely to the mobileness bit.

The reason I raised this issue is that for the new <selectmenu> element, we need to standardize the styling via CSS, including what happens on small screens. We would like behavior similar to <select> that gives the user a more "full screen" view when their screen size is small. It seemed natural to re-use the mobileness bit, since that's how it's done in practice for <select>. Without that, we'll have to have a standardized UA stylesheet that looks like this:

@media screen and (max-width: 500px) {
   ... styling for "full screen" select ...
}

I anticipate endless haggling over 500px or 499px or 501px or 682px. Having said that, and given that the desire is to switch to a "small screen friendly" layout when "the screen is too small", using actual screen size does make sense. I was just hoping to side-step the bikeshedding over the pixel value. I see the points above that mobileness is kind of funny.

[zcorpan]

If possible, I think the mechanism we decide for <selectmenu> should be used for <select> also. The latter is also stylable (less so, but still). Using mobileness bit to decide for <select> and a viewport-size MQ for <selectmenu> seems unexpected to me.

I don't mind switching to a MQ instead of using mobileness, if that's deemed better and is sufficiently web compatible for <select>.