User agent overrides for top Japanese Sites(bugzilla.mozilla.org) |
User agent overrides for top Japanese Sites(bugzilla.mozilla.org) |
UA overrides are not the only tool in our toolbox. They're deployed in concert with outreach from webcompat.
UA overrides are a way of breaking a cycle, not preserving it.
They make it feasible for Japanese users to use Firefox without manually messing around with UA overrides (e.g., using Phony). And that gives us leverage. And with leverage our excellent webcompat team can get sites to make changes.
[1]: http://stackoverflow.com/a/31279980
[2]: http://blogs.windows.com/msedgedev/2015/06/17/building-a-mor...
I used to advocate using something like Modernizr and then writing your code against the results, but now I think an even more straightforward approach is to just do the feature detection you wish to use directly in your code. No sense in loading in a library and testing for things you don't need, still only to have those tests totally decoupled from the parts of your codebase that depend on the feature detection.
It makes more sense to do only the feature detection you need right in your codebase adjacent to the code which relies on the results.
I'm old enough to remember it was much earlier than that. In the early '00s there were already calls to do feature detection; jQuery was released in 2006 and it basically did it for you. In 2015, there is no excuse to do UA sniffing -- if anything, because we now have 20 years of case-history showing people will trivially spoof it.
While writing your own feature detection is still probably lightweight (although not by much if you customize modernizr correctly), you're not going to get all the edgecases Modernizr will unless you spend A LOT of time on it.
2 examples:
1) There's currently no way to reliable check if a browser support device orientation. Maybe because of bugs or incomplete implementations
2) It's impossible to tell when iOS 8.x has added the chrome around the page in landscape removing nearly 1/3rd of the entire view-able area on an iPhone5S.
https://github.com/Zarel/Pokemon-Showdown-Client/commit/30f2...
In Chrome, event.pageX/pageY refer to the position of the top left corner of the drag-preview-image, relative to the top left corner of the page.
In Safari, event.pageX/pageY refer to the position of the mouse curser relative to (0, window.innerHeight * 2 - window.outerHeight), a point slightly above the bottom left corner of the screen.
(Neither of these is spec, which as far as I know says that event.pageX/pageY should be the position of the mouse cursor, relative to the top left corner of the page.)
I eventually got around it by storing values from the `drop` event, but anyone who needed these values from the `dragend` event would be screwed.
My next most recent problem unsolvable by feature detection has to do with HTML5 Notification, whose API was massively changed recently. Attempting to use the new API on old versions of Chrome would cause the render process to crash (not just throw an error you could catch in a try-block, but actually crash like http://i.stack.imgur.com/DjdCX.png ). Of course, using the old API on new versions of Chrome would fail silently, so there was zero way to reliably deliver a notification to the latest version of Chrome without crashing older versions or using user agent detection:
User agent sniffing is just a bad practice. Everything about it is a hack. There's no right way to do something wrong.
The first is how many different ways sites are determining the browser corresponding to the user agent. You know that they're all based on "guess and test": come up with an idea for an if condition, open up the code in the 5 browsers you care about, see if the result works. It almost reminds me of the output from a fuzzer: it's a valid answer, but you can tell a random number generator and a lot of tries is what got you there.
The second is how many web developers seem fine writing the same website many times; once for mobile, once for IE, once for Chrome, once for Firefox. I've always taken the approach of doing exactly one site, and using whatever features are available in the worst browser the client wants supported. If extensive workarounds are needed to make the feature work in every browser, I say skip it. (I was always happy with what IE6 could do.) Of course, when I did web development, it was mostly boring corporate applications, not public websites that face pressure from competitors that are willing to write a codebase from scratch for every browser back to NSCA Mosaic. I consider myself very lucky.
The idea is that you're able to encode information about the execution environment into the type system, so that you can do things like write functions that depend on having access to GPS coordinates, or an audio output device, and so on.
The theory is that this will make it easier to target a wide variety of platforms, or devices which may restrict access to information through permissions systems, like those offered by Android or iOS. If, at compile time, you know you've handled all of the cases of an environmental constraint either being met, or not being met, then you have a much stronger guarantee that your code isn't going to unexpectedly fail spectacularly on a platform you haven't tested against.
Stop this feedback loop. The client is not responsible for the server's bugs.
The vendor has an obligation to create the best web experience for the user and while it’s certainly a sad state of affairs that not more sites are testing for features rather than the UA string, it’s a sad fact that not all web authors care enough about interoperability to remedy their bad ways.
I've used the detectmobilebrowsers.com as a baseline in the past, and only tweaked slightly so that fallbacks with "phone" will be xs (extra small), otherwise common mobile OSes would get "sm" (small), while desktops get "md" (medium) ... if you use adaptive CSS, and JS you can/should of course adapt if the pre-rendered environment doesn't match.
There are other modules written to predetermine a lot more, but it's all kind of a bit sad.
Unfortunately, there are cases where it is still necessary. For example, IE 10 reports that it supports the CSS pointer-events property, but it only works on SVG elements, not HTML elements.
You probably still have nightmares of these: https://msdn.microsoft.com/en-us/library/ms537512(v=vs.85).a...
On the way to 2012 it became clear once Microsoft said they never intended to let IE announce itself as IE in the future that the game was finally over for UA sniffing. The funniest part was I still remember the MS fanboy blog post that was saying how wonderful it would be that future versions of IE would identify itself as not IE, and how this would make the world a better place. :P
Netscape versus IE (late 90's) - features didn't matter, they just rendered HTML and CSS differently
Firefox versus IE (early 00's) - Firefox added a bunch of great CSS support and things like rounded corners and PNG transparency, so once we could use those we could just supply a polyfill for the specific IE version that needed it. Opera could handle it already, Netscape was Firefox rebranded. Only IE (which announced itself as IE) needed extra help
Mobile vs Desktop (late 00's) iPhone! Android! Tablets! Now is where things start to get a little crazy, IE will be IE but a bigger concern is the separation between tiny little touchscreen devices browsing a website, and a massive desktop computer
Mobile versus Mobile (early 10's) - IE never says it's IE, we have smart watches, phones, phablets, tablets, netbooks, notebooks, and still desktops. There is Firefox, and Chrome that run on Mac, Windows, Linux, iOs, and Android, there's Safari which runs on OS X, Windows (old version), and iOS, there's IE, of which there are 8,9,10,11 and the new ones in circulation, and a handful of other browsers like Android browser that kind of gave up a long time ago but are still used.
I'm sure backend software was rife with feature-detection for the OS's it ran on (Redhat versus CentOS, special support for IIS, etc) but until things exploded after the iPhone was released in 2007 the web had very predictable deficiencies that could be addressed more directly than feature detection.
I can remember as a Linux user, there were plenty of websites that would only let 'approved' User-Agents in, because they would rather you NOT see their site than see a site in a browser they didn't support. When using Linux I often didn't have access to IE or Netscape, so I would use Firefox or Konqueuror to spoof a different User-Agent. Nintendo.com used to be like this, plus others.
2) The existence of autoconf et al is not in any way preventing people from performing platform tests all over the place, so it's not like a panacea.
Sorry if you find this a bit abrasively worded, I aimed to avoid that, but you made me bristly with your implication that "web folk" are somehow lesser.
If you're using the majority of Modernizr tests it makes sense to use the full library, but for the most part me and the other devs I've talked to usually drop the whole library in for ease of maintenance, but mainly use it for one feature alone: touchscreen detection.
Lately I've tried putting some of my HTML on a diet by replacing my need for Modernizr for the purpose of touschreen detection with this snippet:
if(('ontouchstart' in window)||(navigator.msMaxTouchPoints>0)){
// code for touchscreens here…
}
Suppose Modernizr were a book, and each feature Modernizr tests for was a recipe. What I'm suggesting is this: Instead of going to the library and checking out the entire recipe book just to refer to the icing recipe, just copy out the list of ingredients and leave the book on the shelf. you're customizing the recipe anyway, so if you just add their list of ingredients to the steps you're writing for your own customized icing it's going to be easier in the future than if you write your recipe steps with a little note that says: 'refer to ingredients on page 24 of Modernizr Cookbook'. I also think buying a personal copy of the book for the same purpose is overkill - it makes more sense just to list the specific ingredients you want to reference directly inside the new recipe you are writing and keep it all on the same page, plus not have to worry about where that recipe book is every time you want to whip up a new batch of icing.