Are we really supposed to support all versions of Safari since 5.1? It's a bit old.
PHP 7.2 Compatibility
Is PHP 7.2.0 compatible with MediaWiki? That is the current stable version of PHP (as of 1/1/2018).
Currently, MW1.30(current stable version) is not yet fully compatible with PHP 7.2. PHP will be issued a warning level error. If you disabled display_error in php.ini, there should not be any big problems.
Chrome on mobile
I see the browser support matrix for mobile hast two columns named "Chrome", one stating that version 48+, the other stating that version 43+ is supported. This either was mistyped and one column needs to be removed or it needs clarification what the distinction here is. @Jdlrobson, you've added this in https://www.mediawiki.org/w/index.php?title=Compatibility&diff=2416446&oldid=2415223, can you help with that?
Is there MariaDB support? If yes, can it be added to the compatibility table? Thanks.
Now that the Wikimedia Foundation uses MariaDB on it's cluster, does the table need to be updated?
Is there a timeline for how far into the future MySQL support will continue? In other words, as the MariaDB and MySQL projects diverge is there a point in time that Mediawiki might be expected to drop official support for MySQL?
The Future of HHVM. It seems that HHVM is going to diverge from PHP to Hack; so perhaps it time to migrate to PHP 7.1 (as the only version that is going to be maintained long enough).
There's an ongoing discussion on wikitech-l about this.
Update A-grade browser support to reflect jQuery 3 on Opera
Updated the page to reflect the current state correctly again.
Following up a conversation with @Nikerabbit on CX SVG updates, we've identified, that out-of-the-box jQuery 3 is not supporting Opera 12.x any longer. We should update the matrix accordingly.
Go for it. :)
Process to change compatibility
I have at least one question based on the discussions related to HTML in phabricator: What is the process by which we decide to change MediaWiki's compatibility? Is it well-defined? Does it need calling out on this page?
Perhaps update the php table for MW 1.29 php 7.1 compatibility?
Updated assuming that 1.29 now fully plays with 7.1. The related task is fully messed since it cheerfully mixes the issue for core with the issue for extension.
I was asked about the demographics of no-JS users, and didn't have a great or solid answer ("Corporate intranet users? old browser users? users avoiding banner ads?"), so went looking. Here's what I found:
- Corporate proxy disabled it - (for intranet security)
- For privacy - (preventing some tracking/advertising systems, usually coupled with disabled-Cookies)
- For annoyance prevention - (to prevent things like animations, particularly for users who find these overwhelmingly distracting)
- For faster site downloading - (less to download (bytes))
- For faster browser rendering - (less to calculate (complexity))
- Other reasons for which users encounter the no-JS version
- lost connection mid-download - (especially mobile users, and unstable wifi users)
- en:NoScript and similar browser extensions
- Browser settings
- Connection proxy
- A browser that doesn't support it - (lynx, etc)
- 2010 - 1.6% average (2.06% in U.S., 0.26% in Brazil) (according to developer.yahoo.com)
- 2013 - 1.1% in U.K. (according to gds.blog.gov.uk
- 2014 - ???
- (newer stats, and other Reliablesources, would be appreciated. Statcounter doesn't yet reveal no-JS usage)
- Sources and good links
- en:Progressive enhancement
Let me know if I missed anything major/minor, or add it to the list :)
Thanks. I don't understand what "Other reasons that users encounter the no-JS version" means.
Mobile users apparently get this fairly often? The gov.uk link mentions it ("network errors, especially on mobile devices"), and I was told this directly by a WMF mobile dev.
Feel free to edit for clarity :)
Update A-grade browser support
Now that we've entered 2012 I'd like to update Compatibility#Browser with what we've basically been doing the last year already.
- Internet Explorer 6+
- Firefox 2.0+
- Safari 3 (WebKit 525)+
- Opera 10.0+
- Chrome 5.0+
New proposed browser support:
- Internet Explorer 6+
- Firefox 3.0+
- Safari 4 (WebKit 531)+
- Opera 10.0+
- Chrome 13.0+
We could go further and raise Firefox to 3.6 and Chrome to 15. However so far everything we've done happened to work during testing in those, so we might as well keep those in the compatibility until we have to do otherwise.
If there's no problem in keeping compatibility with them, I'd continue supporting them, until dropping provides a clear benefit.
Updating the document isn't going to break anything. I'm simply proposing to make it reflect, what afaik is, the status quo.
If most or all features work in those browsers, that's great. But that's not the same as being officially supported. It's not like things will be forced to break in those browsers, simply no systematic testing. Frontend features aren't been systematically been tested in Firefox 2, Safari 3 or older versions of Chrome right now, and haven't been in a long while.
It's not like people using browsers not matching this will get warnings of anything, nothing changes. Other than bugs reported for those browsers perhaps getting a lower priority, but then again, those bugs probably already are..
For what it's worth: jQuery is currently officially supported in "IE 6.0+, FF 3.6+, Safari 5.0+, Opera, Chrome". So for all we know certain jQuery features may already be broken in older browsers, and since we're using jQuery..
We should be talking of dropping IE6; it's over ten years old and has been retarding the whole internet for years. Ensure that they get the content and don't sweat most styling issues.
Our standard is any browser with more than %1 usage on the wikimedia cluster just close to full support as possible (with some degradations allowed), IE6 is/was at ~%2.22 usage the other night when I checked.
IE6 is especially deficient, as I expect you know. It is undeniable that these deficiencies hold back good improvements for the other ~98%. The deployment of class="hlist" on en:wp (w:en:WP:HLIST, horizontal list styling in navboxes) is a good example. IE6 support is via js, which bogs down on larger pages (it's supporting IE7&8, too). It's quite possible that IE6 will linger indefinitely at something a hair above 1%. Mostly it's pirated copies in China on XP. Most people in the developing world are jumping at the various modern-and-free browsers. That 1% set in stone? Oh, and thanks for the 2.22% data point. Good to know.
If the English Wikipedia doesn't want to support IE6, that's up to them. They can make the decision to drop hlist support for IE6 if it's so much of a hassle.
You probably should dig deeper in the details: according to Microsoft, IE6 has 6% of the total market share, but below 1% everywhere except Asia:
http://www.ie6countdown.com/ (official Microsoft site)
I agree we don't need to update this chart unless there is a bug we can't fix in an older browser. As long as it works we can officially support it.
Because of a recent change in support by jQuery (which ResourceLoader and thus most enhanced functionality depends on), I have updated the page and split it between "Grade A" (where everything should work), and "Grade B" (which we will maintain until either we can't (impossible bug in an old browser), or we don't have to (< 0.1% wmf usage stats). Right now the only difference in "Grade B" is support for jQuery (Firefox 2 > Firefox 3.6, Safari 3 > Safari 4)