Hacker News new | past | comments | ask | show | jobs | submit login

The correct approach is to use feature detection. There are libraries available for it, such as Modernizr [1].

[1] https://modernizr.com/docs/#what-is-feature-detection






You can't always feature detect bugs. I'm not sure why this entire thread is filled "use feature detection" when it's been historically clear that it isn't sufficient.

Part of the proposed deprecation of the useragent is a JS API to expose the information.

Which is silly since the information that's needed to work around version specific bugs is ($vendor, $version) so people will just end up depending on that and it will start the cycle again.

I appreciate the idealism of "if your standard's compliant site doesn't work in Chrome 142 then it's Google's problem" but I can't just throw up my hands and let my site be broken.


> so people will just end up depending on that and it will start the cycle again.

The User Hints spec specifically says that user agents aren't required to provide them in all circumstances, and that they shouldn't be provided in some.

> User agents ought to exercise judgement before granting access to this information, and MAY impose restrictions above and beyond the secure transport and delegation requirements noted above.

The message from Google is clear: Whilst we understand you want to work around bugs, and this is the only way to do it, you really should be second-guessing whether you need to touch this API at all.


Great, now my server side rendering code needs to inject JS into the customer to feedback agent capabilities.

Or check the proposed headers that will also get sent: Sec-CH-Arch, Sec-CH-Model, Sec-CH-Platform, Sec-CH-UA, Sec-CH-Mobile.

Sec-CH-Mobile ? - please tell me the meaning of this is "user agent changes position, refresh positional data often" (checks the specs)

  user agent prefers a "mobile" user experience.
the spec is a tautology using air-quotes :/

That makes sense to me. Different websites will have different expectations of what specifics a mobile experience will need. It may just be different style sheets, or the dev will need to take into account the activity of their particular site, such as reducing background connections to preserve battery life, etc.

Surprisingly i do know what >> "mobile" experience << means in this context and can therefor make sense of this, too. I am just making fun of it by pretending i am reading a technical document that is supposed to specify how to build a sane and reliable system ;-)

A JS API that tells you which bugs exist in the browser?

> Where feature detection fails developers, UA Client Hints are the right path forward.

UA Client Hints will provide: brand, major version, full version, platform brand and architecture, platform architecture, model and whether it should be treated as a mobile platform.

If you were using the UserAgent to guess if the browser was a particular version with a particular bug, now you don't have to parse something and probably get it wrong.


> UA Client Hints will provide: brand, major version, ...

It seems you are using "Mozilla 5.0". Your browser is really out of date!

Please consider updating to rand("Googlebot/2.1", "Version/7", "XUL/97", "HTML/5").


There's no guarantee the user's browser will just hand over that information with the new spec:

> User agents ought to exercise judgement before granting access to this information, and MAY impose restrictions above and beyond the secure transport and delegation requirements noted above.


You can't always detect browser version, either.

Hard problems are hard, but my experience, and the recommended approach by browser implementers, is that feature detection works better.


The fundamental issue with this is it tells you about what's there when what you need to know is what's broken (not even necessarily what's missing).

But this is only accessible on the client side, what about all the other backcompat code on the server side (like the SameSite issue mentioned elsewhere in the thread?) Or server-side rendering? Are we not supposed to care about progressive enhancement anymore?

I build HTML5 games and I need to use very specific hacks for certain browsers, e.g. use a different offscreen canvas implementation for Safari due to performance. I can't use feature detection since it's not about a missing feature.

You can benchmark the alternatives for 2 seconds and choose the faster. Call it: performance detection

For that to work, browsers would also have to accurately advertise their own bugs/quirks, which might be a difficult ask.

Wouldn't those quirks be sufficient to fingerprint in the same way?

What if the DOM looks perfectly normal, but doesn't render correctly?



Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: