Hints to identify different form factors #333
Comments
|
Thanks @mrajah1 - I think it's a proposal worth considering. I'd like to gather up some data on existing patterns and report back in the next few days - I know that various browsers have shipped some form of TV, VR and Tablet tokens have shipped at some point in different UAs. |
😅 OK, anyways, here's some non-exhaustive data to motivate a use case: Sources:
Cars/ AutomobilesExample token values: “QTCarBrowser”, Example UA strings:
It seems like people also just look at the model name, probably because there are so few browser-enabled cars right now (Tesla being a notable exception) - but that's not super scalable. TelevisionExample token values: “tv”, “TV”, “SMART-TV”, “SmartTV”, “Smart TV”, “Smart_TV”, “HbbTV” Example UA strings:
VRExample token values: “VR”, “MobileVR”, “Mobile VR” Example UA strings:
TabletExample token values “Tablet” Note: Firefox for Android (from 11 to 68) had a “Tablet” token (but then removed it)
Not a lot of Tablets follow this pattern these days. What else? Smart watches? Smart speakers? Not sure. |
|
https://groups.google.com/a/chromium.org/g/blink-dev/c/0Bctfvd-Sg8/m/e9Mq_TrJBgAJ reminded me of "Web XR" browsers, i.e. https://hackmd.io/@XR/xrbrowsers See also I don't have any of these Microsoft devices to test UA strings, but it seems like "XR" is sufficiently different than "VR" and would be included as a valid value. So maybe if we decide to add this client hint, the list of bikesheddable values (to begin with) would be something like "Automobile", "Tablet", "TV", "VR", "XR". And we could add additional values as use cases popped up. |
* Add a Sec-CH-UA-Form-Factor hint * Include Form-Factor hint in explainer Fixes #333
|
Not sure if we actually want "Tablet"... or if we should remove it. |
|
Automobile or Automotive? |
|
@mrajah1 which do you think is better? I don't have any strong feelings - it's just a string to me. |
|
prefer Automotive. |
|
The "mobile" boolean field only for phone mobile. So I think "Tablet" is needed for check pad device. |
|
Can anyone provide a use case for why you would need to know server-side that the device is a tablet etc? Wouldn't existing data hints like screen size and data saver cover those? |
|
I think it's more useful for browser client. Detect current device and rendered as the specific view. |
|
Why do you need to know client-side that the current device is a tablet? You know what the screen size is, what the screen resolution is - what more do you want to know? |
Yeah, I have this question as well, I'm not 100% sure why Tablet is as useful as Automotive or TV... and the fact that Firefox and Chrome (and iPad...) don't send it anymore suggests it's not so important. But I'm open to other use cases. |
|
This list feels like an invitation to bikeshed. Are phablets included? How should my Internet-enabled refrigerator identify itself? What about the browser embedded in my tractor - is that automotive or a tablet? I think this could be headed off by clearly defining
|
|
Maybe we want to go the other direction and embrace the chaos a bit. I think To start, many websites want to support iPads so they want browsers to report the model Then, Apple buys Nintendo introduces the iPadDS with two screens that folds like a clamshell. Now its browser will send a model Finally, Apple introduces iPad3DS with 3D support and an AR mode. The browser now sends a model Is this a little bit of a mess? Yes. If we don't provide a space for a mess will a mess just be made in an unexpected place (maybe via many client hints like |
|
I agree - that seems the more common approach in the history of the web, and takes the spec out of the feedback loop of webdevs trying to generalize and device manufacturers trying to specialize. |
|
Mozilla's Firefox Android team is debating whether Firefox on tablets should send a UA string with Safari on iPadOS sends a Safari desktop UA string (e.g. Chrome on tablets sends a UA string that includes the |
|
From a TV manufacturer point of view, the motivation and field naming look good to me. CSS WG has tried to classify major types of devices(media) such as tv and handheld, but it's rarely used now. In addition, 'automotive' term would be an appropriate one, since W3C has several automotive specs. The values of TV, VR, mobile, tablet would be acceptable, but I'm not sure the XR case. XR devices can be diversified such as a glass, mobile w/ camera and dedicated one. We can expand more values(types) for upcoming influential future devices later. (robot, watch, fridge, window) |
Yeah, I think this is a good idea.
I think I'm convinced on changing the type to list for form-factor, but the ship has sailed on changing the type for model. Why don't we keep the existing list, and try to add some language about adding new items (or something) as they become relevant: "Automobile", "Tablet", "TV", "VR", "XR" |
|
Still confused as to when you'd ever need to know that the current browser is an Automotive or a Tablet, and not just a screen of a given size. "VR" or "XR" I could kinda see, as you could eager-load WebXR Device API-based code on those environments, but that's not really much of an advantage, is it? |
|
I think @mrajah1's first comment addresses a bit of that: from the user's perspective, there's more difference between form-factors than just screen size, relating to how information is presented and how the user interacts with that information (gestures, inaccurate pokes while watching the road, etc.). Sites currently need to "guess" how to behave based on UA string and other available data, and that guessing causes issues: new devices might not be recognized by important sites, so the device manufacturers "lie" in the UA string; and users have bad experiences when a site mis-characterizes a device and provides e.g., a desktop experience on an auto. Providing a clear signal related to the user's understanding of the device would reduce these issues. As @arichiv suggested, we'll still need some room for "mess", and I suspect making the header a list, using "SHOULD", and including non-normative descriptions of each value will allow that room. I think there's a valid question of whether it's necessary to include this information in the HTTP request headers. It can help for situations like eager-loading assets and code related to the form-factor. But probably most uses of this information will be client-side, via Speaking of which, this will be high-entropy, as some hint values will always be comparatively rare and thus carry significant information identifying the user. |
|
I had a look today at the current draft specification of the Sec-CH-UA-Form-Factor and noticed some things I found confusing and also some I found missing. It currently says the header should have one of these values "Automotive", "Mobile", "Tablet", "TV", "VR", "XR", "Unknown" or the empty string (which implies "Desktop"). Most of these terms are obvious to me, except for the "VR" and "XR".
If I understand this correctly then the builder of a browser running on a VR system would have 2 equally valid values to choose from ... which will lead to confusion. With my current understanding I would remove the 'VR' one. In line with earlier remarks; What is this header intended for? The current list of values is nudging towards what I call in my own software the DeviceClass. See https://yauaa.basjes.nl/expect/fieldvalues/#deviceclass At this point I tend towards knowing what technical variant of the website should be provided to the visitor. In my experience that is about things like (similar to what @djmitche said):
So either the single "Form factor" is really something like the 4 attributes I just mentioned, or it should be simplified (i.e. less values), or the list of values should be a lot longer to describe all variations ... adding Watches, Home appliances, Smart Displays (Google Nest and such), Fixed Gaming Consoles (PS5, XBox), Mobile gaming consoles (Nintendo Switch), Headless systems (GoogleBot, Mastodon server-to-server), eReaders (very slow screens, no animations), etc. I'm really curious to hear what original the intended meaning is and how you view my points. |
|
#343 tries to address some of these points - I'd love your feedback! |
|
Coming in late on this, but...did we (as a community or practice) not decide ages ago that we'd want to feature-detect based on more specific characteristics, rather than trying to lump things into very broad, ill-defined, and often overlapping "buckets"? Is this going to be a re-run of the various media types ( |
|
Hah, your timing is impeccable.. I can't speak to the past as I wasn't part of this community group at the time, but that is concerning. What were the issues with those media types? In this case, we've allowed for "overlapping" by using a list. And perhaps leaning heavily into the "form-factor that users interact with in a meaningfully different way" will help them be better-defined. I think "broad" is a feature. |
|
@djmitche As per @patrickhlauke 's comment, the "form-factor" model (e.g. Desktop vs Mobile) suffers from the bundling of various properties under a single term, that are actually orthogonal. For example, before touch-screens became common on laptops, Mobile was interpreted as meaning "has touch input", while Desktop meant the device did not. But Mobile was also interpreted to mean "low bandwidth connectivity", which might also apply to Desktop, if the Desktop is actually a laptop. Mobile was also assumed to mean "has a small display", whereas Desktop form-factors would have big displays, and then tablets came along, and so-on :) |
|
Rather than form-factor, would hinting the pointer fulfill this use case, when used along with other hints (width, in particular)? By hinting this criteria, it could be used in server-side considerations. As this already exists in CSS, the logic could follow the CSS From that logic (again, in combination with other hints such as Width) it would be relatively easy to determine a general form factor - tablet, phone, hybrid (tablet w/ mouse - like the Surface or iPad with Magic Keyboard), computer, TV, etc. |
|
To @drwez's commments from 10 months ago (!): the bundling is intentional, as users perceive their device and user-agent not as a bundle of properties but as a cohesive whole. And browser vendors tend to make the same categories, with dramatically different UIs for different form-factors. So I think browsers wouldn't have to do a lot of detection And the ability to list multiple form-factors means that an exciting new form factor Z with the elevator pitch "like X but also Y" can list form-factors X and Y as well as Z. Rewinding history, maybe that means that the "phablet" form-factor would have been described in the hint as ["phone", "tablet", "phablet"] -- so a site unaware of phablets but with a dedicated tablet UI would use that UI on the new device, but a site aware of phablets could further specialize. I suspect we'll want to get a bit more practical experience here before making further changes. The hint shipped in Chrome 124, but to my knowledge not in other browsers. |
|
i admit i still remain unconvinced - would prefer granular hints over broad "buckets", as that's more in the spirit of feature/capability detection. |
|
@patrickhlauke Considering one of the main goals of this feature was to reduce the fingerprinting potential of the user-agent string, "more granularity" is actively counter-productive. |
User Agent strings currently contain Mobile to indicate a hand held mobile device. As we consider form factors like TV, VR head sets, automotive and more it would be very useful to know what form factor the customer is browsing a website on so webapp owners can fine tune the experience.
Eg. a VR experience might want to make things more friendly for hand gestures, automotive larger touch targets
Could we consider a new Client Hint for this purpose?
The text was updated successfully, but these errors were encountered: