Hacker News Reader

Comment by fluffything | Hacker News Reader

And doing this encourages websites that actually need to detect this platform properly to introduce the next generation of horrible things.

View on HN

Browsers will almost certainly begin to phase out user agent strings anyway: https://www.zdnet.com/article/google-to-phase-out-user-agent... .

In the vast majority of use cases, these values should not be used to detect platform features - actual feature detection should be used instead.

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.

“Every broken site” will be internal enterprise web-applications that haven’t been touched in 15 years where they’ve also lost the source code.

They can slap a proxy on the front to change it back to what they need.

That sounds like work. Which costs money.

They can just not update their browser - which is essentially doing "no work", and is free.

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.

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

Yes, I wholeheartedly agree with you on this one.

Either the sites you’re visiting are doing it wrong, or you’re expecting a density of pixels that never worked well for most mouse users already.

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.

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.

Good thing there won't be any more browser/version specific bugs to work around!

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.

Reply on news.ycombinator.com