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

[zcorpan]

See https://github.com/whatwg/html/issues/8224#issuecomment-1235722036

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: https://github.com/whatwg/html/issues/8224#issuecomment-1236952646

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

[mfreed7]

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

The trouble with that is that the "native" picker for <select> is typically only available on the "mobile" platforms. So I'm not sure what would/should happen if we're on a device where !mobile but width < max-width. Perhaps there isn't such a platform, but it seems like an odd corner case that we'd be opening up.

The difference for <selectmenu> is that, at least by default, we weren't thinking about exposing the native picker for small screens. Perhaps there would be a CSS property that allowed the developer (or UA, if it needs to) to force the native picker, but not by default, and not triggered by the media query we're discussing.

[zcorpan]

The trouble with that is that the "native" picker for <select> is typically only available on the "mobile" platforms. So I'm not sure what would/should happen if we're on a device where !mobile but width < max-width. Perhaps there isn't such a platform, but it seems like an odd corner case that we'd be opening up.

This can happen on desktop by shrinking the window, or even using an iframe element.

[mfreed7]

In working on this further for <selectlist> (it got renamed), it occured to me that what we really want is a @media query that means "this is a small screen", without having to haggle on an exact value for what "small" means. For example, we'd like a <selectlist> to present a different interface when on a "phone" sized screen: larger tap targets, more padding, take over more of the screen with the menu. Much like native <select> pickers do today on iOS and Android. The media query that currently encapsulates that is something like:

@media (pointer: coarse) and (max-width: 10cm) {

The pointer:coarse is important because you need larger touch targets when using a coarse pointer like a finger. The max-width:10cm is important because on such a small screen, the users needs to have things de-cluttered to focus on the picker. On a larger screen such as a tablet, it isn't appropriate to take over the entire screen, since the user has a lot of real estate to work with.

The above CSS is functional and achieves the use case. However, max-width: 10cm isn't great. Why 10cm? Why not 8 or 12? There's no exact breakpoint that can be identified to define the difference between "small screen" and "large screen".

What would be great is something like:

@media (pointer: coarse) and (screen-size: medium) {

I said screen-size: medium because I want to leave room for ultra-small screens like watch faces, which could be screen-size: small. These need better names, but I think it's a feature, and not a bug, that they're not strictly defined. It'll be up to the UA, and changing technology, to define what screen sizes count as large vs. medium vs. small. But that frees developers from having to worry about exact values, and avoids the standards debate about a standardized value being memorialized in the spec.

Is that something the CSSWG would be interested in thinking about?

[Loirooriol]

What if only one dimension of the screen is small, but the other is big?

Also, I'm not convinced by the argument for not defining them. What will happen is that authors will rely on whatever Blink chooses, and Blink will be locked into that initial choice to avoid breaking sites.

[mfreed7]

What if only one dimension of the screen is small, but the other is big?

Yeah, that's a good question. Mostly people use the width as a proxy, but again here, this might be a great reason to let the UA define it? That device doesn't exist (or isn't common today) so it's impossible to get it 100% right without knowing how it's used. The alternative of hard-coding a specific width seems worse in this case, doesn't it?

Also, I'm not convinced by the argument for not defining them. What will happen is that authors will rely on whatever Blink chooses, and Blink will be locked into that initial choice to avoid breaking sites.

I agree that would be a bad outcome. How do you propose we define it to avoid this problem? My hope was that by not defining it in terms of pixels, developers would use it more for the qualitative breakpoints, such as "more padding", or "add a backdrop". Perhaps browser devtools can randomize the breakpoint, so developers can't count on a width while developing? I'm open to suggestions.

[Loirooriol]

I tend to think the authors should define the boundaries themselves, like

@custom-media --mobile (pointer: coarse) and (max-width: 10cm);

@media (--mobile) {
  ...
}

[Crissov]

This reminds me a bit of the classic ubiquitous computing device classes:

• tab, ~cm, wearable
• pad, ~dm, handheld
• board, ~m, mounted

[zcorpan]

@mfreed7 do you want screen size or layout viewport size? Note that https://drafts.csswg.org/mediaqueries-4/#mf-deprecated (and CSSOM) allows UAs to not expose the screen size.

Are coarse screen sizes (small/medium/large) OK to expose from a fingerprint perspective?

[mfreed7]

@mfreed7 do you want screen size or layout viewport size? Note that https://drafts.csswg.org/mediaqueries-4/#mf-deprecated (and CSSOM) allows UAs to not expose the screen size.

I suppose layout viewport size is fine. Again the use case is small-screen mobile which typically doesn't have the ability to resize the viewport.

Are coarse screen sizes (small/medium/large) OK to expose from a fingerprint perspective?

I would think much more fingerprinting information is available via window.innerWidth, no?