This makes sense since it should avoid two issues:
- Sites that try to detect mobile by looking at "ARM" in user-agent string
- Sites that try to parse the macOS minor version for some reason and would be confused to see something like "11_0"
BTW, user-agent is a hell anyway. Just looking at this user-agent that OP posted, macOS still identifies itself as "Mac OS X", still is based on Mozilla/5.0(!), still identifies itself as KHTML enginee (compatible with Gecko), and so on...
Oh my god can we please kill the user agent string already? Every time any new combination of browser/os/platform is created it claims that it's as some other user agent from an established browser because sites are lazy and abuse user agent string to determine capability. Meaning they have long lost all meaning and we should just dump them.
> Oh my god can we please kill the user agent string already?
Browser makers tried to do that by providing feature detection, but the weight of legacy code and developers already used to using the user agent strings has made killing it impossible.
Edit: As pointed out in another comment here, it seems like Google is killing it (or planning to). [1]
You can probably get the same information by looking at the webgl fingerprint, since the iGPU inside the A12Z is different than the ones used in Intel macs.
It's more complex and requires to use JavaScript that you can block in the browser, while the user agent is always sent to the server on every request, and thus is much easier to fingerprint the user with that.
It is hell, but it is only way to workaround the hell tons of safari graphic bug.
Because it only affect graphic, you can't really detect whether you are affected by it or not from js.
The best thing you can do it guess the browser from user-agent and apply the workaround anyway. Or you can pray for the apple to fix their sh*t (given what they have done in the past, it is unlikely).
Something like the safari failed to draw some elements suddenly. JS reported it is there. Query the size with js do work. Select it with devtool works. The only thing not work is... the element is invisible. Hide and show the element again makes it show correctly. But how do I know whether it is bugged now without guest the browser from user-agent?
> BTW, user-agent is a hell anyway. Just looking at this user-agent that OP posted, macOS still identifies itself as "Mac OS X", still is based on Mozilla/5.0(!), still identifies itself as KHTML enginee (compatible with Gecko), and so on...
This is why we have some more developers spending time on creating FOSS libraries that parse user agent strings and tell you exactly what the browser claims to be, with attributes like browser name, OS, version, browser engine, etc. All these libraries need updates (or at least a cursory look) whenever a new browser version is released so that they can continue identifying browsers correctly. All those people, bless them for this work, could be doing something else in an alternate universe.
Notwithstanding feature detection and graceful downgrades, browser user agent strings seem to be very commonly used to decide the behavior of many websites.
The replacement they're going with, "client hints", is weird in its own way. Suppose you render your website server-side, and suppose you use different templates for desktop and mobile. You then have to determine the kind you want before any response is sent, but the new method prevents you from doing that; you have to send a response to ask the browser to send the mobile flag in a subsequent request. You'd have to use ugly workarounds for that. One that comes to mind is to issue a redirect to the requested URL itself, but ask for the additional headers. Not optimal because it adds a round-trip and I'm not sure it'll work at all. User agent strings aren't pretty but they make this kind of detection extremely easy and straightforward.
And "actual feature detection" doesn't work with SSR, like, at all.
It is true that trying to make a website Javascript and CSS free is becoming a very limited proposition. The problem with pure HTML sites using SSR is that they have to assume the user-agent defines some sort of contract around features when absolutely none has ever existed. And browsers have to assume SSR sites will update behavior correctly when the user agent string changes, which also has seldom been the case. This is why all user agents still include Navigator, Gecko, KTML, WebKit, etc in their strings for regex to chew on.
The latest iPadOS, for example, purposely reports itself as a Mac desktop because too many sites saw 'MobileSafari' and returned a sub-par site experience based on a small mobile phone screen. But it actually goes beyond that:
1. It lets the user toggle the user agent themselves between mobile and desktop (iPhone and Mac Desktop style agents)
2. The browser will by default use a mobile user agent when rendering in a small form, such as a browser in a smaller modal window or a side-bar.
Client hints might provide a way to actually formalize a contract for SSR apps, if people participate and indicate what they need.
A good observation, but why do you need to serve a mobile and a desktop version of your site in the first place? You can with modern HTML and CSS make a website that works perfectly on mobile and desktop, without having to serve a different version for the different platform.
It doesn't make sense to make the choice of what to render on the user agent: for example if it says Android, what does it mean? It is probably a smartphone, but it could also be a tablet, a TV, or even a PC!
An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile, since it usually work one way and thus if you share on a chat the link to the mobile version of the site and the other one opens it on a desktop there is no easy way to get back to the desktop site (most of the times I have to modify the URL!)
I might be a minority, but I don't like modern adaptive websites. They try really hard to work on both touch and non-touch devices with the same underlying markup, and more often than not end up being terrible on both. You end up with these giant, touch-friendly buttons on desktops. Making all your paddings and layouts and font sizes dynamically adapt to the interaction paradigm is hard and almost no one's doing it. Then there are some interactions that are only possible on desktops — like hovering things to reveal menus or tooltips; these websites rarely make use of the unique properties of the mouse. Or sometimes they do but then you happened to open it on your phone and you have to tap and hold the thing to trigger the hover. And so on.
> It is probably a smartphone, but it could also be a tablet, a TV, or even a PC!
That's what the "request desktop website" setting is for.
> An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile
I'm using either a 27" 1440p monitor or the built-in screen of my 15" macbook. Either way, modern web makes fonts and UI elements a tad bigger than they have to be, and there's usually too much area wasted on whitespace between them.
Desktop UIs are meant to be compact because mice and trackpads allow nearly pixel-level positioning. Mobile UIs, on the other hand, have to have large elements and ample spacing between them because tapping stuff with your fingers is inherently imprecise. You can't really have both these things at the same time.
Out of websites that are currently live and have good desktop versions, I'd point out HN and reddit (the old design).
And then there's Facebook who has separate mobile and desktop websites but recently chose to redesign its desktop one to look very mobile... I can't imagine the justification behind this one.
You're certainly welcome to prefer more compact UIs on your very large screens, but it's only that: a preference. There are many reasons why other people either prefer or need (i.e. accessibility, touch) larger text and UI elements to be able to use these websites.
I personally prefer (and may well someday need) larger text and UI elements, because my vision and motor skills have gradually declined. I also prefer (and soft-need) lower information density because higher density is a cognitive challenge (ADHD).
> An even more stupid idea is to redirect the user to a different domain if you detect that the user agent is mobile, since it usually work one way and thus if you share on a chat the link to the mobile version of the site and the other one opens it on a desktop there is no easy way to get back to the desktop site (most of the times I have to modify the URL!)
Absolutetly this - the number of people sharing m. links for Wikipedia when is just annoying. And there is absolutely no excuse for having different HTML for today's smartphones and Desktops. For text sites like Wikipedia you shouldn't even need media queries or any fancy stuff - just avoid fixed (minimum) widths and use <meta name="viewport" content="width=device-width, initial-scale=1"> to tell broken-by-design mobile browsers that your website is not broken and can be rendered normally instead of in a giant viewport.
They should just make a gentleman's agreement that the four majors will change it to name and version without any of the cruft. Every broken site will be quickly shamed into fixing their shit.
If there is a constant in the universe it's that developers will always be trying to detect X by querying for Y and then have their code break when those assumptions become wrong.
I don't know whether to laugh, or to instead be triggered by the traumatic memories which were buried deep within the recesses of my mind until now and assume the fetal position.
This was originally done by IE way back in the day, for a variety of reasons - one being to not block IE. So, they just masqueraded the IE browser as Netscape. It's been a mess every since.
Yeah, it's one of those pernicious things that highlights that a powerful player like Microsoft can essentially lie or disregard standards for their own benefit and thus cheapen the entire purpose of the rule.
Not sure why you're being downvoted, but this is exactly the reason. Chrome on Windows includes "Safari" in the user agent and Chrome on Android includes "Mobile Safari" because if they don't add it, tons of websites will break.
Everyone does this, which is kinda why we need to get rid of user agents and replace it with feature detection (and css that works everywhere for people who don't want to run Javascript).
Javascript feature detection is much too late when you need to send headers with the HTML and browser vendors can't agree on the header values or change their mind on what things mean. Like the samesite cookie nonsense: https://www.chromium.org/updates/same-site/incompatible-clie...
Assuming things like that continue to happen, what are web developers supposed to do?
I propose a Real-Agent header that includes browser name and version, os name and version, cpu type (maybe) and desktop/mobile flag (maybe). Or separate headers for each name/version data, I don't care, I just know I need real data sometimes, and some new weird server request pattern isn't going to work well. Then continue to send shakespearean sonnets in user-agent for all I care.
Bugs should be fixed by who produces the browser and not by the website administrator by looking at the user agent and using workarounds.
When someone asks me to build I site for them I say, look I will guarantee that the site that I make is compliant with the W3C specification. If there is something that it doesn't work because some browser don't implement the standard correctly, you go to Microsoft to complain, or you install a decent browser like Firefox.
> Bugs should be fixed by who produces the browser and not by the website administrator by looking at the user agent and using workarounds.
IE 6 had such a history where it held back other browsers and developers were held hostage to it for several years. Now we have Chrome to fill that gap and some Google platforms won’t work well or work the same on Firefox.
Lol, I don’t know who your clientele are but producing websites that don’t work on popular browsers “because the browser is not following spec” is a non-starter. A bank wants a banking website its customers can use, not a website 60% of its customers can use and a link to a 7 year old bug report.
Disagree. You can't just tell your customers "my product doesn't work because of Microsoft, go complain to them; even though it's possible for me to work around it, I'm choosing not to".
Then part of feature detection could be detecting bugs and working around them. This wouldn't have to be done by every web developer, but bundled into a commonly used library so cruft can be taken out when browsers fix bugs.
If a browser updates with a new feature that Chrome already has and other sites already use, the users get to use the new feature with no update from the developers due to feature detection.
I don't disagree with you on feature detection, but there is no feasible way to encode all browser bugs that require workarounds into a library. By nature, these are usually extremely niche.
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_16) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15"