On 26 Jul 2014, at 22:32, Steven Walling <steven.walling(a)gmail.com> wrote:
This seems really reasonable.
Are we still agreed that Grade A means anything over 1% of readership? If
so, we should reconfirm what our browser share is really like, because last
time I checked, IE6 was less than 1% of total and thus eligible for
dropping from Grade A now and forever (he says with great
1% was never "the figure" as far as I know (certainly not for Grade A).
For the longest time most documents and practices used the 0.01% mark (that
is, before MediaWiki 1.17; predating ResourceLoader, jQuery and most
front-end features). During these years it basically meant we didn't
support browsers with less than 0.01% share (e.g. may be broken, insecure,
or otherwise less usable). Support for the rest was cheap considering the
relatively primitive nature of our front-end at the time.
After MediaWiki 1.17 we started to distinguish between "support" (site is
usable and readable) and "feature rich". It was OK to implement features
that would only be available for newer browsers. We disabled resource
delivery for IE 4 and 5 as their engines are not adequate and made it
technically infeasible to implement essentials. As they still had enough
traffic we didn't want them getting a broken page, so came to be a
Around this same time the figure seemed to have been changed from 0.01% to
mode (Grade A and B) 0.1% applied to Grade B, *not Grade A*. Meaning our
aim was to dedicate resources to support any browser with 0.1% or more
traffic. Thus guaranteeing that 99.9% of our users would have an experience
less than even 0.1% traffic and were neither Grade A or B. This provided
them a a better fallback (though no official support), so that e.g. IE4,
IE5 and ancient Netscape users wouldn't be bothered with loads of scripts
that won't work. Instead they get a relatively lightweight page to try
their best on.
Here minimal support meant 1) Grade B feature support or blacklist in
stylesheets work in this browser, 3) ensure our backend infrastructure is
compatible with those browsers (url schemas, critical HTTP features,
security, image formats etc.)
Note how then, IE6-8 were considered Grade B, not A.
And remember that both 0.01% and 0.1% are both pretty big at our scale. Our
efforts aren't driven by how profitable that 0.1% is but by our mission
statement. For a browser to be truly unsupported takes a lot of moral
consideration (e.g. if the server may use a protocol the browser doesn't
support they might get nothing at all).
After 2010 we kind of started to forgot about all this. Few updates to the
charts and little enforcement of it.
Regardless of what the page said, we never actually distinguished between
Grade A and B. Both were given the same treatment and care. We never had
any features that only work in Grade A. We did optimise for Grade A, but no
exclusive user facing features (except for VisualEditor and other features
that adopted a different browser support matrix).
While I've personally tried to keep minimal browser support somewhat in
check, the document was simply no longer accurate and focussed too much on
individual browser versions and not on the actual policy. Thus we archived
it last year. Yesterday I've published a more refined version of this
policy at https://www.mediawiki.org/wiki/Compatibility#Browsers
mostly current practices, factual state of the software (we have a startup
module, we do blacklist browsers, our basic layout was made to work in
IE6/FF2 etc.) and status quo (to my knowledge all front-end code in core
supports IE6 and I'm quite certain code not working in IE6 would not be
approved by anyone having mediawiki-core merge authority).
Since Grade B never ended up being recognised in any way by the software,
I've kept that out. And the previously undocumented Grade C represents
browsers we are interested in supporting due to their traffic but only via