5 ms·
So, all the people that agree on the new "standard string" update their browsers to send that that, and find themselves unable to use all the websites that are
by tacostakohashi 12y ago
So, all the people that agree on the new "standard string" update their browsers to send that that, and find themselves unable to use all the websites that are still checking for some variant of "Mozilla/..." because their administrators haven't updated them yet (i.e., the entire internet). Nice idea.
- UnoriginalGuy 12y agoThat would be the standard string. It would just be an ugly legacy string that tries to be all classic UA strings. You just stop updating it past that. The main goal isn't to break backwards compatibility, it is to make the point that there won't be FORWARDS compatibility. That UA string is static forever.
- tacostakohashi 12y agoThat's what "Mozilla/..." already is and always has been, and it obviously doesn't work. All you need is for one browser manufacturer to break the rule and advertise their new feature via something new at the end, and then everyone else who continues to play by the "standard string" rules suffers. Don't get me wrong, I am not advocating UA strings - but to get rid of them, there needs to be an approach where there isn't a punishment for following the rules.
- cpeterso 12y agoEven removing"Mozilla/" could break UA detection that uses hardcoded string indexes to version numberz. :(
- tracker1 12y agoHell, I'd be happy if browsers sent a content and platform dimensions headers... so that I at least know the screen size, and if it's in a window, the content size that will be filled.... would make it really nice to be able to do adaptive rendering of the markup.
- derefr 12y agoBrowsers can do "broken website" detection much better than websites can do "broken browser" detection. (Few browsers with frequent updates vs. many sites with most "dead", etc.) Internet Explorer (of all things) already had the right idea with its "previous IE" mode: if the renderer emits standards errors while parsing the site, offer to retry with an older renderer (and send that renderer' original UA.) The newest Mobile Safari has a similar idea: if a site seems to force certain mobile viewport constraints, then offer to redo the request with a desktop UA instead of expecting the site to know how to set a sticky-session parameter of "desktopness." In fact, Chrome's "Translate this Page" popdown might be the best example: you get a page you might not understand, along with an offer to magically fix the issue (which is nevertheless optional, because the user might speak that language after all.) To wit: let old UA-detecting websites break. And then notice that they did, and offer to send a "compatibility UA" only in those cases. Turn a cost browsers were eating into a light punishment (but not impairment!) of the websites responsible. A carbon tax on archaic coal-powered websites, in a sense. (And note that this wouldn't have to be work repeated by every user, or even seen by many at all. Google could build a perfect pre-seed database for this just by doing comparative search indexing using Googlebots that send differing UAs.)
- cbr 12y agoInternet Explorer (of all things) already had the right idea with its "previous IE" mode: if the renderer emits standards errors while parsing the site, offer to retry with an older renderer (and send that renderer' original UA.) IE dropping into various modes to interpret your document can be wonderful when it works, but can also be a huge pain. I work on PageSpeed, an open source optimizing proxy, and this IE behavior keeps us from making a lot of optimizations on IE. Consider this code: <link rel=stylesheet href="main.css"> <!--[if IE 7]> <link rel=stylesheet href="ie.css"> <![endif]--> <link rel=stylesheet href="more.css"> Combining multiple CSS files into one is a great way to speed up page load times because most of the time in loading these resources is waiting for the round trip. We would like to issue: IE7: <link rel=stylesheet href="main+ie+more.css"> Other browsers: <link rel=stylesheet href="main+more.css"> But IE's impersonation keeps us from doing this. When we process a page requested with an IE UA, we don't know which version of IE it will decide to be when interpreting the page. Yes, it claims to be IE10, but if it sees something to drop it into IE7 mode then we shouldn't have removed ie.css. My favorite part of this announcement is the link [1] to where MS says this detection is going away: The next major version of IE will still honor document modes served by intranet sites, sites on the Compatibility View list, and when used with Enterprise Mode only. ... Public Internet sites will be rendered with the new Edge mode platform. [1] http://blogs.msdn.com/b/ie/archive/2014/11/11/living-on-the-edge-our-next-step-in-interoperability.aspx http://blogs.msdn.com/b/ie/archive/2014/11/11/living-on-the-...