Baseline years discussion

[captainbrosset]

For context, see #3245.

This PR, at one point, added some content to describe the notion of Baseline year.

This issue is a place for folks to discuss about this notion.

[foolip]

Here's my attempt at a summary:

In #3245 @tonypconway proposed this definition of "Baseline years"

All the features that were Newly available at the end of a given calendar year can be described as being in that Baseline year's feature set. For example, overflow: clip became Newly available in September 2022, so it is part of Baseline 2022 and all subsequent Baseline years.

Notions of Baseline years are already out there. @atopal provided examples:

• MDN shows the year from baseline_low_date in the widget, for example abs() shows as "Baseline 2025 Newly Available"
• https://webstatus.dev/ has "Baseline 2025" and so on as saved searches in the sidebar
• https://chrome.dev/google-analytics-baseline-checker/ helps you pick a Baseline target, expressed as a year

@jgraham pointed out some nuance to a definition, which I'll distill as:

• Having "Baseline 2024" refer to features that work in some browsers released in 2024 but not all, can be seen as an off-by-one error.
• In some contexts "Baseline 2024" refers to only the features that became Baseline in 2024, and in others in includes all older features as well.

Finally, there was discussion about how a concept like this can help developers, or if it suggests that our definition of Baseline Widely Available is not conservative enough.

Should we define something officially?

[rviscomi]

Notions of Baseline years are already out there. @atopal provided examples:

Just to add a few more examples, VS Code and many other IDEs that depend on its language servers (Cursor, Zed, etc) use the "Baseline since YYYY" terminology:

JetBrains' entire suite of IntelliJ-based IDEs (eg WebStorm) also use the "Baseline since YYYY" terminology:

ESLint for CSS, Stylelint, and HTML ESLint all accept Baseline years as Baseline targets, eg:

module.exports = {
  rules: {
    "@html-eslint/use-baseline": ["error", {
      "available": 2022
    }],
  },
};

And of course, the PR that spurred this discussion browserslist/browserslist#903 adds baseline YYYY support to Browserslist.

[tonypconway]

Thanks @captainbrosset @foolip and @rviscomi for pulling this conversation together.

As Rick's pointed out, the concept of Baseline 20XX is already implemented in tools created by the wider community, and it's also implemented in tools owned by this org, specifically baseline-browser-mapping and its dependent browserslist-config-baseline - the latter of which we will be able to deprecate when the PR in browserslist itself lands, as it offers the same options. I haven't seen any objections to the availability of years in this org previously.

I've spoken to several business either directly or through members of my team over the last year and the majority of teams we've spoken to who see the benefit of Baseline have looked at their data and decided that Widely available is a suitable criteria for feature selection for them, and that it's also a suitable replacement for their minimum supported browsers table.

However, a handful of partners - who tend to be much larger orgs, unsurprisingly - have said that Widely available will be slightly too ambitious for them because:

• They have very strict rules about the minimum number of users they can fully support because of their public position. For example, one public service broadcaster explained to me that they have a very large proportion of older users who are much more resistant to upgrading their Android device and so fall out of Chrome support, and/or elderly users and children using second hand iPad's which are no longer receiving iOS updates and are therefore stuck on an older version of Safari.
• There's just slightly too much revenue attached to browser versions that don't quite meet Widely available, but they still really want a simplified way of talking about which features they use and communicating that to their development teams and toolchain.

There aren't a lot of orgs where this is the case, but they are of significant enough size and footprint that I think

There's an even smaller subset of smaller orgs in very technically advanced markets where something like Baseline 2023 - which currently includes features that are Newly but not yet Widely - would be suitable, but Widely would probably work great for them as well.

@jgraham in the Matrix chat:

I think this discussion strongly suggests that MDN and others should exactly reverse what they're currently doing and only put the years in the banner for "Widely Available" features, and not for "Newly Available".

I don't disagree with this! Or just have 20XX on any feature that is in Baseline.

What I'm concerned about is that so far there are no examples of benefits to web authors from creating additional annual "baseline" statuses for things that are "Newly Available".

I agree there's some devrel interest in telling people which features have become available on the platform in some defined timeframe, but I don't think that requires WebDX to define the timeframe of interest of reify it into groups.

I think the org needs I mentioned above respond to these points, but to clarify: people writing about how the web is evolving are not the only audience for Baseline, and one of the big audiences has told us that they want to be able to frame feature sets in this way to simplify decision making in their teams. Much of the time, they're still looking at adopting features they weren't confident adopting before, because their old minimum of "Safari 12, Chrome 70" or "ES5" become obviously outdated when they are prompted to look at the numbers again knowing that they'll get a more easily discussed and enforced threshold.

Finally, in all the conversations we've had with folks, Baseline 20XX has been understood to mean: all the features that were interoperable (i.e. Newly available) at the end of 20XX. Personally, I would tweak the filters in webstatus.dev so that they have the earliest relevant start date possible, so the 2025 filter would be:

baseline_date%3A**2015-07-01**..2025-12-31

Rather than:

baseline_date%3A**2025-01-01**..2025-12-31

You'll still get the most recent features of that year at the top of the search, but it'll be easier for developers to tack on other search filters after and have them apply to all relevant features, not just the ones that became Baseline in that year.

[jgraham]

Is the definition of "baseline" in tools like VSCode "widely available" or does it also include "limited availability"? If it includes both, I consider that to suggest that describing "newly available" as a "baseline" status was a mistake.

I think for things that are "widely available" having a way to be more conservative makes sense e.g. if you want to support older browsers, so you aren't prepared to use any web technology that hasn't been in new browser releases for at least 4 years using "Things that became newly available in 2021" as your standard makes sense.

On the other hand, for things that are newly available, I don't see how years are useful to authors. A single year covers 40% of the time to "widely available", which seems like far too much margin of error to be the basis of a useful decision, because the availability will shift so much in that time. For example, something that became "newly available" last year may or may not be available in the latest Firefox ESR and may or may not be available in Chromium browsers that are not always up to date with the latest release (e.g. Samsung Browser). Even if I'm very confident that my site biases toward users with up-to-date browsers (maybe it's desktop-only, doesn't have enterprise usage, etc.) the year-based system wouldn't be useful to define a more aggressive threshold than "widely available" (it doesn't correspond to "last two releases" or "last 12 months" or anything else that developers might want to target).

[tonypconway]

Is the definition of "baseline" in tools like VSCode "widely available" or does it also include "limited availability"? If it includes both, I consider that to suggest that describing "newly available" as a "baseline" status was a mistake.

VS Code and WebStorm both show you the appropriate badge for the feature. If the feature is Widely available, green tick; Newly, blue tick; not part of Baseline i.e. Limited, orange X. The "Baseline since..." date in both tools is the year the feature became interoperable i.e. Newly available. This is really helpful if you're targeting a year rather than Widely! I did open a PR on mdn/fred that proposed showing years for Widely features as well, although I agree with Daniel's point that we need to find a better way to talk about the old, pre-Edge stuff rather than just saying it's Baseline 2015 (even though it is Baseline 2015, 2016, and so on, unless it gets deprecated).

Even if I'm very confident that my site biases toward users with up-to-date browsers (maybe it's desktop-only, doesn't have enterprise usage, etc.) the year-based system wouldn't be useful to define a more aggressive threshold than "widely available" (it doesn't correspond to "last two releases" or "last 12 months" or anything else that developers might want to target).

I don't think anyone is advocating for developers to use a target that is more recent than Widely. But you most certainly can talk about Newly available features as being part of a Baseline year. Whether you should or not is indeed a different matter. I think it could be a useful indicator of how new something is, so that folks targeting Widely can get a gut check on whether something is worth thinking about in their planning process. If I'm looking at a feature today and it's Newly (2023), that's more worth scoping for use in the coming months than a feature that is Newly (2025). But I don't have super strong feelings on this point, happy to hear what others think.

[jgraham]

VS Code and WebStorm both show you the appropriate badge for the feature.

The concern I have is that "Baseline" already sounds like a status, and indeed was originally intended as a status, but now is used just as a branding and the actual statuses are "Newly Available" and "Widely Available" (plus "Limited Availability"). So "Baseline since…: for "Newly Available'" in editor UI is confusing because it's somewhat contradictory: something that's "Newly Available" isn't currently part of the (small-b) "baseline" web feature set that authors can safely depend on. A more reasonable presentation would be "Newly Available, expected Baseline in N months".

That's not directly related to years, just another example of where we've ended up with suboptimal presentation of the data due to the conflation of things that are newly available in the latest user agents, and things that are actually baseline in the sense of "safe for authors to use".

If I'm looking at a feature today and it's Newly (2023), that's more worth scoping for use in the coming months than a feature that is Newly (2025).

I think it makes some sense for clients to provide an informative date when something became newly available. But for this case a year granularity doesn't make any sense; things that are Baseline 2023 and 2025 might be slightly more than 12 months different, or almost 24 months different in when they will be regarded as "widely available'. I think there's a use case for "show me all the things that should become widely available in the next 6 months", but years aren't suitable for that.

[rviscomi]

A more reasonable presentation would be "Newly Available, expected Baseline in N months".

A feature that is Newly Available is already Baseline, according to the status definition. Or do you mean "expected Widely Available in N months"?