Change Details

Our browser blacklist for differentiating between Grade C and the rest is getting rather long. When it was just IE<=5 it was a quick hack, but now it's getting big. This article about BBC web developers "cutting the mustard" reminded me of the important of feature detection: http://responsivenews.co.uk/post/18948466399/cutting-the-mustard It would shrink our code a lot because a small set of feature tests cover the same as all our hardcoded user agents. More importantly, feature detection will give the blacklist a lot more meaning. Lesser known browsers that we don't officially support will automatically fall in the right category. We use the same approach in VisualEditor already. A few User-Agent may still be hardcoded as supplementary filter (for browsers we know pretend to support features, but don't; or for features harder to detect). It will give us confidence and stability into ensuring the runtime has the methods that we require. It would also make it easier to in the future turn off javascript for non-ES5 browsers by simply adding a one line feature test for it.

### Preable Wikimedia wikis page views (February 2016): | Total | Grade A | Grade X | Grade C | -- | -- | -- | -- | 100.00% | 86.27% | 9.16% | 4.58% | 16002 M | 13804 M | 1465 M | 732 M * Grade C: Browsers we've identified as not supporting our JavaScript run time. Officially supported, as noscript. (e.g. IE 8, Opera Mini) * Grade A: Browsers passing the startup sniffer, get JS, and we officially support them. (e.g. Chrome, IE9+) * Grade X: Browsers passing the startup sniffer, get JS, but we don't officially support them (e.g. Iceweasel, UC Browser, Yandex). There is no technical distinction made between Grade A and X. Just that we don't regularly test in Grade X browsers, nor prioritise issues specific to those. More details at <https://www.mediawiki.org/wiki/Compatibility#Browsers>. We currently split between Grade C and Grade A+X by sniffing for Grade C user agent strings. This blacklist is getting rather long. Once upon a time it was just `IE <= 5`, but it's grown much larger since. (see [startup.js#isCompatible](https://github.com/wikimedia/mediawiki/blob/df1019c49d/resources/src/startup.js)) ### Reasons Converting to a feature test would: * ... shrink this critical code path (T127328). * ... make it more maintainable. * ... give the blacklist a lot more meaning. Allowing us to confidently use features without conditionals or theoretical fallbacks. * ... older versions of browsers that we no longer support will automatically fall in the right category. A small set of feature tests would effectively cut Grade C the same way as our user agent sniffer. It would also make it easier to, in the future, turn off javascript for non-ES5 browsers by simply adding a one-line feature test for it. This article about BBC web developers "cutting the mustard" reminded me of the important of feature detection: http://responsivenews.co.uk/post/18948466399/cutting-the-mustard

Our browser blacklist for differentiating between Grade C and the rest is getting rather long. When it was just IE<=5 it was a quick hack, but now it's getting big.### Preable This article about BBC web developers "cutting the mustard" reminded me of the important of feature detection:Wikimedia wikis page views (February 2016): | Total | Grade A | Grade X | Grade C http://responsivenews.co.uk/post/18948466399/cutting-the-mustard| -- | -- | -- | -- | 100.00% | 86.27% | 9.16% | 4.58% | 16002 M | 13804 M | 1465 M | 732 M * Grade C: Browsers we've identified as not supporting our JavaScript run time. Officially supported, as noscript. (e.g. IE 8, Opera Mini) * Grade A: Browsers passing the startup sniffer, get JS, and we officially support them. (e.g. Chrome, IE9+) * Grade X: Browsers passing the startup sniffer, get JS, but we don't officially support them (e.g. Iceweasel, UC Browser, Yandex). There is no technical distinction made between Grade A and X. Just that we don't regularly test in Grade X browsers, nor prioritise issues specific to those. More details at <https://www.mediawiki.org/wiki/Compatibility#Browsers>. It would shrink our code a lot because a small set of feature tests cover the same as all our hardcoded user agentsWe currently split between Grade C and Grade A+X by sniffing for Grade C user agent strings. This blacklist is getting rather long. More importantlyOnce upon a time it was just `IE <= 5`, feature detection will give the blacklist a lot more meaningbut it's grown much larger since. Lesser known browsers that we don't officially support will automatically fall in the right category.(see [startup.js#isCompatible](https://github.com/wikimedia/mediawiki/blob/df1019c49d/resources/src/startup.js)) We use the same approach in VisualEditor already. A few User-Agent may still be hardcoded as supplementary filter (for browsers we know pretend to support features, but don't; or for features harder to detect).### Reasons It will give us confidence and stability into ensuring the runtime has the methods that we require.Converting to a feature test would: * ... shrink this critical code path (T127328). * ... make it more maintainable. * ... give the blacklist a lot more meaning. Allowing us to confidently use features without conditionals or theoretical fallbacks. * ... older versions of browsers that we no longer support will automatically fall in the right category. A small set of feature tests would effectively cut Grade C the same way as our user agent sniffer. It would also make it easier to, in the future, It would also make it easier to in the future turn off javascript for non-ES5 browsers by simply adding a one line feature test for it.-line feature test for it. This article about BBC web developers "cutting the mustard" reminded me of the important of feature detection: http://responsivenews.co.uk/post/18948466399/cutting-the-mustard