Baseline query
galvarez421 opened this issue · comments
It seems like it might be useful to provide a "baseline" query to account for the target browsers of https://web.dev/baseline/!
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?
Waiting seems fine to me, especially since users already have the ability to query for those browsers as you described!
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.
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.
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.
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.
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.
@romainmenke how we can select browsers? Can you show an example?
I do not see any logic in queries like Widely available cssmodules
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
- take the last release date of all versions that initially added support
- Firefox 113 was last at
2023-05-09
- Firefox 113 was last at
- 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
- 30 months since last release is
- 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.
@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.
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.
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.
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:
baseline YYYYwould return all browser versions up to the end of the specified calendar year.baseline widely availablewould 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.