On Fri, Jul 5, 2013 at 3:07 PM, Matthew Flaschen <mflaschen(a)wikimedia.org>wrote;wrote:
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