Latest version of Safari should be fully supported in development

[nickserv]

Have you read the Contributing Guidelines on issues?

• I have read the Contributing Guidelines on issues.

Prerequisites

• I'm using the latest version of Docusaurus.
• I have tried the npm run clear or yarn clear command.
• I have tried rm -rf node_modules yarn.lock package-lock.json and re-installing packages.
• I have tried creating a repro with https://new.docusaurus.io.
• I have read the console error message carefully (if applicable).

Description

I noticed the Browser support documentation mentions the default Browserslist config in development:

last 1 chrome version
last 1 firefox version
last 1 safari version

Unfortunately, because of how Browserslist works, this only includes the latest minor (not major) release of Safari, which excludes half of Safari users we should support.

I suggest using last 1 safari major version instead.

Reproducible demo

No response

Steps to reproduce

https://browsersl.ist/#q=last+1+chrome+version%0Alast+1+firefox+version%0Alast+1+safari+version

Expected behavior

Latest version of Safari should be fully supported in development

Actual behavior

Latest minor version of Safari is supported in development (half of users on latest version)

Your environment

No response

Self-service

• I'd be willing to fix this bug myself.

[romainmenke]

Please don't make this change.
It is incorrect.

Safari majors are just marketing versions.

Safari minors contain web engine features and have multiple releases a year, just like Chrome major versions.

[nickserv]

It is incorrect.

No, I've proven statistically that Safari majors are more similar to majors in other browsers: https://github.com/orgs/browserslist/discussions/781#discussioncomment-6516951

Safari majors are just marketing versions.

All browser versions are marketing versions! The resulting browser compatibility is more important.

Safari minors contain web engine features and have multiple releases a year, just like Chrome major versions.

This only helps for comparing updates at a basic level, but isn't practical in this case. Currently Docusaurus only supports developing on the latest minor version of Safari, which means that the half of Safari users on older versions (including users on older devices they can't update) will be unable to use it in development!

[Josh-Cena]

What about "last 2 safari versions"? After 16.4 I've seen few using 16.2.

[nickserv]

I don't think that's enough still. 16.3 has the second highest usage (behind 16.5), both globally and in the US.

last 1 safari major version would include it, though.

[romainmenke]

If the intention is to cover a percentage of users you should change the browserslist query to a >n% query.

These are two different kinds of queries and both have a specific purpose.

Changing it to an >n% query is a valid request.

But please don't change it to major safari as a flawed proxy for a wider user base.

---

No, I've proven statistically that Safari majors are more similar to majors in other browsers: https://github.com/orgs/browserslist/discussions/781#discussioncomment-6516951

With all due respect, this is untrue.

This is from an actual WebKit engineer working at Apple : web-platform-dx/web-features#173 (comment)

[Josh-Cena]

I would agree that user percentage is a bad measure here—we should definitely assume developers use newer versions than users. The question is how many Mac developers use outdated Safari versions. I'd admit that I myself have never cared about my Safari version, since the update is delivered automatically.

[romainmenke]

The question is how many Mac developers use outdated Safari versions.

How many are on an outdated version that doesn't support a specific feature that is a critical building block of the version of docusaurus that they are using.

That implies that a recent change to docusaurus adopted a very modern feature and that a developer quickly updated to this new docusaurus version, while at the same time neglecting to update Safari.

If you haven't received any specific bug reports about this, then I would say that this group is very small :)

If the intention is to only actively support the latest meaningful release of each major vendor then I would say that the current config is fine.

I personally think that this config is fair for a developer tool. It is less complicated if you can ask developers to update to the latest version without specifying what that means for each browser.

[Josh-Cena]

It's usually not about Docusaurus' own code but the code that users write themselves.

[nickserv]

Changing this would be massively breaking and would upset WebKit/Apple and Samsung Internet.

If you want a query that reflects a majority of users you must use >n% queries.

There's nothing that prevents using >n% queries if more coverage is needed, but this isn't an argument against incremental improvements to browser support.

With all due respect, this is untrue.

This is from an actual WebKit engineer working at Apple : web-platform-dx/web-features#173 (comment)

Just because Safari develops and publishes minor releases similarly to major releases in other browsers, doesn't mean users install them in the same way (they often can't because it's not evergreen). As a result I don't think it's relevant in a discussion about supporting versions of browsers users have installed. If you have proof my calculations are incorrect, please show a counterexample.

I would agree that user percentage is a bad measure here—we should definitely assume developers use newer versions than users. The question is how many Mac developers use outdated Safari versions. I'd admit that I myself have never cared about my Safari version, since the update is delivered automatically.

66% globally and 67% in the US (according to browsersl.ist)

[romainmenke]

Just because Safari develops and publishes minor releases similarly to major releases in other browsers, doesn't mean users install them in the same way (they often can't because it's not evergreen). As a result I don't think it's relevant in a discussion about supporting versions of browsers users have installed. If you have proof my calculations are incorrect, please show a counterexample.

Please re-read : #9173 (comment)

---

I will bow out now.

[slorber]

I'm a Docusaurus dev who occasionally use Safari, and my Safari version is currently 16.1

I don't know why in particular I'm on this version and not the latest minor. Safari does not ask me to upgrade, and there's no upgrade option in the menu. It looks related to the OS version somehow 🤷‍♂️. I'm on Ventura 13.0 (not the latest) and my OS does not suggest me to do minor OS upgrades (maybe I disabled this 🤷‍♂️ I don't care about cutting edge macos features).

I never particularly cared much about my macOS/Safari version, but one thing is certain: I expect things to work by default for me in dev.

Browserlist support is currently safari 16.5 after my local DB update, so any feature between 16.1 and 16.5 can break. It's not super likely to happen, but it can in practice.

Even among a developer crowd, I think my own case proved that developers are more likely to have an out-of-date Safari version than the Chrome/Firefox version because is not tight to OS upgrades.

So I'm in favor of supporting the latest major like @nickmccurdy suggests, or at least significantly increasing the Safari-supported browsers so that at least the Safari version that ships with the very first macOS major version that has the most market share (currently 13.0 Ventura, and later 14.0 Sonoma)

Remember that all this is part of the init template, package.json that the users can modify if they don't agree. It's just a default value, and IMHO it should work out of the box and not try to be too aggressive for no good reason. If you want to be more aggressive to you can revert to last 1 safari version if you want on your own site.

---

@romainmenke I don't understand why you are so against this change. This seems right to me and in any case, it shouldn't affect you much. Your Docusaurus dev experience would keep being the same and it would only slightly decrease the risk of something bad/confusing to happen.

I clearly thought that last 1 safari version meant > Safari 16 here, this is not intuitive. And if I introduce a modern feature myself, it would have confused me if it wouldn't have worked for me in dev, or would have needed a minor macOS upgrade to make it work with the current settings.

In case, if I were to introduce a new modern feature:

• I don't want to have to troubleshoot any dev-only issue
• I don't want to upgrade my OS minor
• I don't want to think that I might need a browser list query change

It should just work.

[romainmenke]

I am not against this change at all.
I am only trying to clarify misinformation.

If the intention is to have increased support for older browsers versions, then please change the query to something that really achieves that. For example a query with >n%.

The misinformation I am trying to prevent from proliferating is that Safari majors are equivalent to Chrome majors. They absolutely are not. There is no debating this. Is is factually incorrect.

Making the proposed change purely because someone suddenly says that they are equivalent would be poorly motivated.

---

Setting the correct values can be done by looking at your target audience, seeing which browser versions they use and then matching that in your browserslist.

[romainmenke]

The nuance here is that these values will evolve differently over time.

Changing your config towards last 1 safari major version means that you are now dependent on the major version releases of Apple. When Apple changes how it versions it software you might run into unexpected issues.

The same is true with last 1 safari version but this config is much more straightforward : only the very last release is supported.

---

However a query that matches your target audience will keep working even if when Apple makes changes to it's versioning strategy.

For example : > 0.5% in US and not dead, last 2 firefox versions, last 2 chrome versions, last 2 safari versions, not op_mini all

This only targets US, so be mindful that this is excluding a lot of regions and browsers popular there.

https://browsersl.ist/#q=%3E+0.5%25+in+US+and+not+dead%2C+last+2+firefox+versions%2C+last+2+chrome+versions%2C+last+2+safari+versions%2C+not+op_mini+all

[slorber]

I see thanks @romainmenke

What we want here is to support well developers that are using Safari (as main browser or not).

My assumption is that devs upgrade their OS major quite soon, but may not upgrade their OS minor (like me) as often, so the goal is to cover that. I'm assuming a dev is more likely to be up-to-date than a regular user but it's hard to tell.

Note we are discussing a dev-only setting here, and the goal is that it just works locally for the current user.

Isn't there a query like current local safari version? Because it only has to work on the current computer in the end, it's not meant to be deployed anywhere.

[romainmenke]

A very clear difference between these two styles of queries :

• Apple releases Safari 17 today
• caniuse, browserslist, push an update
• latest 1 safari major version is now 17

how many people of your target audience update immediately to the latest OS / Safari version?

Whereas with a >n% query the list returned by browserslist would always reflect adoption of browser versions.

[romainmenke]

Isn't there a query like current local safari version? Because it only has to work on the current computer in the end, it's not meant to be deployed anywhere.

It does not exist as far as I know, but that is an awesome idea!

I think the use case for this is very common.

I will open an upstream issue for this: browserslist/browserslist#782

[slorber]

Thanks, let's follow the discussions on that issue and decide accordingly then 👍

Since it's just a default in newly initialized sites, and users can change it easily, there's no hurry to do this change right now.

[MrHBS]

This is why I hardcode my version, eg iOS >= 15.4

[slorber]

Hey, the browserlist issue is closed, so wonder what we should do.

IMHO even the Chrome/Firefox queries are a bit too aggressive: if a new version is published, even devs may eventually stay on the former version for a few days.

I understand how it remains imperfect, but my proposal is:

last 3 chrome version
last 3 firefox version
last 5 safari version or last 1 safari major version

https://browsersl.ist/#q=last+3+chrome+version%0Alast+3+firefox+version%0Alast+5+safari+version+or+last+1+safari+major+version

I couldn't find a range query (>n%) that returned me a satisfying result, considering this would retrieve a list of browsers that are currently in use by regular users, and not necessarily a dev crowd.

It looks good enough to me, and prevent the majority of issues to happen for 99.9% of the devs. Unless you express severe pushback against this idea I'll move on and do this change, that remains an improvement to the current query.

[romainmenke]

Why specifically this bit : last 5 safari version or last 1 safari major version ?

I am unsure what the or last 1 safari major version is adding.

[slorber]

Yes maybe it's a bit useless.

Can we go with this simpler one?

last 3 chrome version
last 3 firefox version
last 5 safari version

[romainmenke]

You could go for a heuristic like last 7 safari version which happens to be 1 more than the number of releases in a semver major range. This would allow you to cover the next to last iOS version.

https://browsersl.ist/#q=last+7+safari+version

But that would be brittle.
If they are extra productive next year and have 7 or more meaningful releases next year it would break.

---

Can we go with this simpler one?

last 3 chrome version
last 3 firefox version
last 5 safari version

This seems fine to me and I think it matches your intent :)