Repository navigation
[MNT]: Clarify web browser policy #32165
Description
Summary
I needed a quick break from macOS backend work, so I'm looking at modernizing and cleaning up the web_backend JavaScript files. They currently use a mixture of outdated JavaScript syntax while also using modern web browser features like ResizeObserver.
I noticed that we removed the ResizeObserver ponyfill in #31669. Do we have an official policy on which specific web browser versions we support?
For example, we have code to check CanvasRenderingContext2D.backingStorePixelRatio; however, that property was never official and removed around ~2015. We also warn if a WebSocket doesn't support binaryType; however, it has 100% tracked user support on caniuse.
Activity
subhakartadimalla commentedon Aug 3, 2026
Hi! I'd be happy to work on this. Could I be assigned to this issue?
tacaswell commentedon Aug 3, 2026
@subhakartadimalla Thank you for your enthusiasm, however as this is a policy question I do not think it is good issue to start working on.
timhoffm commentedon Aug 3, 2026
We don't have an official policy (maybe we should create one?).
Anyway, our general policy is to be defensive. We should not impose restrictions that practically affect a relevant amount of users. On the other hand we are not obliged to support ancient systems.
Since Python and the browser are two completely separated ecosystems I have no clear intuition how they relate. (As opposed to the Python, where e.g. there should be no substantial reason for users to be locked on numpy 1.x (=old) but requiring the newest features from matplotlib. Either you have a strong focus on stability, or you have designed your environment to be upgradable.
For browsers, I would anticipate that most users will be on recent versions because automated update mechanisms are wide-spread and browsers are highly sensitive to security issues, so as long as a user is connected to the web, you they'll want to be on the most recent version. However it could be very different for air-gapped systems, and IMHO we should consider them as well.
My defensive wild guess would be that we can safely disregard browser versions that are older than 5 years. Possibly to be checked: What do other libraries in the ecosystem do, (e.g. jupyter notebook/jupyterlab)?
iccir commentedon Aug 3, 2026
Agree 100%.
This is similar to my own company's browser policy; however, we write educational content and have a lot of students on older Chromebooks and iPads which can no longer update. 5 years might be a bit too defensive for matplotlib as an official policy, but it's a good target.
Both Jupyter Notebook and JupyterLab support "…latest versions of these browsers: Chrome, Safari, Firefox". That seems overly aggressive, in my opinion.
timhoffm commentedon Aug 3, 2026
To be clear: If we support browsers from the last n years, we support devices that are out-of-update for n years. So 5 years is indeed very generous. OTOH I'd say let's start with this and if we see that we could significantly simplify the codebase or ease newer features when shortening the the support period we an revisit.
iccir commentedon Aug 3, 2026
Note that even the very-generous "5 years for n" gets us pretty far. That would let us simplify a lot of the ResizeObserver code come March 2027 (Safari 15.4 was released on 2022-03-14) as well as migrate to ES6 classes, arrow function syntax, etc.
timhoffm commentedon Aug 3, 2026
Our next release is likely around the end of the year. It's then only 3 months less 5 years. If you want to start working on the web backend right now, and dropping the mentioned structures this would be helpful, I'd have no concerns going with a slightly shorter support period.
tacaswell commentedon Aug 3, 2026
Semi related, I have a (robot written) typescript front end in https://github.com/tacaswell/mpl-fastapi/tree/main/mpl_fastapi/static/js/src . if we are going to start doing much work on the js code, we should at least review that first (it also includes a re-write of the wire protocol).
iccir commentedon Aug 4, 2026
Cool, I'll take a look!
Note that I'd advise against using TypeScript for the size of our js code. While I've had great experiences using it with larger projects (75000 lines / 250+ files), it adds a significant entry barrier for maintenance and the build process. Ideally, Type Annotations will eventually be added to the language and stripping them from a built product will require no compilation phase.
ianthomas23 commentedon Aug 4, 2026
Please be very careful making any changes to the webagg-related code, and ideally wait until #32148 is merged. There are downstream web-based backends such as ipympl that reuse webagg code, and the last API change made here had serious repercussions downstream for a significant length of time.
I would 100% opt for TypeScript, and keep both the TypeScript source and generated JavaScript in the repo. The conversion from TypeScript to JavaScript doesn't have to be part of the build process, it can be a separate manual step that is only invoked by those making changes to the TypeScript, and the generated JavaScript can include comments at the top telling developers this and pointing to the relevant docs/readme.
timhoffm commentedon Aug 4, 2026
If webagg is ancient and heavily depended on it may be better to leave it alone and do a new web frontend from schratch, which seems what @tacaswell has done.
iccir commentedon Aug 4, 2026
I think that sounds like the best path to take based on @ianthomas23's comment. I'm going to back away from making any cleanup to webagg for now.
sushmitanandani127686 commentedon Oct 21, 2026
WeatherGod commentedon Oct 21, 2026
An important consideration is that the browser policy should be decoupled from the python policy because users might be accessing the web frontend on a completely different device from the machine serving up the web frontend. So, just because we say that our python code generally supports X years back, that doesn't mean that our JS code also has to be for X years back.
timhoffm commentedon Oct 21, 2026
Since browsers are quite exposed they typically need to be updated to the latest version for security. The only systems where that’s not necessary would be air-gapped environments. But the I’d still wonder why they can update matplotlib but cannot update their browser.
Overall I agree that our browser policy could be less defensive than our python dependency policy.
WeatherGod commentedon Oct 21, 2026
It is entirely possible for these to be two different machines. A very common scenario for outdated browsers are tablet devices that have fallen out of support and has no reasonable mechanism for updating them. One could argue that such users are not the type that would be viewing charts online, but I wouldn't know one way or another.
iccir commentedon Oct 21, 2026
Yep, I'm in this situation, actually. Apple requires that all web browsers on iOS use the system WebKit framework. Even if I install the latest version of Firefox on my iPads, it has to use an ancient variant of WebKit. This is obviously not great for security, but I also don't use those devices with any kind of account login.
I'm not sure how much this affects matplotlib, but it's incredibly common in my day job (education software) and is the reason I have to support 5+ years back.