I also think that a notice should be put ontop of mediawiki to say that internet explorer 6 is no longer supported and ask them to upgrade to internet explorer 8.

On Friday, 25 July 2014, 0:14, Thomas Mulhall thomasmulhall410@yahoo.com wrote:

We had a discussion about internet explorer 6 and someone said that we should start to remove some code but keep codes that let internet explorer 6 users edit and view the page.

On Thursday, 24 July 2014, 22:03, Thomas Mulhall thomasmulhall410@yahoo.com wrote:

Thanks.

On Thursday, 24 July 2014, 21:49, Sumana Harihareswara sumanah@wikimedia.org wrote:

Replying with a subject line. :) Good luck Thomas.

Sumana Harihareswara Senior Technical Writer Wikimedia Foundation

On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall thomasmulhall410@yahoo.com wrote:

Hi should we upgrade jquery ui to version 1.10.4. even though we recently upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The main difference is it removes internet explorer 6 support which as long as internet explorer 6 users can edit and view the page it wont matter to them. here is the changelog jqueryui.com/changelog/1.10.0/

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Fri, Jul 25, 2014 at 4:56 PM, Max Semenik maxsem.wiki@gmail.com wrote:

Why? Everyone who was able to upgrade already did that. The remainder are either users with really crappy machines or corporate slaves who can't decide anything themselves. What will you achieve by annoying them?

+2. I understand the desire of front end developers to be freed of the constraints of supporting an ancient platform, but some of us old guys figured this out back in the heyday of the first dotcom bubble. The answer is progressive enhancement. It turns out that this is good for everyone because the same techniques that allow supporting a functional but less highly interactive frontend experience for older desktop platforms led to responsive designs that support the ever expanding "mobile" platforms. The number one business of the movement is the distribution of knowledge. We should seek to reach the widest audience possible with the least restrictions on bandwidth, screen resolution and device capability. Yes, of course we should push ourselves to present the content provided by our hard working editors in a platform that is responsive and enticing to the upscale consumers of the modern internet, but we should never forget that the truly important deliverable is the content itself. Wikipedia and the sister projects should be readable and editable from a VT100 terminal connected to a packet radio network bounced off of a satellite with ridiculous latency to reach our most far flung caching center. If they can speak HTTP and somehow get a request packet to us, we must provide the knowledge the consumers seek.

Bryan (not responding as an employee of the WMF, but as a geek who wants to help people who want to learn and share)

Maybe this can be done once 1.25 is released in alpha or 1.26.

On Saturday, 26 July 2014, 11:03, Krinkle krinklemail@gmail.com wrote:

Before we get all up in an IE6 debate, imho the more important difference is that jQuery UI 1.10 drops support for the (now deprecated) jQuery 1.8 API.[2]

Considering we only recently upgraded jQuery UI from 1.8 to 1.9, and that that upgrade was the first of its kind since the introduction of the framework in MediaWiki 1.16, we should give it a fair amount of time to allow everyone a fair opportunity to know about this breaking change.

Similar to how MediaWiki maintains releases, jQuery UI continues to support and maintain 1.9.[1] If there's important security or bug fixes, they'll make a minor release that we can upgrade to without breaking anything. So while 1.10 is "newer" than 1.9, it is still totally supported and there's no pressure to upgrade from that angle. (There's pressure from other angles but that's another topic.)

For those aware of the fact that jQuery UI 1.10 is not the latest version (1.11 is, released last month), the 1.11 release is interesting because, like jQuery UI 1.10, it also dropped support for a major browser (IE7).[3] So we'll probably want to upgrade to 1.10 first. Aside from browser support, our code is distributed so we can only upgrade to a version that drops support for an API after we first upgrade to a version that provides the new API.[4]

— Krinkle

[1] http://jqueryui.com/download/%C2%A0and their source repository continues   to maintain jQuery UI 1.11.x, 1.10.x and 1.9.x [2] http://blog.jqueryui.com/2013/01/jquery-ui-1-10-0/ [3] http://blog.jqueryui.com/2014/06/jquery-ui-1-11-0/ [4] http://jqueryui.com/upgrade-guide/1.10/

On 24 Jul 2014, at 22:03, Thomas Mulhall thomasmulhall410@yahoo.com wrote:

Thanks.

On Thursday, 24 July 2014, 21:49, Sumana Harihareswara sumanah@wikimedia.org wrote:

Replying with a subject line. :) Good luck Thomas.

Sumana Harihareswara Senior Technical Writer Wikimedia Foundation

On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall thomasmulhall410@yahoo.com wrote:

Hi should we upgrade jquery ui to version 1.10.4. even though we recently upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25. The main difference is it removes internet explorer 6 support which as long as internet explorer 6 users can edit and view the page it wont matter to them. here is the changelog jqueryui.com/changelog/1.10.0/

---

...

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On Sat, Jul 26, 2014 at 9:54 AM, Krinkle krinklemail@gmail.com wrote:

As for IE6, that roadmap is quite simple in my opinion.

At this point MediaWiki already degrades gracefully in older browsers in a number of different ways. We've put our cut off point for javascript execution in general at IE < 6 and Firefox < 4. And for stylesheets we also support IE6 for the basic layout (enough for text to be readable in a way that isn't distorted or hard to read).

In any browsers where we don't abort the javascript pipeline from the startup[1] module, there must be no fatal errors or uncaught exceptions due to browser support.

While a library doesn't have to throw an exception in an older browser per se, in case of jQuery UI it's quite simple. We can only upgrade to jQuery 1.10 when we drop IE6 support for Grade A. And when we do, IE6 will become javascriptless[1] and jQuery UI will no longer be relevant as problem in IE6.

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 antici.........pation.)

On Sun, Jul 27, 2014 at 2:25 AM, Krinkle krinklemail@gmail.com wrote:

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 the non-javascript mode.

Thanks, Timo - brilliant work as always.

I would like to make a case for moving more browsers into the grade C category. JavaScript's client-side execution means that being able to provide predictable user experiences is inherently dependent on client updates _with reasonable maintenance burden_. By shifting more browsers into JavaScript-less mode, we accomplish the following:

- Improve performance for low-end users since these JS engines are often slow.

- Significantly reduce the maintenance burden for modern user experience code.

- Reduce risks of security exploits targeting users running an outdated environment.

We could then also begin to treat JavaScript-less experience as a first class citizen in support and testing, which helps us serve low-end users better. If we take the grade C category seriously, we need to think more about testing these workflows and ensuring we give the best possible experience to those users.

IMO this should be based on both usage share and maintenance burden based on developer judgment. IE6-7 would be obvious candidates -- single platform browser, high maintenance burden to test for, etc.

Erik

...

I would like to make a case for moving more browsers into the grade C category.

Yes please. As a project that must live the test of time I think we should be focusing our energy on building for future browsers. Our main goal is to provide people knowledge which can be done without JavaScript. Older browsers hold us back in my opinion.

I would also support this, for similar, but slightly different reasons. I agree that we need to make sure that the project stands the test of time, and for that reason I think we need to make Grade C a first class citizen.

I think because of the relative ease of parsing and saving a javascriptless page, it stands the best chance of being accessible long into the future.

This would, of course, also allow us, as others have pointed out, to reduce our maintenance burden and focus on building the best experience that new browsers can provide.

Thank you, Derric Atzrott

\o/ what terrific news to wake up to! Derric I think we are in agreement on the way forward! You are not saying anything I disagree with :) On 6 Aug 2014 07:33, "Erik Moeller" erik@wikimedia.org wrote:

On Mon, Aug 4, 2014 at 5:36 PM, Derric Atzrott datzrott@alizeepathology.com wrote:

...

...

...

I would like to make a case for moving more browsers into the grade C category.

...

...

Yes please. As a project that must live the test of time I think we

should

...

...

be focusing our energy on building for future browsers. Our main goal

is to

...

...

provide people knowledge which can be done without JavaScript. Older browsers hold us back in my opinion.

...

I would also support this, for similar, but slightly different reasons.

I

...

agree that we need to make sure that the project stands the test of

time, and

...

for that reason I think we need to make Grade C a first class citizen.

OK. I've submitted a change to do this for MSIE6 for now. [1] It got merged quickly, but please update if I missed anything (I'll add release notes now). Provided there are no concerns with this, I'll send a note to wikitech-ambassadors@ soon, drafted here:

https://www.mediawiki.org/wiki/User:Eloquence/MSIE6

This case seems very obvious given the unpatched vulnerabilities and lack of official support; let's discuss additional browsers/categories of browsers on a case by case basis.

Timo, I also noticed that the definition of "grade C" in startup.js was inconsistent with what's on the mediawiki.org page so I updated it accordingly.

Thanks, Erik

[1] https://gerrit.wikimedia.org/r/#/c/152072/

Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Support can mean either depending on the context.

Most of this is uncontroversial, but I found it useful to think through and sum up.

From a platform perspective to support a browser means that the user experience is considered acceptable, tested against, and we're committed to keeping it that way (which may mean moving a browser or mediawiki feature from one Grade to another). Don't forget that there's a lot more to our platform than javascript execution!

Supporting users of browsers we provide a javascript-less experience still requires a lot of things to work; such as:

* Content delivery. (Can't require HTTP features that don't work, e.g. some sites require every user to be in a session with an ID and for new visitors they respond with an empty page that sets session cookies based and refreshes to display the real page, we couldn't do that if we want to support browsers without cookies or with cookies disabled.) * Enough styles for the page to be usable. (Let's say background-image were new in CSS3, then we couldn't exclusively have a design with white text on a background image without a fallback colour to ensure the text is readable without that image.) * HTML implementation. (Say a supported browser doesn't allow relative urls in a <form> action attribute, we'd have to make it an absolute url.) * Character encoding. (If certain unicode literals aren't interpreted properly, we may have to explicitly encode them.) * We'd commit to doing our best to keep their stuff secure (e.g. while we may patch against a browser-specific CSRF exploit for an unsupported browser out of the goodness of our hearts, we pretty much have to if it affects a supported browser).

All these areas and more do in fact have problems we account for, but I think we've been at it long enough that we've got these bases covered in MediaWiki and in our web servers and caching proxies. However as we keep introducing new backend code and iterate our infrastructure, we need to ensure we don't miss anything.

-- Timo

On 27 Jul 2014, at 18:42, Jon Robson jdlrobson@gmail.com wrote:

A few quick notes:

• we should be killing jQuery ui. not upgrading it :)
• progressive enhancement != supporting IE6. We should be doing this

anywhere. Personally I would be fine with giving IE6,7, even 8 and maybe 9 no JavaScript whatsoever and supporting them simply from simply a css perspective. People can edit and read without JavaScript.

• I think we should be careful when we say support. Does support meaning

any new features we write in JavaScript have to work on these platforms or does in mean they need to be usable? I'd say the latter. It sounds like the discussion is around supporting JS.. On 24 Jul 2014 13:49, "Sumana Harihareswara" sumanah@wikimedia.org wrote:

...

Replying with a subject line. :) Good luck Thomas.

Sumana Harihareswara Senior Technical Writer Wikimedia Foundation

On Thu, Jul 24, 2014 at 4:24 PM, Thomas Mulhall < thomasmulhall410@yahoo.com> wrote:

...

Hi should we upgrade jquery ui to version 1.10.4. even though we recently upgraded to version 1.9.2 we could upgrade to 1.10.4 in Mediawiki 1.25.

The

...

main difference is it removes internet explorer 6 support which as long

as

...

internet explorer 6 users can edit and view the page it wont matter to them. here is the changelog jqueryui.com/changelog/1.10.0/ _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

---

Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l