Feedback: Confusion about config syntax for Safari potentially results in reduced support for Safari

[nickmccurdy]

I've been using various tools that support Browserslist configs for a while now, and was recently discussing adding support for Baseline, when I got this helpful reply from @romainmenke:

last 2 safari versions is 16.5, 16.4 whereas Baseline has 16 and 15 at this time

At first I thought this was a bug or missing feature. I did some more troubleshooting and research and found the major versions syntax for Safari and iOS, which works nicely with last 2 safari major versions.

I found this issue difficult to discover because there's no linter warning for it and browsersl.ist lists so many Safari versions that I didn't think to read them carefully. I suspect other developers may also find this difficult to understand, as popular open source tools like Create React App, Vite, Docusaurus, and Gatsby have made the same mistake, and I found approximately 9,400 similar configs on GitHub. Without fixing this, a significant portion of Safari users could be left unsupported. In the cause of Docusaurus, I noticed its Browserslist config could potentially cause half of its developer users to be unsupported, according to browsersl.ist.

Personally, I think versions should use major versions for Safari and iOS by default, as it appears to do for all other browsers and systems. If this isn't possible, I'm hoping to at least raise awareness and propose DX improvements for Safari support. I also believe Safari version support is more sensitive than other browsers, as it's the only browser engine on iOS and requires system updates, and doesn't automatically update on older macOS versions like evergreen browsers can.

Related issues

• Publish and maintain a browserslist query. web-platform-dx/web-features#264
• Latest version of Safari should be fully supported in development facebook/docusaurus#9173
• Latest two versions of Safari should be fully supported in legacy plugin vitejs/vite#13921

[romainmenke]

Personally, I think versions should use major versions for Safari and iOS, as it appears to do for all other browsers and systems. ` If this isn't possible, I'm hoping to at least raise awareness and propose DX improvements.

This wouldn't be ideal :)

Baseline was using a bad definition where it is thinking in semver and was forcing that thinking onto the versioning schemes of all browsers.

A Safari minor version bump is equivalent to a Chrome major version bump.

Safari majors :

• are tied to marketing for new OS versions
• happen once a year
• are ties to larger changes to the browser itself, not the underlying engine

Safari minors :

• happen multiple times a year
• contain new browser engine features

Chrome majors :

• happen multiple times a year
• contain new browser engine features

Firefox majors :

• happen multiple times a year
• contain new browser engine features

Samsung Internet minors :

• happen multiple times a year
• contain new browser engine features

Baseline/WebDX have since corrected their definition (only internally) so that Safari minors are equivalent to Chrome majors. This change isn't yet reflected on marketing pages and blog posts for Baseline

---

IMO the baseline definitions are just complete bogus.
They are so wildly incorrect and unhelpful that is best to just ignore Baseline entirely for now.

I can say that here, but it wouldn't be helpful to say that in the WebDX group.
I really hope that their work progresses up to a point where they do have a good definition.

There is a very large chance that that definition will be extremely close to defaults in browserslist.

defaults in browserslist does what you want and has been tested in the wild.

---

It is however critically important that no one starts changing things that work today because of bogus reasoning in Baseline.

It is better to let them work through their mistakes without causing further fallout in the wider dev community :D

[romainmenke]

Please see : web-platform-dx/web-features#173 (comment)

Apple/WebKit are very vocal about minor versions being equivalent to major versions in Chrome/Firefox.

The same is true for Samsung Internet.

[nickmccurdy]

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 potentially confusing queries. And there doesn't have to be abny breaking change.

[romainmenke]

And there doesn't have to be abny breaking change.

It is a breaking change :)

For example I depend on browserslist in cssdb, postcss-preset-env, core-web and polyfill.io to construct and verify support data.

Changing the versions that are returned for such queries would break either those tools directly or glue scripts that support them.

---

But more importantly it is still an incorrect assumption that Safari majors are their meaningful releases. They are not.

This is what I have been spending all my free time on for the last 4 years.
Please consider the possibility that the current situation might be correct :)

[nickmccurdy]

It is a breaking change :)

No it's not: https://github.com/orgs/browserslist/discussions/781#discussioncomment-6517004

[romainmenke]

I am leaving this conversation.

I am a core maintainer of large projects for which this is going to be a breaking change.
I have given you extra information from good sources.

I don't want to debate what is or isn't true when I am simply presenting you with facts.