On Fri, Jul 5, 2013 at 3:07 PM, Matthew Flaschen mflaschen@wikimedia.orgwrote:

Yes, IE is particularly an issue for this, since it often requires a fair amount of specific work. However, our browser compatibility requirements in general are somewhat in limbo. James Forrester marked the guidelines at https://www.mediawiki.org/wiki/Compatibility#Browser historical, rightly pointing out they were somewhat unrealistic (they didn't reflect what people could afford the time to actually do).

Now, we need something to replace them. This might be a case for an RFC.

I'm reluctant to put a blanket policy on something like browser compatibility.

Browser compatibility really comes down to several separate things: * HTML/CSS/JavaScript feature support -- does the browser actually supply the things we need? * Bugginess -- do the browser features we make use of work as expected? * Feasibility of workaround -- can a little code fix it, or is there a fundamental limitation we're stuck with? (Crashing browsers are hard to work around except by disabling a feature, for instance...) * Cost/benefit of degrading/disabling the feature -- is the feature actually needed, or can folks ignore it or work around it?

These are going to balance out differently depending on the wiki feature, on the browser features it depends on, on what the feature does/is used for, and the relative ease of user workarounds like updating or using another browser.

In the specific case of VisualEditor, that project should have its own compatibility policy, which I would expect to be more stringent than the general read-the-text-on-the-wiki compatibility requirements (which accommodates all kinds of weird stuff like "no CSS support" and "JavaScript is disabled").

If we must set a blanket policy for MediaWiki, I think it should be pretty general, something like: * *current* release of all major browsers with 'evergreen' releases (Chrome, Firefox, Safari) * a chosen *subset* of major versions of IE * a clear expectation that some advanced features won't work with some versions of some browsers, and a sane policy for acceptable fallbacks?

Fallback examples: * VisualEditor -> editable source with preview button * drag-n-drop photo upload -> upload photo by clicking on a button * video -> still photo(s) * 3d rotating molecule viewer -> still photo of molecule * GPS -> geo-IP lookup * round corners -> square corners

-- brion

On 7/6/13 12:44 AM, Brion Vibber wrote:

If we must set a blanket policy for MediaWiki, I think it should be pretty general, something like:

• *current* release of all major browsers with 'evergreen' releases

(Chrome, Firefox, Safari)

• a chosen *subset* of major versions of IE
• a clear expectation that some advanced features won't work with some

versions of some browsers, and a sane policy for acceptable fallbacks?

Safari is a bit complex, because Apple forks stable branches for different versions of OS X, so it's not quite an evergreen browser. *But* these stable branches sometimes have significant back-end rendering functionality quietly backported into their point releases. That can make assuming the latest version of the rendering engine is everywhere close to correct, but not always. The currently maintained branches are 5.1.x (OS X 10.6) and 6.x (OS X 10.7, 10.8). The 5.0.x branch (OS X 10.5) is definitely on an older rendering engine, since it hasn't had a point release since 2011; its market share is declining but still has around 10% of Safari users.

-Mark