⚓ T288287 Remove IE11 from Basic support ("Grade C")
Page Menu
Phabricator
Create Task
Maniphest
T288287
Remove IE11 from Basic support ("Grade C")
Closed, Resolved
Public
Actions
Edit Task
Edit Related Tasks...
Create Subtask
Edit Parent Tasks
Edit Subtasks
Merge Duplicates In
Close As Duplicate
Edit Related Objects...
Edit Commits
Edit Mocks
Mute Notifications
Protect as security issue
Assigned To
Volker_E
Authored By
Volker_E
Aug 5 2021, 8:12 PM
2021-08-05 20:12:34 (UTC+0)
Tags
Browser-Support-Internet-Explorer
(IE11)
MediaWiki-extensions-General
(Backlog)
MediaWiki-General
(Backlog)
CSS
(Documentation)
Front-end Modernization
(Following)
MW-1.41-notes (1.41.0-wmf.15; 2023-06-27)
Design-System-Team
(Up Next)
User-notice-archive
(Backlog)
Referenced Files
F41667913: Screenshot 2024-01-12 at 10.25.20 AM.png
Jan 12 2024, 7:38 PM
2024-01-12 19:38:33 (UTC+0)
F41667968: Screenshot 2024-01-12 at 10.56.00 AM.png
Jan 12 2024, 7:06 PM
2024-01-12 19:06:06 (UTC+0)
F41667971: Screenshot 2024-01-12 at 10.57.35 AM.png
Jan 12 2024, 7:06 PM
2024-01-12 19:06:06 (UTC+0)
F41667923: Screenshot 2024-01-12 at 10.28.22 AM.png
Jan 12 2024, 6:36 PM
2024-01-12 18:36:10 (UTC+0)
F41667925: Screenshot 2024-01-12 at 10.28.33 AM.png
Jan 12 2024, 6:36 PM
2024-01-12 18:36:10 (UTC+0)
F36963913: obraz.png
Apr 26 2023, 10:25 PM
2023-04-26 22:25:09 (UTC+0)
F34997398: screen_recording_2022-03-08_at_3.31.19_pm.mov.gif
Mar 10 2022, 5:11 PM
2022-03-10 17:11:24 (UTC+0)
Subscribers
Aklapper
AnneT
Base
Catrope
CCiufo-WMF
DAbad
Daimona
View All 30 Subscribers
Description
Summary
Remove IE11 from basic support.
Compatibility policy:
Affected components:
MediaWiki core, skins and extensions
. Wikimedia Foundation libraries like
Codex
and
OOUI
Update 2024-05-22:
The
compatibility template has been updated
to reflect the outlined support changes.
Motivation
Improve the user experience by making pages load slightly faster and use less bandwidth, because we'd send less CSS code down the wire.
Take away maintenance-burden of writing fallback CSS for newer CSS features not supported in IE11. The effort spent in writing workarounds and addressing specific browser code is a waste of our limited resources.
Unlock use of newer CSS features that do not have a fallback and thus cannot be safely used today.
Statistics
Superset (Wikimedia Foundation login only)
2022:
“~0.1%, down from ~0.5% at the start of 2022, and ~1.0% at the start of 2021.” –
T288287#8617086
2023:
T331463: IE11 User and Traffic Analysis update 2023
analytics.wikimedia.org
Development abilities to gain without IE11
Full list at caniuse
. Excerpt:
display: flex
, Full Flexbox API; removal of pre-standard Flexbox implementation (bytes and pain saved) and only standard syntax support
calc()
as CSS unit value allowed
@supports
feature queries able to be used unrestrictedly
CSS custom properties (aka CSS Variables)


element
TTF/OTF web font support
Note that custom properties aka CSS vars are not only blocked by IE11, but it's with 0.51% globally according to caniuse, the biggest of the remainders (Edge 12-15)
Acceptance criteria
Update
to remove IE11 from Basic support (Grade C)
T340172: Update browserslist-config-wikimedia to remove IE11 from the basic list
T340173: Release new versions of browserslist-config-wikimedia and stylelint-config-wikimedia with IE11 removed
Post to
Tech/News
(pending)
Post to
Technical Community Newsletter
Details
Related Changes in Gerrit:
Subject
Repo
Branch
Lines +/-
ResourceLoader: Clarify browser support comment in startup module
mediawiki/core
master
+4
-1
Poc: Add client-grade-X class to grade X browsers
mediawiki/core
master
+19
-0
Customize query in gerrit
Related Changes in GitLab:
Title
Reference
Author
Source Branch
Dest Branch
Update basic supported browsers for 2024
repos/ci-tools/browserslist-config-wikimedia!11
jforrester
T288287
main
Customize query in GitLab
Related Objects
Search...
Task Graph
Mentions
Duplicates
Status
Subtype
Assigned
Task
Open
None
T333394
Vector 2022 should use details element instead of checkbox hack (IE11) for better accessibility and to fix issues with hover states on language button
Resolved
Volker_E
T288287
Remove IE11 from Basic support ("Grade C")
Resolved
Jdforrester-WMF
T178356
Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)
Resolved
Catrope
T272104
Allow modules to opt-in to ES6 syntax support
Resolved
Catrope
T272882
Upgrade ResourceLoader JS minifier to support ES6
Resolved
Catrope
T277085
Add support for ES6 client code to eslint-config-wikimedia
Resolved
Jdforrester-WMF
T333354
Announce Grade A JavaScript requirement rising from ES5 to ES6
Duplicate
None
T237688
Raise MW JS requirement to include ES6 Promise (drop IE11, Safari 5-6, and Android 4.1-4.3)
Resolved
Krinkle
T284935
OOjs + ES6
Resolved
Krinkle
T96640
Remove reliance on class static properties that are reserved in JavaScript
Resolved
ldelench_wmf
T303325
IE11 User and Traffic Analysis
Resolved
CCiufo-WMF
T332716
Communicate intention to remove IE11 from basic support
Resolved
Jdforrester-WMF
T340173
Release new versions of browserslist-config-wikimedia and stylelint-config-wikimedia with IE11 removed
Resolved
Volker_E
T340172
Update browserslist-config-wikimedia to remove IE11 from the basic list
Mentioned In
T423292: Wikimedia Hackathon 2026: Cool new things in JS + CSS
T333394: Vector 2022 should use details element instead of checkbox hack (IE11) for better accessibility and to fix issues with hover states on language button
T365759: Remove IE 11, Edge legacy 15-18, Firefox 39-48, Chrome 31-48 CSS hacks and workarounds in core, extensions and skins
T338184: Accordion: Add CSS-only version and update hover and active colors
T353173: [SPIKE] Investigate remaining work for IE11 deprecation
T283726: Align ResourceLoader's 'startup.js' feature check with updated modern browser list
T342267: Investigate surprising "10% Other" portion of Analytics Browsers report
T340172: Update browserslist-config-wikimedia to remove IE11 from the basic list
T326665: Design and build Accordion component (MVP)
T335387: CSS Components on IE11: Icons are not displayed
T334235: Update VideoJS player to 8+ version
T332716: Communicate intention to remove IE11 from basic support
T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)
T309951: Script error occurs when loading Wikipedia page into MS Access Webbrowser control
T308867: Downgrade IE11 to Unknown Support
Mentioned Here
T338184: Accordion: Add CSS-only version and update hover and active colors
T340172: Update browserslist-config-wikimedia to remove IE11 from the basic list
T340173: Release new versions of browserslist-config-wikimedia and stylelint-config-wikimedia with IE11 removed
T335387: CSS Components on IE11: Icons are not displayed
T325105: [Epic] Add CSS-only versions of most Codex Vue components
T178356: Raise Grade A JavaScript requirement from ES5 (2009) to ES6 (2015)
T331463: IE11 User and Traffic Analysis update 2023
Duplicates Merged Here
T308867: Downgrade IE11 to Unknown Support
Event Timeline
There are a very large number of changes, so older changes are hidden.
Show Older Changes
egardner
removed a project:
Codex
Apr 26 2023, 4:26 PM
2023-04-26 16:26:55 (UTC+0)
egardner
mentioned this in
T335387: CSS Components on IE11: Icons are not displayed
Apr 26 2023, 4:29 PM
2023-04-26 16:29:27 (UTC+0)
Nux
subscribed.
Apr 26 2023, 4:45 PM
2023-04-26 16:45:45 (UTC+0)
Comment Actions
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
Jdlrobson
added a comment.
Apr 26 2023, 9:09 PM
2023-04-26 21:09:11 (UTC+0)
Comment Actions
@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
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."
egardner
added a subscriber:
kzimmerman
Apr 26 2023, 10:00 PM
2023-04-26 22:00:58 (UTC+0)
This comment was removed by
egardner
Nux
added a comment.
Apr 26 2023, 10:25 PM
2023-04-26 22:25:09 (UTC+0)
Comment Actions
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
egardner
added a comment.
Apr 26 2023, 10:46 PM
2023-04-26 22:46:56 (UTC+0)
Comment Actions
@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.
Krinkle
added a comment.
Edited
May 1 2023, 4:12 PM
2023-05-01 16:12:20 (UTC+0)
Comment Actions
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.
ldelench_wmf
moved this task from
Inbox
to
Needs Refinement
on the
Design-System-Team
board.
May 2 2023, 3:33 PM
2023-05-02 15:33:33 (UTC+0)
AnneT
added a comment.
May 11 2023, 10:43 PM
2023-05-11 22:43:03 (UTC+0)
Comment Actions
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.
Nux
added a comment.
May 11 2023, 11:38 PM
2023-05-11 23:38:31 (UTC+0)
Comment Actions
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:
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.
Aklapper
added a parent task:
T334235: Update VideoJS player to 8+ version
May 14 2023, 7:26 PM
2023-05-14 19:26:08 (UTC+0)
Izno
removed a parent task:
T334235: Update VideoJS player to 8+ version
May 22 2023, 9:14 PM
2023-05-22 21:14:57 (UTC+0)
egardner
mentioned this in
T326665: Design and build Accordion component (MVP)
May 24 2023, 4:19 PM
2023-05-24 16:19:29 (UTC+0)
Tgr
subscribed.
Jun 13 2023, 11:32 AM
2023-06-13 11:32:47 (UTC+0)
Comment Actions
Is this really a proposal for changing
? 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.
egardner
added a comment.
Edited
Jun 13 2023, 10:43 PM
2023-06-13 22:43:39 (UTC+0)
Comment Actions
In
T288287#8927172
@Tgr
wrote:
Is this really a proposal for changing
? 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)

element
@supports
queries
egardner
added a comment.
Jun 14 2023, 9:09 PM
2023-06-14 21:09:47 (UTC+0)
Comment Actions
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.
Krinkle
added a comment.
Jun 14 2023, 11:44 PM
2023-06-14 23:44:10 (UTC+0)
Comment Actions
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.
gerritbot
added a comment.
Jun 14 2023, 11:57 PM
2023-06-14 23:57:55 (UTC+0)
Comment Actions
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
gerritbot
added a project:
Patch-For-Review
Jun 14 2023, 11:57 PM
2023-06-14 23:57:56 (UTC+0)
Jdlrobson
added a comment.
Jun 14 2023, 11:59 PM
2023-06-14 23:59:05 (UTC+0)
Comment Actions
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
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:
(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.
Michael
added a comment.
Edited
Jun 15 2023, 8:12 AM
2023-06-15 08:12:06 (UTC+0)
Comment Actions
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
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
feels like almost legal policy, I'm hesitant to be bold and make editorial changes to it.
Catrope
added a comment.
Jun 22 2023, 11:13 PM
2023-06-22 23:13:58 (UTC+0)
Comment Actions
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
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
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.
gerritbot
added a comment.
Jun 22 2023, 11:33 PM
2023-06-22 23:33:57 (UTC+0)
Comment Actions
Change 932347 had a related patch set uploaded (by Catrope; author: Catrope):
[mediawiki/core@master] ResourceLoader: Clarify browser support comment in startup module
Catrope
added a comment.
Jun 22 2023, 11:34 PM
2023-06-22 23:34:07 (UTC+0)
Comment Actions
Wiki page updated:
Catrope
mentioned this in
T340172: Update browserslist-config-wikimedia to remove IE11 from the basic list
Jun 22 2023, 11:55 PM
2023-06-22 23:55:29 (UTC+0)
Catrope
updated the task description.
(Show Details)
Jun 23 2023, 12:06 AM
2023-06-23 00:06:54 (UTC+0)
gerritbot
added a comment.
Jun 23 2023, 5:50 PM
2023-06-23 17:50:59 (UTC+0)
Comment Actions
Change 930278
abandoned
by Jdlrobson:
[mediawiki/core@master] Poc: Add client-grade-X class to grade X browsers
Reason:
gerritbot
added a comment.
Jun 24 2023, 11:41 AM
2023-06-24 11:41:01 (UTC+0)
Comment Actions
Change 932347
merged
by jenkins-bot:
[mediawiki/core@master] ResourceLoader: Clarify browser support comment in startup module
ReleaseTaggerBot
added a project:
MW-1.41-notes (1.41.0-wmf.15; 2023-06-27)
Jun 24 2023, 12:00 PM
2023-06-24 12:00:27 (UTC+0)
Maintenance_bot
removed a project:
Patch-For-Review
Jun 24 2023, 12:10 PM
2023-06-24 12:10:19 (UTC+0)
Dringsim
subscribed.
Jun 28 2023, 4:51 AM
2023-06-28 04:51:18 (UTC+0)
Krinkle
mentioned this in
T342267: Investigate surprising "10% Other" portion of Analytics Browsers report
Jul 19 2023, 3:31 PM
2023-07-19 15:31:48 (UTC+0)
egardner
moved this task from
Needs Refinement
to
Backlog
on the
Design-System-Team
board.
Oct 2 2023, 9:14 PM
2023-10-02 21:14:03 (UTC+0)
Krinkle
mentioned this in
T283726: Align ResourceLoader's 'startup.js' feature check with updated modern browser list
Nov 22 2023, 5:49 PM
2023-11-22 17:49:52 (UTC+0)
CCiufo-WMF
mentioned this in
T353173: [SPIKE] Investigate remaining work for IE11 deprecation
Dec 11 2023, 5:12 PM
2023-12-11 17:12:33 (UTC+0)
CCiufo-WMF
edited projects, added
Design-System-Team (Roadmap)
; removed
Design-System-Team
Dec 13 2023, 8:02 PM
2023-12-13 20:02:28 (UTC+0)
CCiufo-WMF
moved this task from
Now
to
Next
on the
Design-System-Team (Roadmap)
board.
egardner
added a comment.
Jan 12 2024, 6:18 PM
2024-01-12 18:18:57 (UTC+0)
Comment Actions
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

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,

is of course not supported by Internet Explorer. [1]
In the future there will be other native HTML elements like

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

, but this task is about IE11 specifically
[2]:

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
egardner
mentioned this in
T338184: Accordion: Add CSS-only version and update hover and active colors
Jan 12 2024, 6:21 PM
2024-01-12 18:21:12 (UTC+0)
Jdlrobson
added a comment.
Jan 12 2024, 6:36 PM
2024-01-12 18:36:10 (UTC+0)
Comment Actions
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
In modern browser:
In IE11:
egardner
added a comment.
Jan 12 2024, 7:06 PM
2024-01-12 19:06:06 (UTC+0)
Comment Actions
Our demo site kind of falls apart in IE11, but it looks like the basic content is visible.
So this:
Becomes:
CCiufo-WMF
added a comment.
Jan 12 2024, 7:13 PM
2024-01-12 19:13:33 (UTC+0)
Comment Actions
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
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

to confirm the behavior is equivalent.
Jdlrobson
added a comment.
Jan 12 2024, 7:38 PM
2024-01-12 19:38:33 (UTC+0)
Comment Actions
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.)
CCiufo-WMF
edited projects, added
Design-System-Team
; removed
Design-System-Team (Roadmap)
Jan 16 2024, 2:13 PM
2024-01-16 14:13:27 (UTC+0)
Catrope
added a comment.
Jan 20 2024, 1:15 AM
2024-01-20 01:15:49 (UTC+0)
Comment Actions
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.
Volker_E
updated the task description.
(Show Details)
Jan 31 2024, 7:31 PM
2024-01-31 19:31:33 (UTC+0)
Volker_E
updated the task description.
(Show Details)
Izno
moved this task from
Backlog
to
Documentation
on the
CSS
board.
Feb 1 2024, 2:49 AM
2024-02-01 02:49:39 (UTC+0)
Pppery
subscribed.
Feb 3 2024, 10:51 PM
2024-02-03 22:51:01 (UTC+0)
CCiufo-WMF
triaged this task as
High
priority.
Feb 20 2024, 6:14 PM
2024-02-20 18:14:24 (UTC+0)
CCiufo-WMF
moved this task from
Backlog
to
DST-Sprint-17 (2024-02-20 to 2024-03-01)
on the
Design-System-Team
board.
CCiufo-WMF
edited projects, added
Design-System-Team (DST-Sprint-17 (2024-02-20 to 2024-03-01))
; removed
Design-System-Team
CCiufo-WMF
moved this task from
DST-Sprint-17 (2024-02-20 to 2024-03-01)
to
Up Next
on the
Design-System-Team
board.
Feb 20 2024, 6:40 PM
2024-02-20 18:40:15 (UTC+0)
CCiufo-WMF
edited projects, added
Design-System-Team
; removed
Design-System-Team (DST-Sprint-17 (2024-02-20 to 2024-03-01))
CCiufo-WMF
changed the status of subtask
T332716: Communicate intention to remove IE11 from basic support
from
Open
to
In Progress
Mar 4 2024, 5:05 PM
2024-03-04 17:05:05 (UTC+0)
ovasileva
subscribed.
Mar 4 2024, 7:20 PM
2024-03-04 19:20:14 (UTC+0)
CCiufo-WMF
added a parent task:
T333394: Vector 2022 should use details element instead of checkbox hack (IE11) for better accessibility and to fix issues with hover states on language button
Mar 7 2024, 8:40 PM
2024-03-07 20:40:51 (UTC+0)
CCiufo-WMF
lowered the priority of this task from
High
to
Medium
Apr 29 2024, 5:22 PM
2024-04-29 17:22:56 (UTC+0)
Volker_E
updated the task description.
(Show Details)
May 23 2024, 3:25 PM
2024-05-23 15:25:33 (UTC+0)
CCiufo-WMF
closed subtask
T332716: Communicate intention to remove IE11 from basic support
as
Resolved
May 23 2024, 3:31 PM
2024-05-23 15:31:14 (UTC+0)
CCiufo-WMF
updated the task description.
(Show Details)
Volker_E
updated the task description.
(Show Details)
May 23 2024, 3:42 PM
2024-05-23 15:42:00 (UTC+0)
CodeReviewBot
added a project:
Patch-For-Review
May 23 2024, 4:28 PM
2024-05-23 16:28:25 (UTC+0)
Comment Actions
jforrester opened
Update basic standards for 2024
CodeReviewBot
added a comment.
May 23 2024, 5:09 PM
2024-05-23 17:09:43 (UTC+0)
Comment Actions
volker-e merged
Update basic standards for 2024
Maintenance_bot
removed a project:
Patch-For-Review
May 23 2024, 5:31 PM
2024-05-23 17:31:28 (UTC+0)
CCiufo-WMF
assigned this task to
Volker_E
May 23 2024, 6:19 PM
2024-05-23 18:19:01 (UTC+0)
Volker_E
mentioned this in
T365759: Remove IE 11, Edge legacy 15-18, Firefox 39-48, Chrome 31-48 CSS hacks and workarounds in core, extensions and skins
May 23 2024, 7:46 PM
2024-05-23 19:46:40 (UTC+0)
CCiufo-WMF
mentioned this in
T333394: Vector 2022 should use details element instead of checkbox hack (IE11) for better accessibility and to fix issues with hover states on language button
May 24 2024, 2:50 PM
2024-05-24 14:50:05 (UTC+0)
Volker_E
closed subtask
T340173: Release new versions of browserslist-config-wikimedia and stylelint-config-wikimedia with IE11 removed
as
Resolved
Jun 20 2024, 3:42 PM
2024-06-20 15:42:52 (UTC+0)
Volker_E
updated the task description.
(Show Details)
Jun 20 2024, 3:47 PM
2024-06-20 15:47:07 (UTC+0)
Quiddity
added a project:
User-notice
Jun 20 2024, 8:45 PM
2024-06-20 20:45:07 (UTC+0)
Quiddity
moved this task from
To Triage
to
In current Tech/News draft
on the
User-notice
board.
Volker_E
closed subtask
T340172: Update browserslist-config-wikimedia to remove IE11 from the basic list
as
Resolved
Jun 24 2024, 4:28 PM
2024-06-24 16:28:05 (UTC+0)
Volker_E
updated the task description.
(Show Details)
CCiufo-WMF
moved this task from
In current Tech/News draft
to
Already announced/Archive
on the
User-notice
board.
Aug 13 2024, 1:45 PM
2024-08-13 13:45:33 (UTC+0)
Comment Actions
This was announced in
CCiufo-WMF
updated the task description.
(Show Details)
Aug 13 2024, 1:45 PM
2024-08-13 13:45:42 (UTC+0)
Volker_E
updated the task description.
(Show Details)
Aug 13 2024, 1:57 PM
2024-08-13 13:57:13 (UTC+0)
Pppery
unsubscribed.
Aug 13 2024, 1:57 PM
2024-08-13 13:57:40 (UTC+0)
Volker_E
closed this task as
Resolved
Aug 13 2024, 1:57 PM
2024-08-13 13:57:49 (UTC+0)
Comment Actions
Successfully resolved! 🎉
Maintenance_bot
edited projects, added
User-notice-archive
; removed
User-notice
Aug 29 2024, 9:35 PM
2024-08-29 21:35:56 (UTC+0)
Lucas_Werkmeister_WMDE
mentioned this in
T423292: Wikimedia Hackathon 2026: Cool new things in JS + CSS
Tue, Apr 14, 2:43 PM
2026-04-14 14:43:44 (UTC+0)
Log In to Comment
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct.
Wikimedia Foundation
Code of Conduct
Disclaimer
CC-BY-SA
GPL
Credits