Just as a note: you can write CSS for IE and then use @support(display:grid) to provide better layout for modern browsers. You just cannot use @supports not (display:grid) because of limited @supports support 😉. So IE rules first and other browsers later with @support.

@Nux right and we're doing that :) which is why I'm a little puzzled about the idea of supporting grade C. Good modern frontend development patterns surely make this a non-issue.

I think we also need a better definition of Grade C. Currently the definition is "In the front-end this means content is presented in a readable manner, and content and account actions can be performed, but these browsers do not receive JavaScript features.". My interepretation of this was that only skin developers (and stylers of parser content) need to be concerned about this. A shared understanding of what we're trying to achieve here seems like a good place to start here. I don't think anyone involved in product development is seriously thinking that their features should be working in any of the grade C browsers, but in Desktop Improvements (Vector 2022) we've been striving to make sure at least the article content is available. Is Grade C not purely about reading content? Why would others need to care about this?

In theory we could hide all Codex components and just show the title of the page and the article text there and deem that acceptable.

I'm not clear what "account actions can be performed," and whether this current definition still holds. For example, we could drop support for logged in users if we felt the need.

Personally I would drop the classification of Grade C and grade C and instead replace this with a line "Browsers that are not in grade A should get read-only experience of Wikipedia in that they can read articles, follow links and perform a basic search function via an HTML form. There should be no expectation that any other features work in these browsers."

I think when you have a button that is only an icon and nothing else is displayed instead in IE then this is not an acceptable degradation (for me personally). The problem is in Vector sometimes you only have icons. But I think if you could display labels that are hidden and ditch icons for IE that would satisfy "content is presented in a readable manner, and content and account actions can be performed". Not sure about codex, but when you remove all classes from links in top menu it just works. So maybe in some case just make an empty css for IE? (e.g. surround everything with @supports)

@Nux I agree that it's good to think about graceful degradation strategies here – maybe one way to cushion the blow of ending Grade C support for IE 11 would be to ensure that a basic but usable fallback experience still gets shipped for users of that browser – some kind of bare-bones skin or stylesheet. I'm not sure of @supports queries can do this or not.

In T288287#8809065, @Jdlrobson wrote:

I think we also need a better definition of Grade C. Currently the definition is "In the front-end this means content is presented in a readable manner, and content and account actions can be performed, but these browsers do not receive JavaScript features". My interepretation of this was that only skin developers (and stylers of parser content) need to be concerned about this. […]

The skin indeed plays an important in faccilitating the underlying base layer the site (Grade C). Without it, nothing else can even attempt to deliver anything of on-screen. In the same sense that the skin is the lowest-common denominator for the HTML/CSS layer, so too are the ResourceLoader startup+base modules the lowest-common denominator for JS-based enhancements. They set the foundation for everything else.

However, these responsibilities don't end there. On the contrary. The Base/Modern layering is essential to our overall system architecture, and is at the basis of all APIs and interfaces. There exist virtually nothing on our platform that doesn't start with the Base experience first. That's the only way to get to a fast, accessible, discoverable, archivable, and equitable experience. And given our platform has optimised for precisely that for 20 years, it is also in practice the cheapest way to implement something. Extend the basic SpecialPage and HTMLForm interfaces, wire up some declarative arrays specifying what goes where, and pipe it to an service class or other API, and you're done. It renders fast and is available to everyone. "Everyone" here. means Grade C. To quote Frontend practices § Getting started "We are all the 1%, at different times." — where time refers to both ocasions but also portions of time within a given experience. Every pageview, even those on a $3000 MacBook Pro with fibre-optic Internet at Apple Park in California, start visually with Grade C first.

Personally I would […] replace this with a line "Browsers that are not in grade A should get read-only experience of Wikipedia in that they can read articles, follow links and perform a basic search function via an HTML form. There should be no expectation that any other features work in these browsers."

I think this sets up a counter-productive incentive toward framing the experiences as being separate, when they are not. And implying or justifying a cost trade-off not supported by facts.

It is extremely expensive and wasteful to frame a JavaScript-based approach as faster to market and to add back the lower bits as you go. There's cases where WMF and others have tried, but we've yet to see the first success story. It's faster to market to start with the basics, every time. And it leads to more searchable, discoverable, linkable/shareable (URLs) and equitable and faster outcomes when you instead "layer on" feature-specific code if/when there is resources to do so. When you start with a SpecialPage or HTMLForm, you've got basically no code to write, no (unit) tests to write.

The notion that I'm writing against is understandable though. For a full decade the industry has favoured metrics and frameworks that scale rather poorly, which practice acted mostly a way to ensure small-mid size companies can't compete with big tech as they're too busy chasing their own tail with a framework that can't fit their budget no matter how hard they try.

Speaking specifically about IE11 here:

In T288287#8808398, @Nux wrote:

Just as a note: you can write CSS for IE and then use @support(display:grid) to provide better layout for modern browsers. You just cannot use @supports not (display:grid) because of limited @supports support 😉. So IE rules first and other browsers later with @support.

This is easy to do on a small scale, but starts to add significant complexity beyond that. Here are a couple of examples from the component library in Codex, where we already don't support IE11 for Vue components but would need to for CSS-only, no-JS components if IE11 remains in grade C.

For no-JS icons inside buttons, we implemented a Less mixin that applies the icon SVG as a mask-image. This allows us to dynamically change the color of the icon when the user interacts with the button by changing the background-color, keeping it in sync with the text color. For browsers that do not support mask-image (e.g. Firefox < 53), we simply apply a black or white background-image depending on which has better contrast.

This currently does not work in IE11 because we used @supports not for the fallback code. This patch demonstrates the code needed to implement the fallback as default, then undo those styles in the @supports block. 20 extra lines of code in an already complex mixin solely to support IE11. This may not seem like a lot, but every bit of added complexity makes the library harder to build and maintain.

A larger issue is flexbox. We currently use it throughout Codex, and to ensure that all no-JS components work in IE11, we would need to test all components there and write fallback styles as default for anything broken in IE11, then undo those styles for all other browsers. As a small team trying to support a Wikimedia-movement-wide library, this becomes unwieldy. It's also an additional burden to new Codex developers, and we want and need to enable more contributors.

Of course, we can do all this if we decide it's worth it—I just ask that we weigh the costs and benefits.

For no-JS icons inside buttons, we implemented a Less mixin that applies the icon SVG as a mask-image. This allows us to dynamically change the color of the icon when the user interacts with the button by changing the background-color, keeping it in sync with the text color. For browsers that do not support mask-image (e.g. Firefox < 53), we simply apply a black or white background-image depending on which has better contrast.

Sorry, but immediately when I started reading this I heard "a11y only color" in my head 🙃. Sounds like a problem with: https://www.w3.org/WAI/WCAG21/Understanding/use-of-color.html
If the change of state is important then it shouldn't be done by using color (due to a11y). If it is not important then I would say adding support for IE (or FF on XP) is also not important.

A larger issue is flexbox. We currently use it throughout Codex, and to ensure that all no-JS components work in IE11, we would need to test all components there and write fallback styles as default for anything broken in IE11, then undo those styles for all other browsers. As a small team trying to support a Wikimedia-movement-wide library, this becomes unwieldy. It's also an additional burden to new Codex developers, and we want and need to enable more contributors.

I think since you're doing a component library it's more of a problem. You don't know the context of the components... I personally used flexbox long before my company dropped IE support and it was mostly fine. As long as you don't force the height of the elements, you should be fine (even without fallback). But since you're making a component library, I'm guessing that sometimes you have to force the dimensions of elements (or devs might).

Maybe you could replace @supports not with .notjs selector or similar? That should be more stable.

Is this really a proposal for changing https://www.mediawiki.org/wiki/Compatibility#Browsers ? As it is written now, it doesn't really make sense to remove a browser from Grade C. That would mean starting to serve Javascript to it again.

In T288287#8927172, @Tgr wrote:

Is this really a proposal for changing https://www.mediawiki.org/wiki/Compatibility#Browsers ? As it is written now, it doesn't really make sense to remove a browser from Grade C. That would mean starting to serve Javascript to it again.

I see this task (and I think @Volker_E sees it the same way) as being about dropping the requirement that our CSS or markup supports IE11.

Maybe we need a new category in the compatibility table for "dead" or something similar – we don't serve JS to them, but we're also no longer concerned with the state of the no-JS interfaces they receive, no functionality is guaranteed any longer, and use is discouraged.

If we no longer had to support IE11 for our non-JS UIs, we could start relying on a lot of CSS / HTML features that we've been blocked from using for years, such as:

• Full flexbox API
• CSS Grid
• CSS custom properties (aka CSS Variables)
• <details> element
• @supports queries

One more thing – I don't that moving IE11 to Grade X would mean serving JS to it again. We would continue using the feature-detecting startup module to avoid sending any additional JS to this browser.

I think that our definition of "Grade C" could probably be clearer, but removing IE 11 from it still seems straightforward to me.

In T288287#8927172, @Tgr wrote:

As it is written now, it doesn't really make sense to remove a browser from Grade C. That would mean starting to serve Javascript to it again.

In T288287#8933124, @egardner wrote:

I think that our definition of "Grade C" could probably be clearer, but removing IE 11 from it still seems straightforward to me.

Indeed, removal from Grade C does involve serving JavaScript. Grade X covers "all other browsers".

We would start to include IE11, the same way that Grade X already includes all unlisted browsers (Brave, Iceweasel, DuckDuckGo, Netscape), and the same way that Grade X already includes other old browsers that we support current versions of (Chrome < 31, Firefox < 39, etc.). We don't serve JS to Netscape or Firefox 2, either!

Grade X is defined as the browser being "given a chance to have a modern experience", the same way that Grade A browsers are. This is important for neutrality and browser diversity, such that we don't actively prevent new browsers and modified browsers from accessing the full Wikipedia experience. In a sense we treat Netscape and Firefox 2 the same way we treat modern browsers like Vivaldi, UC Browser, Brave, DuckDuckGo, and Ungoogled Chromium. Plus, this way frontend devs have high-confidence in the environment through feature-test "proof", rather than the more brittle approach of user-agent sniffing.

Change 930278 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/core@master] Poc: Add client-grade-X class to grade X browsers

https://gerrit.wikimedia.org/r/930278

In the meeting we flagged the text "MediaWiki handles these browsers the same as Modern (Grade A) browsers and they are thus assumed to be capable. This principle provides various important benefits:" in https://www.mediawiki.org/wiki/Compatibility#Basic_(Grade_C) for Grade X as confusing. It should probably be removed or re-worded since Grade X browsers includes browsers served the grade C experience (but the text implies they all get Grade A).

As discussed we could also be more programmatic and deliberate around what experience Grade X users get: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/930278 (with the reflow as discussed) - it might be better for example for a skin to ship the print styles to such browsers than to give them an untested experience.

In T288287#8933388, @Krinkle wrote:

In T288287#8927172, @Tgr wrote:

As it is written now, it doesn't really make sense to remove a browser from Grade C. That would mean starting to serve Javascript to it again.

In T288287#8933124, @egardner wrote:

I think that our definition of "Grade C" could probably be clearer, but removing IE 11 from it still seems straightforward to me.

Indeed, removal from Grade C does involve serving JavaScript. Grade X covers "all other browsers".

You could be read as saying that we're serving JS to Grade X browsers regardless of them passing the compatibility check in startup.js. That would also include IE10 and IE8 and IE 6. That's not actually true, right?

My understanding is that the Grade A/C/X distinction is normative for us as Wikimedia, not descriptive or prescriptive of the code.
For Grade A, we're committing to making sure they get our fully functional JS experience, and we'll fix bugs in JS and styles.
For Grade C, we're committing to still making sure that a basic experience works for them. We're not committed to make sure they get our modern JS. They may or may not get served JS, depending on what features they actually support (as determined by the compatibility check in startup.js).
For Grade X, we're not committing to anything. They may or may not get served JS, depending on what features they actually support (as determined by the compatibility check in startup.js).

So in that sense, a dropping a browser from Grade C is mainly a change in our commitment, not one in code.

That being said, I do agree that the Grade C section on https://www.mediawiki.org/wiki/Compatibility#Basic_(Grade_C) is contradictingly phrased:

In the front-end this means content is presented in a readable manner, and content and account actions can be performed, but these browsers do not receive JavaScript features.

That sounds like none of the Grade C browsers are receiving JS, but that is false. 2019 Firefox probably is getting JS despite being Grade C.
This other paragraph from the same section seems more accurate to me:

Some browsers in this category are known to be incompatible with modern JavaScript (ES6) and therefore do not get JavaScript features. They are identified via a feature test suite in the startup module.

We should probably fix that ambiguity/contradiction, but since https://www.mediawiki.org/wiki/Compatibility feels like almost legal policy, I'm hesitant to be bold and make editorial changes to it.

In T288287#8933762, @Michael wrote:

You could be read as saying that we're serving JS to Grade X browsers regardless of them passing the compatibility check in startup.js. That would also include IE10 and IE8 and IE 6. That's not actually true, right?

You're right. The compatibility check in startup.js is based on feature detection (there used to be a disallow list of specific browsers based on navigator.userAgent, but that was removed as part of T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)).

My understanding is that the Grade A/C/X distinction is normative for us as Wikimedia, not descriptive or prescriptive of the code.
For Grade A, we're committing to making sure they get our fully functional JS experience, and we'll fix bugs in JS and styles.
For Grade C, we're committing to still making sure that a basic experience works for them. We're not committed to make sure they get our modern JS. They may or may not get served JS, depending on what features they actually support (as determined by the compatibility check in startup.js).
For Grade X, we're not committing to anything. They may or may not get served JS, depending on what features they actually support (as determined by the compatibility check in startup.js).

I think that is correct. Specifically, we commit to making the compat checks pass in all Grade A browsers, and we make no commitment to whether they pass in Grade C or Grade X browsers.

So in that sense, a dropping a browser from Grade C is mainly a change in our commitment, not one in code.

That's exactly right. There are no code changes required for this task, except for changes to our stylelint and browserslist configs (which I will make subtasks for shortly).

That being said, I do agree that the Grade C section on https://www.mediawiki.org/wiki/Compatibility#Basic_(Grade_C) is contradictingly phrased:

In the front-end this means content is presented in a readable manner, and content and account actions can be performed, but these browsers do not receive JavaScript features.

That sounds like none of the Grade C browsers are receiving JS, but that is false. 2019 Firefox probably is getting JS despite being Grade C.

You're right, and I think there's a similar misunderstanding in how we tend to think about Grade C. I had been thinking about it as "Grade C browsers do not pass the compat checks", but that's not true. There's a similar misstatement/contradiction in startup.js itself:

* Browsers known to pass these checks get served our modern run-time (Grade A or Grade X):

but then it goes on to list Chrome 63 (released in Dec 2017) and Firefox 58 (Jan 2018) as browsers that pass the checks.

This other paragraph from the same section seems more accurate to me:

Some browsers in this category are known to be incompatible with modern JavaScript (ES6) and therefore do not get JavaScript features. They are identified via a feature test suite in the startup module.

We should probably fix that ambiguity/contradiction, but since https://www.mediawiki.org/wiki/Compatibility feels like almost legal policy, I'm hesitant to be bold and make editorial changes to it.

I think you're completely right, and nobody has complained on this task in the 8 days since you posted this comment, so I'm going to boldly change this on both the wiki page and in startup.js.

Change 932347 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] ResourceLoader: Clarify browser support comment in startup module

https://gerrit.wikimedia.org/r/932347

Wiki page updated: https://www.mediawiki.org/w/index.php?title=Compatibility&diff=5998603&oldid=5969103

Change 930278 abandoned by Jdlrobson:

[mediawiki/core@master] Poc: Add client-grade-X class to grade X browsers

Reason:

https://gerrit.wikimedia.org/r/930278

Change 932347 merged by jenkins-bot:

[mediawiki/core@master] ResourceLoader: Clarify browser support comment in startup module

https://gerrit.wikimedia.org/r/932347

I think that it's time for us to revisit this again.

We'd like to make a CSS-only version of our Accordion component available in Codex. This would necessitate using the HTML <details> element. This element is widely supported and delivers a crucial new ability to provide simple showing/hiding of content without the need for any JS (or hacky CSS).

I think that skin and extension authors would also find this element handy if they need to deliver more interactive interfaces to users without JS.

However, <details> is of course not supported by Internet Explorer. [1]

In the future there will be other native HTML elements like <dialog> that will allow us to deliver other rich features without additional JS. [2]

As long as we keep IE11 on the Basic Support list, our users will never be able to benefit from these features.

[1]: We'd also need to bump up the versions of FF and Edge on the basic support list in order to use <details>, but this task is about IE11 specifically

[2]: <dialog> is a little more futuristic and I don't think it's ready for adoption here yet, but over time we should be able to rely more and more on native HTML functionality

I guess my question here would be what does the CSS-only component look like for the Accordion in IE11? E.g. does it degrade to something that meets the criteria of being functional e.g. is the content inside the accordion visible? Are the links clickable? If the issue is only that it doesn't behave like an accordion I don't see why that would be a problem.

For context the details element itself seems to degrade quite nicely on https://design-system.service.gov.uk/components/details/

In modern browser:

Our demo site kind of falls apart in IE11, but it looks like the basic content is visible.

So this:

Becomes:

In T288287#9457154, @egardner wrote:

Our demo site kind of falls apart in IE11, but it looks like the basic content is visible.

So this:

Becomes:

I'd say that's acceptable within the definition of Grade C and therefore does not need to block T338184.

From https://www.mediawiki.org/wiki/Compatibility#Grade_C:

In the front-end this means content is presented in a readable manner, and content and account actions can be performed, but JavaScript features may or may not work.

We should still test in the other older Grade C browsers that also don't support <details> to confirm the behavior is equivalent.

I'd say that's acceptable within the definition of Grade C and therefore does not need to block T338184.

+1

FWIW I don't think Codex should be worrying about CSS component support. Instead it should just document the support it provides e.g. "This component degrades to text in browsers that do not support the details element". I think that decision itself should be deferred to the actual products using Codex. For example, if web team want to use the CSS component for accordion, we'll make a decision about browser support then separate from any global one. Making a decision for a web UI using CSS components that requires JavaScript to actually function VS article content using an accordion to provide important information are two very different use cases and context is important.

On a related topic, I still think we lack a shared definition at WMF about what supporting grade C actually means. Given "The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally." I would say "disseminate it effectively and globally." is the main thing that needs to be considered here and something we should aspire to. e.g. does the component degrade in such a way that its content can be read? [which in this case it does!]

FWIW Vector 2022 support in IE11 looks like this:

The main issues are:

• alignment of menu items in the top right is broken
• full screen (no CSS grid)

(Those are okay from my perspective as the content is readable.)

In T288287#9457183, @Jdlrobson wrote:

On a related topic, I still think we lack a shared definition at WMF about what supporting grade C actually means.

That seems to be the key issue here. Right now MediaWiki core has have stylelint configured so that it prohibits the use of any CSS features that are not supported by all grade C browsers. This means that it warns for things like @supports (not supported in IE11), position: sticky (IE11, Edge 12-15, Chrome 31-55, Opera 18-41) and tab-size (IE11, Edge 12-18). We override this rule in some places (about 50 globally), but as a rule you can't write CSS that doesn't work in IE11 without justification. This stylelint rule seems to me to be the main way in which Grade C support manifests for developers. Analogously, eslint is configured to enforce Grade A browser compatibility, so the rough rule the tools enforce is that JavaScript needs to work in Grade A browsers and CSS needs to work in Grade C browsers. The reality is a bit more nuanced: Grade C support is only required for CSS that can be loaded when JS is not available; for CSS that is only loaded in combination with JS, only Grade A support is required.

Note that our main skins (Vector and Minerva) have configured stylelint differently, such that it's based on Grade A browsers instead of Grade C. I don't know why this was done, but maybe if we had a more realistic Grade C target that excluded IE11 and some of the really old Edge Legacy versions (and if we used per-file or per-directory overrides to treat CSS files that only load with JS differently than CSS files that can load without JS), we could have our tools enforce our browser support targets without needing a lot of overrides.

Given "The mission of the Wikimedia Foundation is to empower and engage people around the world to collect and develop educational content under a free license or in the public domain, and to disseminate it effectively and globally." I would say "disseminate it effectively and globally." is the main thing that needs to be considered here and something we should aspire to. e.g. does the component degrade in such a way that its content can be read? [which in this case it does!]

I agree that "the content can be read" is what we should strive for. My view is that if we drop a browser from Grade C, that means we're no longer making an effort to ensure that the web site works and the content can be read in that browser. The functionality of the web site and the ability to read content in that browser will then likely degrade over time, as new code is introduced that uses features not supported by that browser. This task proposes doing that for IE11, and I think that's fine in light of how low its usage has gotten.

jforrester opened https://gitlab.wikimedia.org/repos/ci-tools/browserslist-config-wikimedia/-/merge_requests/11

Update basic standards for 2024

volker-e merged https://gitlab.wikimedia.org/repos/ci-tools/browserslist-config-wikimedia/-/merge_requests/11

Update basic standards for 2024

This was announced in https://meta.wikimedia.org/wiki/Tech/News/2024/27