(Replying to PARENT post)
That approach is fragile, because it won't stop applying the crazy workaround after Chrome version Y fixes the problem.
You can't know which version it's going to be, and there's a chance you won't be maintaining that code anymore then.
👤pornel🕑5y🔼0🗨️0
(Replying to PARENT post)
In the short-term this might be annoying, but in the longer term this is going to force browsers to adhere more closely to standards. When sites are less able to write different code for different browsers, the onus to fix inconsistencies will transfer from site-maintainers to browser-maintainers.
In 5 years you might look back and realize you no longer write browser-specific code any more.
👤henryfjordan🕑5y🔼0🗨️0
(Replying to PARENT post)
+1. The number of rendering invalidation bugs I had to work around in mobile Safari is crazy.
`if(affectedBrowserUA) { elem.style.transform = 'translate3d(0,0,0); elem.style.transform = ''; }`
Edit: I guess you can achieve the same thing through UA client hints. Just need to add a new JS file that reads the request headers and maps them into JS globals.
👤AdamTReineke🕑5y🔼0🗨️0
(Replying to PARENT post)
I'd argue that if you're doing this you can't have tested your JavaScript on many platforms. This breaks very quickly in my experience. Feature detection[1] is a much better strategy. That can get complicated too, but often there are third-party polyfills that can do that for you.
[1] https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...
👤kerkeslager🕑5y🔼0🗨️0
(Replying to PARENT post)
It's VERY useful to be able to use the UA string to do something like:
if (Chrome version X) then { do this crazy workaround because Chrome is broken }
No. People don't even necessarily update to the latest version. The "Samsung Browser" was notorious for seemingly always be some old fork of Chrome or Chromium that would never update.