Baseline query

[galvarez421]

It seems like it might be useful to provide a "baseline" query to account for the target browsers of https://web.dev/baseline/!

[ai]

We can add alias for last 2 Chrome versions, last 2 Edge versions, last 2 Firefox versions, last 2 Safari versions.

I, honestly, don’t like Baseline, since it looks like too US centric for me. There are no browsers popular in Asia and Africa there.

Should we wait a little to see how popular it will be?

[galvarez421]

Waiting seems fine to me, especially since users already have the ability to query for those browsers as you described!

[nickserv]

We can add alias for last 2 Chrome versions, last 2 Edge versions, last 2 Firefox versions, last 2 Safari versions.

I think an alias would be helpful, as it's already being actively used by web.dev and MDN.

However, this could make it harder to support versioned Baseline lists: web-platform-dx/web-features#264 (comment)

I, honestly, don’t like Baseline, since it looks like too US centric for me. There are no browsers popular in Asia and Africa there.

According to Statcounter Global Stats, Chrome still has over 70% market share in Asia and Africa. I believe most of the other popular mobile browsers in these regions are based on Chromium, which is already in Baseline.

Should we wait a little to see how popular it will be?

I'd argue it's already getting popular, considering it's already been added to many articles on web.dev and MDN, and the WebDx Community Group running it already has 2 chairs and 42 other participants from at least 11 organizations.

[romainmenke]

I'd argue it's already getting popular, considering it's already been added to many articles on web.dev and MDN, and the WebDx Community Group running it already has 2 chairs and 42 other participants from at least 11 organizations.

This is not really accurate and doesn't carry any weight.

The people behind the WebDx Community Group and web.dev and MDN are the same.
So this isn't adoption, it's just marketing.

---

According to Statcounter Global Stats, Chrome still has over 70% market share in Asia and Africa. I believe most of the other popular mobile browsers in these regions are based on Chromium, which is already in Baseline.

Baseline only includes latest 2 Chrome majors, so any Chromium based browser that is a little bit more behind (e.g. Samsung Internet with ±5% market share) is excluded.

In reality Baseline excludes a lot more people than it includes.

---

I think an alias would be helpful, as it's already being actively used by web.dev and MDN.

It's too soon to create an alias as the definition of Baseline isn't even stable yet.
So you can only create more incorrect and confusing things today.

At this time Baseline is harmful towards end users and hostile towards browser vendors not included in their list.
This was not the intention of the WebDx community group, but it is very much the reality.
It is not inclusive and it doesn't promote/foster an open web.

They are very actively working on a better definition.

[nickserv]

According to Statcounter Global Stats, Chrome still has over 70% market share in Asia and Africa. I believe most of the other popular mobile browsers in these regions are based on Chromium, which is already in Baseline.

Baseline only includes latest 2 Chrome majors, so any Chromium based browser that is a little bit more behind (e.g. Samsung Internet with ±5% market share) is excluded.

In reality Baseline excludes a lot more people than it includes.

Perhaps there could be separate lists or envs with more relaxed versioning based on usage of release dates of browser versions.

[romainmenke]

Perhaps there could be separate lists or envs with more relaxed versioning based on usage of release dates of browser versions.

That is what is being researched in the WebDx community group.
There was a lot of pushback (including by me) and they are very open to this feedback.

[romainmenke]

The definition was updated and in a very specific way.

https://web.dev/blog/baseline-definition-update

Newly available: An item is newly available in Baseline when it becomes interoperable across the main browsers.
Widely available: The point at which the feature is generally safe to use. This line is set at 30 months after the newly available point.

I don't think Widely available can be expressed by browserslist because it is feature centric.

Browserslist doesn't know anything about features.

Tools like core-js, babel, autoprefixer, postcss-preset-env, ... however might be able to integrate this.

[ai]

@romainmenke how we can select browsers? Can you show an example?

I do not see any logic in queries like Widely available cssmodules

[romainmenke]

For example with oklch : https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/oklch#browser_compatibility

• chrome 111
• firefox 113
• safari 15.4

1. take the last release date of all versions that initially added support
   • Firefox 113 was last at 2023-05-09
2. is that date before or after 30 months ago?
   • 30 months since last release is 2025-11-09
   • that last release is less than 30 months ago
3. if it has been longer the feature is considered to be Widely available

But I don't see how this can be easily used by developers.

[ai]

@romainmenke the browsers you need can be selected by old query like supports css-oklch (we don’t have MDN data yet, but you get the idea).

How Baseline criteria be used here to select browsers?

I think we can use Baseline only to select features by browsers list, not in opposite way.

[romainmenke]

I think we can use Baseline only to select features by browsers list, not in opposite way.

Yeah, exactly.
I don't think there can be a general purpose Baseline alias in browserslist.
I don't think developers can do "browserslist": "baseline" and that things will magically start working.

I think this needs to be implemented in individual tools.
postcss-preset-env could have a "baseline": true options.
And then it would only activate fallbacks for features that aren't Widely available at the time of running PostCSS.

[romainmenke]

I think I am confusing myself with the overly complex wording of the definition.

On second thought I think it is as simple as :

List all versions for Safari, Firefox, Chrome of the last 30 months for both desktop and mobile.

Is there any practical example where that would yield a different outcome?

---

They did not expand the set of browsers to include options that are popular in non-western regions but they did address this.

30 months is considered to be a proxy metrics that should in practice cover sufficient users, regardless of the actual browser they use.

You can still find significant segments that fall outside of this definition.
But I think it will be rare that someone is creating something for such a segment without knowing that they need a specific browserslist that is different from Baseline.

[zerdox-scalr]

web-platform-dx/web-features#536 (comment)
https://shinigami92.github.io/baseline-green/

[tonypconway]

Hi folks, hoping to revisit this issue based on current activity around Baseline. As @romainmenke pointed out in December, there's a valuable use case for developers to state a Baseline preference in tools that depend on browserslist.

We've already spotted agencies adopting Baseline Widely Available as their cut off point for new web features, but we also want people to be able to adopt a specific Baseline year if it makes sense for them. This makes sure that We're working towards developers looking at their analytics provider and knowing that e.g. 99% of their users are on a Baseline 2021 or later compatible browser.

From a syntax POV, there are two possible queries I'd expect to use:

1. baseline YYYY would return the final release of the stated year for each browser and all subsequent versions.
2. baseline widely available would return all browser versions released < 30 months before the time of the query.

I can definitely see how use case 2 might be problematic, as it's a moving target. But use case 1 seems pretty cut and dry. Those browser versions per year are fixed and easily collated by year using MDN browser-compat-data's release info, as in this snippet.

There are considerations around browsers outside of Chrome/Edge/Firefox/Safari, but as @romainmenke pointed out the 30 month window is at least partly intended to address the time it takes for engines to filter through, OSes to update etc. In addition, browser-compat-data has engine and engine_version data for popular browsers that incorporate an engine from elsewhere (see e.g. Samsung Internet). RUM Archive's Baseline visualisation uses this data to logically group browsers, and we expect other analytics providers will adopt a similar approach.

We're happy to collaborate with you on figuring out the best way to make this work, and if there are things missing or which could be simplified in web-features, we can take a look at that.

[foolip]

Regarding the problem of baseline widely available being a moving target, I wonder if each release of browserslist could include a cutoff date? Alternatively, web-features or some package maintained by us Baseline folks could pin a date, or browser versions directly.

[ai]

I wonder if each release of browserslist could include a cutoff date?

We can use current user’s time and browser’s release date from caniuse.

We already have queries like since 2020 or last 3 years. We can make baseline queries like an alias for them.

Can somebody prepare the PR since I am on the JSNation conference?

[tonypconway]

I've edited my previous comment to reflect this, but just for the avoidance of ambiguity, the list that fits the criteria of e.g. baseline 2022 would be the final 2022 release of each of the browsers within Baseline. Quite important for it to be "last 2022 release and following" and not "all releases after 2022", as you'd end up potentially losing features that became interoperable later in 2022.

[romainmenke]

I've edited my previous comment to reflect this, but just for the avoidance of ambiguity, the list that fits the criteria of e.g. baseline 2022 would be the final 2022 release of each of the browsers within Baseline. Quite important for it to be "last 2022 release and following" and not "all releases after 2022", as you'd end up potentially losing features that became interoperable later in 2022.

I am not sure.

The baseline 2022 label can be attached to any feature that becomes interoperable during 2022. This might be on jan 1, or on dec 31.

The question then is:

• baseline 2022 means: I want to support only browser versions that meet the baseline 2022 criteria
• baseline 2022 means: I want to ensure baseline support/status for my users up to 2022

The first statement aligns with dec 31
The second with jan 1

With the first option you can also get weird results. baseline 2024 would be an empty set since no releases yet exist after 2024-12-31

---

I prefer resolving baseline 2022 to since 2022-01-01

[tonypconway]

Yes, we've had some more discussion on this in web-platform-dx/web-features#1047 as well. What it boils down to is that "Baseline 2022" isn't a set of browsers, but a set of features. Any feature that was interoperable across the core set of browsers by the end of 2022 is a "Baseline 2022" feature. Any browser version that supports all of those features is Baseline 2022 compatible.

So you can say with some certainty that the final release of each of the core browsers in 2022 and all subsequent releases supports all the features in the Baseline 2022 feature set. There are probably also cases where an earlier release of a given browser supports that feature set, because it already supported all the features therein, but we don't have the data ready yet to specify that with certainty. One day in the future, web-features will have all that data, but right now it doesn't, so "final release of specified year" is the safest selector to get all the features you expect.

Thanks Romain for taking the time to create a branch. I put together an alternative that accepts two possible config options:

• baseline widely available: returns all browser releases in the last 30 months and the last release of each core browser prior to that date.
• baseline YYYY: returns all browser releases after the specified year, and the last release prior to that cutoff date.

The only current downside is that it doesn't give you all the versions you would expect for Chrome and Firefox on Android because of caniuse-lite missing older versions. But the desktop versions of both browsers are pretty much exactly aligned on features with their Android counterparts, so the desktop versions should act as a guardrail for feature selection in other tools that depend on browserslist.

I also haven't written tests and I'm not sure if the grammar is necessary, happy to be advised as this is my first time contributing.

[romainmenke]

@tonypconway said:

Yes, we've had some more discussion on this in web-platform-dx/web-features#1047 as well. What it boils down to is that "Baseline 2022" isn't a set of browsers, but a set of features. Any feature that was interoperable across the core set of browsers by the end of 2022 is a "Baseline 2022" feature. Any browser version that supports all of those features is Baseline 2022 compatible.

@romainmenke said:

baseline 2022 means: I want to support only browser versions that meet the baseline 2022 criteria

If that is the official guidance of the web-dx community group then I will alter my proposal :)

---

[romainmenke]

baseline widely available: returns all browser releases in the last 30 months and the last release of each core browser prior to that date.
baseline YYYY: returns all browser releases after the specified year, and the last release prior to that cutoff date.

I think there is an edge case / bug here.

If either conditions results in no versions for a given browser, then the most recent release should be returned instead.

This covers two cases :

• a new browser emerged and was added to core set quickly
• a browser stopped receiving updates but is still part of the core set

[tonypconway]

In the case of:

a new browser emerged and was added to core set quickly

As long as the list here is updated to include the new browser in the set, any Baseline query should return at least the latest release of that browser, because the latest release will fall into all of the possible definitions, right? And that's the case for all browsers, including and_ff and and_chr - you currently only have the latest versions of those browsers in caniuse-lite, so making sure the latest version of each browser is returned in the case that there's only 1 matching recent version is pretty important¹.

As for:

a browser stopped receiving updates but is still part of the core set

I don't know exactly what the plan is for such a situation. I think a browser that has been officially discontinued is no longer suitable for inclusion in Baseline, as it would effectively freeze the standard on the final release of that browser. I can't speak with the authority of the web-dx CG, but I imagine the web-dx CG would remove that browser from the core browser set pretty rapidly. For now, it's a hypothetical that depends on Apple, Mozilla, Microsoft or Google deciding to abandon the browser space entirely on at least one major OS which seems... less than likely! So probably not a case we need to worry about addressing right now. But @atopal and @ddbeck may have more to say on the matter.

Footnotes

1. This is a separate topic that has come up recently. As you know, caniuse-db doesn't include any versions of and_ff and and_chr before the current version because of the lack of usage data. Kadir, Daniel and I discussed this with @Fyrd recently, and his suggestion was not to include older versions in caniuse-db because it would break the 1:1 mapping of version_list and usage_global in data-2.0.json which could mess things up downstream.

   Because caniuse-lite is already importing MDN's browser-compat-data, he suggested tweaking the logic for in caniuse-lite to supplement the release_date object to include older browser release dates based on browser-compat-data where they aren't available in caniuse-db. I think that's a sound approach, and will create an issue in caniuse-lite asking for this, as it would make the Baseline queries here in browserslist more accurate. ↩

[romainmenke]

I didn't mean a bug with Baseline.
More a potential bug when converting your definitions to code naively.

I don't know exactly what the plan is for such a situation. I think a browser that has been officially discontinued is no longer suitable for inclusion in Baseline, as it would effectively freeze the standard on the final release of that browser.

The goal of Baseline is to help users find features which are safe to use.

This is not hypothetical, it has already happened :)
IE once had majority market share but eventually died.

Say the same thing happens to Chrome, then there will be a gap when market share is still too large to ignore it, while at the same time the latest release might already be quite old.

This will be a painful era when standards seem frozen, but that will accurately reflect what is safe to use for developers. Including the latest release as a fallback is the correct representation of this.

Eventually this era will come to an end when support drops low enough to remove that browser from the core set.

Here it is important to keep in mind that "30 months" is a proxy for market share.
Any browser that no longer has sufficient market share will be omitted from the core set.
But a dead browser, that is part of the core set, still has too much market share to ignore, even when the last release was more than 30 months ago.

Is there is a scenario where we don't want to do this fallback?

[ddbeck]

Chiming in here as a maintainer of web-features and Baseline.

The summary is that I endorse the baseline widely available and baseline YYYY understandings here, but I don't think there's a need to have a backstop for dead-end browsers, as long as Baseline and web-features is maintained.

Some notes on definitions here, or jump to the end for specific recommendations:

• Taking baseline widely available to mean the release at least 30 months ago in each of the core browser set browsers is good (and true to the Baseline definition). 👍

• Taking baseline YYYY to mean the last release of each core browser set browser in YYYY is a good, safe approximation and the one I'd publish out of the web-features package today if I could. 👍

• In the future, once web-features has largely complete coverage of all of web platform features, taking baseline YYYY to mean the last release of YYYY will become an approximation that is potentially cover fewer releases than reality (that is to say, it is a cautious approximation). For example, the second-to-last release of a single browser in a year might have support for all of the interoperable features in that year. I won't know how common this is until late this year.

• baseline YYYY where YYYY is ≤2014 is undefined, because there are no Edge releases before 2015. The web-features owners intentionally deferred deciding whether or how to handle features during the IE era.

• Similarly, the web-features owners did not define a browser addition or removal process. We did discuss it, but decided that the actual facts would make a difference to our definition updating process (e.g., a vendor discontinuing a browser is different from developers rejecting a browser is different from a wholly new browser gaining importance). (I'll try to document this and the preceding point on web-features.)

• The web-features governance team has a meeting quarterly and the Baseline definition calls on us to formally review the definition annually. I have no doubt there'd be ample discussion and warning of changes to the definition.

Some recommendations:

• Use the proposed baseline widely available and baseline YYYY calculations, for now. I don't think there's a need to backstop dead-end browser cases, because…

• web-features ought to calculate and publish a mapping from browser releases to Baseline years (adapting to any changes in the definition, if applicable). When that work is done, browserslist/caniuse-lite should use it as a source of data, instead of doing its own calculation. Follow Include version in data.json web-platform-dx/web-features#1186 and Create a JSON object (or objects) that maps browser versions to Baseline years web-platform-dx/web-features#578 for this.

• If a user attempts to use baseline YYYY before 2015, then they should get an error.

(edited: to fix a mistake in the way I described the YYYY approximation)

[romainmenke]

@ddbeck is there a scenario where doing a fallback to the last release would be incorrect?
I don't mind removing this fallback, but it seems like an obviously better approach to add a fallback.

In may 2016 (30 months after release) IE11 still had more than 5% market share.

Without a fallback people would have suddenly stopped including polyfills for IE after that date.

But even before that, this would have been noticeable in baseline 2014.
As no releases happened for IE in 2014 it would have been omitted entirely even when it was only 1 year and 1 month old at that time and had 8% market share.

Is there any actual harm in including a fallback?

(stats: https://www.w3counter.com/trends)

[romainmenke]

If a user attempts to use baseline YYYY before 2015, then they should get an error.

We can add an error for this

[romainmenke]

🤔 Just to make sure we aren't talking about different things.

I am mostly concerned about implementation bugs while using examples like IE to illustrate these.

A implementation could do:

1. look for the first release after a specific point in time (30 months ago, 31 december of a given year, ...)
2. return that release and each release after
3. optionally return the release prior to the one that was found

If no release is found after that point in time the list will be empty. because condition 2 and 3 never trigger.
Even when the point in time is fairly recent like baseline 2024 (this year)

Doing a fallback to the last release ensures that the list is never empty.

---

Also important to keep in mind that browserslist is doing the inverse as Baseline.

Baseline is tracking interop of features.
browserslist is used to polyfill features that lack interop/support.

Excluding a browser has a dramatic effect.
It means that no polyfill will be included for features that only lack support in that browsers.

latest chrome and latest firefox and latest edge without latest safari means that you wont receive any polyfills for safari at all. Such a setting says: "I am not targeting/supporting Safari at all"

---

Aside :

This is maybe already a flaw with having support for Baseline in browserslist.
Even the latest definition of Baseline, which I really like as a tool for learning and teaching about Web features, is unfriendly towards other browsers.

If a browser outside of the core set requires a specific polyfill it will never be served such a polyfill when developers use baseline queries.

You can easily use it one direction, as a proxy to know if something is safe for most developers, most users.
But you can't easily use it to make something safe.

[ddbeck]

I think the main harm of a backstop is that it is surprising. If I plug in baseline 2016 (alone), I think it would be strange for browserslist to resolve that into a list of releases that includes browsers not in the definition of Baseline. If I wanted to declare support for IE, I could opt-in to that specifically (e.g., baseline 2016, IE > 10), right?

[romainmenke]

I think the main harm of a backstop is that it is surprising. If I plug in baseline 2016 (alone), I think it would be strange for browserslist to resolve that into a list of releases that includes browsers not in the definition of Baseline.

That would never happen, right?
And also not what I proposed :)

We would never return a browser outside of the core browser set and it is the intention to always keep up to date with the core browser set as maintained by the web-dx CG.

The case I outlined is something else but I can understand the confusion :)

The examples with IE are purely because IE is the most recent example of a major browser that died. If we created Baseline in 2012 it would have included IE. And in early 2015 it might have still included IE because of market share.

The backstop would only do fallbacks for browsers in the Baseline set.

So if you define baseline 2024 you would still get the latest version of each browser in the set, even when we haven't reached the end of 2024 yet. The same for 2025, even when declaring a year in the future doesn't really make sense.

[ai]

The power of Browserslist is query combining. We do not need to create very complex rules for baseline query since users can do just: baseline 2024, last 1 version or baseline 2024, ie 11 (if they need it).

Because it is almost impossible to create a logic for Baseline which will work for all cases.

[romainmenke]

I like this @ai!
Thank you for this suggestion 🙇

[romainmenke]

I will also omit the baseline newly available because it is so similar to last 1 version.

[ddbeck]

So if you define baseline 2024 you would still get the latest version of each browser in the set, even when we haven't reached the end of 2024 yet. The same for 2025, even when declaring a year in the future doesn't really make sense.

Ah, I see what you mean now. Sorry for my confusion before. I think it's fine for baseline <current or future year> to fallback to the latest release of each browser in the Baseline core browser set. I could see that being kinda useful for a forward–looking project (e.g., you're building a demo of some new thing that is not yet Baseline but will be in the following year).

Eventually baseline <current year> will mean something more specific (when web-features is better at keeping up with the platform—much like the general case for prior years), but right now approximating to the latest release makes sense.

[ai]

Do we have user stories? Who, how and why will use it?

baseline 2024—how developers will specify year? What reasons they will use?

If you plan to use it in your config, how you can see the full version of config?

In the past we added many queries to Browserslist but almost nobody use them. So we need to think about it for next queries.

[romainmenke]

I think there are roughly these cases:

Case 1:

We have a project without specific support requirements.
We want the project to work well for most users in most browsers.
We don't have exact statistics or knowledge about our users.

We want tools to help us achieve these vague requirements:

• by automatically applying polyfills
• by giving feedback on features which aren't safe to use yet.

Setting baseline widely supported will give us a good starting point.
Something we can use during development.

We can adjust where needed after launch if we receive feedback.

---

Case 2:

We need to communicate with clients about support requirements and goals.
Browser versions, polyfills, interop, ... are too many technical aspects for most clients.
We use Baseline as a communication tool with clients.

We can say to clients: "We use Baseline" and they can quickly look this up and gain an understanding of what this will mean.

We want tools to help us realize what was agreed upon with clients:

• by automatically applying polyfills
• by giving feedback on features which aren't safe to use yet.

---

Case 3:

We have an internal tool/project.
We know that all users are always on the latest version of a major browser.

We want to use the very new features as this project is a good way to gain experience with new tech.

Setting baseline newly supported ensures that feature without interop receive polyfills.

I think it is fine to not support this, users can use last 1 version

---

I started writing a user story for baseline YYYY and then I realized that I couldn't really come up with one :D

I think that baseline YYYY is really useful on documentation pages like MDN, but do we really need it in tools like browserslist?

You would only use baseline YYYY if you know that you need to support exactly those versions that came out at the end of that year. Why would you not use existing queries to list those versions directly? Why would you not use a since YYYY query?

Does anyone have a user story for baseline YYYY in the context of browserslist?

[ai]

We want the project to work well for most users in most browsers.

I highly against using Baseline for “just a default for people who don’t want to go deeper”.

Baseline contains only browsers popular in US and this US-centrism is against the core idea of Browserslist (to fight with discrimination people by browsers; like Opera browser was ignored by US).

The current defaults fits much better with mixing market share (> 0.5%), Firefox ESR, adding latest version of all browsers to keep browser diversity (but removing dead browsers).

We use Baseline as a communication tool with clients.

Yes, it is an interesting example. Do we have real cases of it? Maybe somebody mention in slides, etc?

The main problem here is that Baseline works in opposite direction—a way to think about features, not browsers. Maybe nobody used it for target browser and we will increase project’s maintenance without giving tool which people use.

I think that baseline YYYY is really useful on documentation pages like MDN

BTW, I really like this idea. Often I need an answer for “when this feature was widely available” and not I need to google browser’s versions release dates.

Why would you not use a since YYYY query?

Yes, I think since YYYY is much easier to understand (just a release date) where baseline YYYY uses more complex logic (YYYY.1.1 - X month).

[tonypconway]

The first thing I'll say is: browserslist is not the only tool where we think Baseline support can/will be useful, but it is one of the more important ones because it's so widely used by packagers/polyfillers/linters.

We're currently working with analytics and RUM providers to get Baseline support built into their tools. One of the end goal is that developers can look at a simple report for an existing site and say "oh, if I target baseline widely available I'll hit 96% of my users; if I choose baseline 2021 I'll hit 99%". So instead of basing it on Statcounter for a particular region, or globally, they're basing it on their real user data. A technology website in the US may have a much more up-to-date set of browsers than the DMV. I've had one major news org have told me that they could feasibly set different Baseline targets for their News and Sport sites (more recent, probably widely available) compared to their kids content (annually reviewed but probably around baseline 2019 right now) because a lot of users on the kids sites are using hand-me-down tablets which are stuck on older version of iOS/Android.

So I would broadly agree with @romainmenke 's Case 1 for a totally new site, but I would propose Case 1a for existing sites:

We have a project without specific support requirements because it was too complex to decide one, or existing support requirements that require lots of discussion and manual reporting.
We want the project to work well for most of our user base.
We do have exact statistics and knowledge about our users because we have user agent data in our analytics or RUM tools.

We want tools to help us achieve these requirements:

by automatically applying polyfills
by giving feedback on features which aren't safe to use yet.

• potentially suggest features/patterns we could use that we aren't using already.
  Setting baseline widely available, or the Baseline year that meets our minimum user support requirements.
  Something we can use during development.

We can adjust where needed after launch if we receive feedback, and review/change easily as our analytics tells us to.

I agree with you that Baseline could be seen as US-centric, especially the original definition, although I don't think that's so much the case since the definition was changed:

• Opera and Samsung Internet both run on Blink. A major motivating factor for updating the Baseline Widely Available definition last year from "last 2 versions" to "30 months ago" (thank you @romainmenke for the feedback on this) was to allow time for a feature to land in Blink, that version of Blink to be adopted by the browsers that incorporate it, and those versions to filter out to end users. We've even discussed having a version of the data that @ddbeck mentioned in Baseline query #771 (comment) that maps Baseline years to the underlying engines using the engine and engine_version fields from MDN browser-compat-data where it can be mapped to an engine from the core browser set, as Akamai do to generate their Baseline support tables in RUM Archive (mapping logic here). Let us know if you think that would be useful, we'd be happy to work with you on it.
• If you're looking at your actual user data and see that Widely Available doesn't serve enough of them, then you can pick the year that does.
• Opera Mini is an unusual edge case, in that it doesn't work like other browsers.

As for Case 2, we've already seen web agencies adopting Baseline in their public browser support statement, for example Clearleft. We're also seeing frameworks move to use Baseline as their yardstick for feature adoption, e.g. Nuxt. I've also had a very popular CMS tell me they are interested in using either Baseline Widely Available or a specific year on their documentation pages and in their dev workflow to simplify their current browser support messaging. So in answer to

Do we have real cases of it? Maybe somebody mention in slides, etc?

Yes, people are starting to do this or are waiting for better tools support to do this.

Agreed on Case 3, I don't see newly available being that useful for now, although it might be something people look to use in the future if they are trying to be at the very bleeding edge. In any case, the newly available widget is fairly explicit that you should approach those APIs with caution, build in fallbacks and look for progressive enhancement opportunities if you're adopting them. last 1 version is effectively the same thing, so there's no need to duplicate.

Finally

Yes, I think since YYYY is much easier to understand (just a release date) where baseline YYYY uses more complex logic (YYYY.1.1 - X month).

Once web-features is complete, you won't need to calculate this anymore, you'll just be able to look at the data and deterministically say which is the earliest version of each browser that supports baseline YYYY. From a devex perspective, it's a lot easier to then say "I'm can use features from the Baseline 2020 set" and determine which features they are in e.g. MDN docs than it is to say "I support Chrome releases after 2020.1.1, Safari after 2020.1.1, etc" and then having to figure out which versions those are, keep that list in your head, and scroll down to the bottom of every page of documentation to cross reference that list against the compat table. So just saying "use since YYYY" isn't a useful solution if somebody has decided that their feature adoption strategy is "Baseline YYYY-1", because there will be features that were interoperable in earlier versions that then get unnecessarily polyfilled/red squiggles/build errors etc.

Ideally, Baseline WA or Baseline YYYY act as both a guardrail to stop you using features that are too new and/or polyfill ones that can be polyfilled, but also to encourage you to use features that you might not have adopted before, provide clarity when you see those features on Twitter/Mastodon/YouTube/tech blogs about whether they're ready for you to use.

I'm on parental leave from next Monday until end of August, but I'll be peeking in on this periodically. @ddbeck and @atopal are both around and happy to chime in more.

[ai]

@tonypconway honestly, your answer about US-centric problem made me worry even more.

Is it possible for Baseline team to speak with different communities to devel a proper rules?

I can’t talk for everyone else, because I definitely don’t know enough from browers in different countries.

• I would start from speaking with communities from: China, India, Nigeria, Maghreb region (in my very limited experince those areas are the most different in tech choices from average Googler view).
• Browsers which I worry more: KaiOS, Samsung, UC Browser. There were many Chinese browsers, we need an investigation what browsers list is actual right now since many of them died.
• Browserslist is used not only in polyfills. For instance, some users use it to generate User Agent regexp to show Your browser is not supported. We still need to return the name of all browsers (we can’t just return specific version of chrome thinking that UC Browser is just “a copy” of some Chrome version).
• I think about Browserslist config also as a documentation for developers of what do we support. It is also mean that we can’t just return US browsers. For instance, KaiOS is not just specific Firefox version. We need to test this platform separately.

I agree that webdev platform needs some new standards about target browsers and browser support. But I see in the current approach a very dangerous way to discrimination.

As for Case 2, we've already seen web agencies adopting Baseline in their public browser support statement, for example Clearleft. We're also seeing frameworks move to use Baseline as their yardstick for feature adoption, e.g. Nuxt.

Interesting examples, thanks.

Agreed on Case 3, I don't see newly available being that useful for now, although it might be something people look to use in the future

Hm, maybe I know some theoretical case. For instance, you are developing startup which will be available for end-user only next year. It will be better for you to support only latest browser since when the product will be releases, they will be widely available.

For instance, I am using Relative Colors in my project for that reason.

oh, if I target baseline widely available I'll hit 96% of my users; if I choose baseline 2021 I'll hit 99%

But in Browserslist we have cover 99% query which works much better. baseline 2021 will take unpopular browser from that time, while cover 99% (or > 1%) will take only popular old browsers (so we will have less unnecessary polyfills in the web).

[romainmenke]

Opera and Samsung Internet both run on Blink. A major motivating factor for updating the Baseline Widely Available definition last year from "last 2 versions" to "30 months ago" (thank you @romainmenke for the feedback on this) was to allow time for a feature to land in Blink, that version of Blink to be adopted by the browsers that incorporate it, and those versions to filter out to end users.

I agree that the current definition is an improvement but it is not neutral :)
It still favors western browsers and users.

Because of the delay in engine version adoption there will still be a gap between Chrome and Samsung Internet.

A user with a browser version of Samsung Internet that is 29 months behind will fall outside of the Baseline definition while a user of Chrome with the same delay will not. Same for all the other browsers based on Blink, Gecko and Webkit. The core browsers will always be ahead of the other vendors with the same engines. And the core browsers happen to be the western browsers :)

I fully understand @ai's concerns about this and if browserslist aims to be neutral and promote supporting all users equally, then maybe it should not adopt the current baseline definition? There is no crucial need for browserslist to support baseline :)

[ddbeck]

My apologies for taking so long to come back to this and to follow up in Tony's stead. It's been a busy few weeks. 😅

I want to respond to a couple of key things:

Tony hinted in this direction, but I'd like to make it really clear: first and foremost, Baseline is a communications tool. I know it won't ever be as precise as targeting some specific set of browsers derived from analytics data for a specific application (assuming it exists—there are lots of developers who won't or can't engage with that). But since it appears on MDN, caniuse, and elsewhere, Baseline can offer something that a more precise "X% of users" can't: a shared terminology for coordination.

"X% of users" encompasses lots of nuance and context: which users, how you measure them, what you think of users you can't or won't track, the browser releases that number translates to, and so on. Absent that context, you can't really know when you're talking about the same X% (and odds are you aren't).

So even if Baseline doesn't directly capture the audience I'm building for, it can still be a useful tool for collaborating with colleagues as a shorthand. "We are targeting the Baseline YYYY feature set" is rather more portable and transparent than having to do a fresh analysis with your analytics when you see an unfamiliar feature on MDN. That's the chief difference between baseline YYYY and cover X% and I why I think it'd be great for browserslist to support both.

Second, I appreciate hearing about Baseline's limitations—it's interesting to know which ones folks notice and which ones they don't (and the rarer limitations I didn't even know about!).

To briefly acknowledge a raft of issues: there was a very long process to come up with the current definition (it was one of the most meeting-filled 6 months of my career). We considered things like including more browsers or deriving the set of included releases from StatCounter data. I think the governance team still has a lot of interest in increasing Baseline's breadth, but data sources backing that up need to be sufficiently accurate, trustworthy, and transparent. That's just not the world we live in (yet).

That said, we put in place a process to periodically review and revise the definition. This is why we don't strongly emphasize the 30-month time horizon: the definition should adapt to changing developer needs and our ability to report on those things. (Someday, I hope we can even de-emphasize the specific browsers—the dream would be for developers to think about the web instead of browsers.)

I think we'll eventually get closer to that idealized version of Baseline, tethered closely to usage data and developer surveys and the like. That's also why I'd like to see Baseline get into more places, like browserslist, so that when we do refine what Baseline is capable of (in incremental ways like regular data updates or big ways like new data sources), developers will get the benefits in lots of places at once: their docs, their editor, their build tools, dependencies, and so on.

[ai]

That's also why I'd like to see Baseline get into more places, like browserslist

I am open to Baseline in Browserslist only when non-Western communities will agree that this communication tools works for them and not only for Western developers speaking between each other.

Just ask them to join your discussions (I believe any big team have a lot of people from Chinese-speaking, Latam and Magrib).

As I told right now I do not believe that this communication tool was created thinking about this problem. So I believe that right now Baseline will force communication to think less about non-Western markets which is against the philosophy behind Browserlist.

But I am not against the idea of Baseline, and when this problem will be fixed (just by communicating with non-Western communities), I am fully open to help and support.

[ddbeck]

communicating with non-Western communities

This work has been in ongoing, though @atopal has been much closer to it than I have been. He was in India just last week and recently in China talking to developers. He's told me some interesting things he's learned in this area (e.g., some regional developer communities don't have a strong interest in interoperability, due to local super app or OS monocultures). I'll ask him to chime in in more detail about what he's learned.

[just-jeb]

I can't speak for all non-Western developers, but I can offer the perspective of a company that operates in such markets.
At Wix.com, we have users all over the world, including in non-Western countries.
We see Baseline as a convenient and effective way to represent and communicate supported browsers, both from the users' perspective and the developers' perspective.
We don't have a separate codebase for specific regions, and if we can't use a feature due to some countries not being up-to-date in terms of browser versions, we won't use it at all (or we'll use a polyfill).
If Baseline were supported in Browserslist, it would help us define a company-wide set of supported features and provide a single reference point that could also be easily communicated to the end user.

[romainmenke]

Thank you for these insights @just-jeb,

if we can't use a feature due to some countries not being up-to-date in terms of browser versions, we won't use it at all

Are these features that fall within Baseline Widely Available?

Can you share how often this happens? (even a vague estimate would be informative)

---

It isn't really clear from your comment if Baseline Widely Available aligns with the browser versions used by visitors of wix.com or if Baseline Widely Available is the support target.

Are there browser versions you still support for specific regions that fall outside the current definition of Baseline Widely Available?

[just-jeb]

It's not that we regularly check what feature we want to use and then assess whether we can or not. Usually, it's the other way around—our devs want to use something for a certain product feature, start checking around our supported browsers, and then find out they can't use it.

We also don't look at specific regions when we stop supporting certain browser versions. It's usually just about the amount of traffic.

Currently, this is how it works: we have this Supported Browsers article, which serves as a source of truth for both our users and our devs. This article is not updated often, and the process is cumbersome because it includes traffic analysis by browser versions and involves some high-level decision makers.

Often, when someone gets around to updating this article, the listed versions represent a very small amount of traffic (which basically means we could have used certain features, but we didn’t, simply because no one cared to update the article). Our infra team (which is responsible for the build chain and the browserslist used across the company) also uses this article as the source of truth.

Hence, I can confidently say that officially we support browsers that fall outside of the Baseline Widely Available category—not because we want to support them, but because the article needs to be updated 🙂.

This is what we'd like to solve with Baselines—we want to use the same Baseline in the article, in Browserslist, and in our code for feature detection. Then we wouldn't need this whole process: the article is always up to date, the browserslist is always up to date, and all developers/users need to check is whether a feature/browser version is part of the specified Baseline.

Hope this makes sense 🙏.

[romainmenke]

Still kind of vague to me if you are saying that Baseline would help to streamline an internal process or that Baseline Widely available is known to be sufficient for non-western regions. I imagine it is both but that makes the message less clear ;)

Between the lines I am reading that you don't know that is sufficient without first doing a full analysis of traffic. And that not needing to do such analysis is why you want to use Baseline in the first place.

I think we need to clearly separate:

• want to use Baseline
• already using an equivalent definition as Baseline in practice and knowing that it is sufficient for all regions

---

You can already define an equivalent browserslist query today.

For example something like:

chrome > 0 and last 2.5 years,
safari > 0 and last 2.5 years,
firefox > 0 and last 2.5 years,
edge > 0 and last 2.5 years,
ios > 0 and last 2.5 years,
and_chr > 0 and last 2.5 years,
and_ff > 0 and last 2.5 years

Doing so might be a good way to gather more data for wix.com on how this works for various regions.

[donmccurdy]

As an author of JavaScript libraries published to npm, I'd be very glad to see Baseline added! Not because it's necessarily what authors of web applications should all be using (that does require some consideration of your users and traffic), but because Baseline represents a pretty good snapshot of "modern JavaScript" as an authoring language and lets me more easily and consistently publish code to npm that is neither too old nor too experimental. As it is, I find it difficult to achieve that balance. See The state of ES5 on the web for background on how/why this is useful to package authors.

[lachesis]

In reality Baseline excludes a lot more people than it includes.

Is that really true? More users on the internet are stuck on browsers >30 months old than are running the current?

[romainmenke]

It was true for the first definition of baseline as it existed when I posted that comment. There is a totally new definition now and luckily it is no longer true today 😊

[ai]

More users on the internet are stuck on browsers >30 months old than are running the current?

The problem of Baseline is that it uses only selected list of browsers made by big US companies (Chrome, Firefox, Safari, Edge).

For instance, there is no UC Browser in Baseline, but it is very popular worldwide.

[ai]

It was true for the first definition of baseline as it existed when I posted that comment. There is a totally new definition now and luckily it is no longer true today 😊

What were the changes?

I see the same 4 US’ browsers on https://web.dev/baseline

[romainmenke]

The set of browsers didn't change.
But the versions included did.

The original definition was only latest 2 versions.
The current definition is last 2.5 years.

[extra808]

there is no UC Browser in Baseline,

It's a Chromium-based browser with a relatively slow release cycle, right? Features in Baseline Newly Available may not be in UC for a while but once a feature reaches Widely Available, it will have been in Chromium for at least 30 months, if they were the last to implement it. I think the "Widely Available" definition exists not only to account for people who are slow to upgrade the browser on their device but also for browser makers who use one of the engines from the browsers that are in the Baseline list.

but it is very popular worldwide.

Is it? StatCounter Global Stats says (the data CanIUse uses and therefore Browserslist) it's 1.11% of global browsers. Even looking only at Mobile & Tablet in Asia, it's 3.04%, less than Samsung Internet, Safari, Chrome (it's declined a lot from its peak in 2016). I know reliable browser market share data is hard to come by, maybe other sources have higher figures.

[pepelsbey]

Here’s some brief research. The current UC Browser 13.7.8.1322 version is using Chromium 100, according to the UA:

Mozilla/5.0 (Linux; U; Android 12; en-US; Pixel 3a Build/SP2A.220505.008) AppleWebKit/537.36 (KHTML, like Gecko)
Version/4.0 Chrome/100.0.4896.58 UCBrowser/13.7.8.1322 Mobile Safari/537.36

The lag between Chrome 100 and Chrome 129 is 29 months. It’s funny: it takes 30 months or 2.5 years to get to the “widely available” Baseline status. So, adding the UC Browser to Baseline would keep many features at bay for a long, long time.

Imagine no inert attribute, no container queries, no :has, no MathML, no CSS nesting, etc.

[ai]

It's a Chromium-based browser

If Baseline defines browser engines (like all Chromium-based browser is hidden inside Chrome), why we have Edge in explicit list?

Having Edge but avoiding explicitly adding other Chromium-based browser is defiantly a way of discrimination for me.

StatCounter Global Stats says (the data CanIUse uses and therefore Browserslist) it's 1.11% of global browsers

Yes, maybe pretty popular is better wording.

For instance, Firefox has around 2.3 %. We have it explicitly in the list, but not UC. In Asia Edge has the same 3% as UC, but we have Edge and not UC in the list.

1% is a lot in the context of global market share. 500M users.

Imagine no inert attribute, no container queries, no :has, no MathML, no CSS nesting, etc.

Unfortunately, diversity is always less convenient in practical short-term terms.

But the same Baseline will block the market from accepting future more advanced browsers (by keeping eyes only on US browsers from big companies).

If we want a way to define browsers with modern features, the allow-list of 4 browsers is not a way. In Browserslist there is more a better way to define target browsers by features, etc.