Baseline: Don't just say "Baseline" on MDN, say "Baseline 2023"

[dfabulich]

Apropos issue #174, some developers will want to be really careful about browser support. Some people will say "2+ major versions is good enough for me," whereas others will insist on 3+ major versions, or 4+ major versions.

Currently, the MDN treatment for baseline just says "Baseline: Widely supported" https://developer.mozilla.org/en-US/docs/Web/CSS/grid

According to https://web.dev/baseline/ the plan is for Baseline to have years associated with them, allowing us to talk about "Baseline 2023," "Baseline 2024" etc.

So instead of "Baseline: Widely supported," I'd prefer it if MDN said "Baseline: Widely supported since 2018". (It shipped in Safari 10 in 2017, but didn't have 2+ major versions until Safari 11 in 2018.)

That way, we don't have to argue about whether a feature should "really" be Baseline 2023 when it only appeared in Safari 15.4 in March 2022. If MDN says "Baseline 2023" I could say "Hmm, that's still too fresh for me, I'll wait until 2024 or 2025". But CSS Grid would say "Baseline 2018," so I could confidently say, "Great, that's plenty long ago, I'll start using it now."

[romainmenke]

I like this!

It brings back a lot of room for nuance that is now lost.

You can still say "it's in any baseline, it's stable and ready for learning".
And projects can adopt a strategy of N years in a baseline.

[stefanhamburger]

It worries me that https://web.dev/introducing-baseline/ mentions "Baseline 24" when it would be much clearer to use "Baseline 2024". Surely, we've learned enough from history and there's no need to abbreviate the year number.

On the topic at hand, I don't mind the "Baseline" term too much, e.g. in my company's support contracts for web products with ongoing maintenance we'd write "Baseline" and not "Baseline 2023", since that term better conveys our commitment to continuous product support, and our forward-looking vision of keeping future platform features in mind, instead of restricting it to one particular browser version. And outside of Firefox LTS, it's really not possible to target a specific version anyway.
I also don't see how you can reduce it to a single year; there are 12 major Chromium/Firefox versions in a year, each of which may add (or remove!) features, so it is easier to just refer to browser versions; Baseline year numbers are a source of confusion.

[dfabulich]

On the topic at hand, I don't mind the "Baseline" term too much

It is easier to just refer to browser versions; Baseline year numbers are a source of confusion.

I don't understand this feedback, especially these two lines juxtaposed.

If Baseline year numbers are a source of confusion, (because browser versions are clearer) then "Baseline" without a year number must be even more "confusing," right?

When you say, "It is easier to just refer to browser versions; Baseline year numbers are a source of confusion," it sounds like you might be arguing against the whole "Baseline" project in its entirety.

Someone could argue, "Indeed, it is painful to track individual browser versions, but that's just the way the world works. Using 'Baseline' and/or 'Baseline 2024' can't improve the situation; it will just make everything more confusing."

But I can't understand an argument that referring to browser versions is better than "Baseline 2024" but worse than "Baseline" with no year. However confusing "Baseline 2024" is, "Baseline" will be at least as confusing as that, if not more so.

[stefanhamburger]

To clarify, I can see myself saying: “We ensure that our web products are and will always be Baseline-compatible.”
And I can see myself saying: “Our web products are compatible with the current browser versions, Firefox 113 and Chromium 113 (and the previous month’s version).”
Both statements are in line with our current workflow, aka we are testing our products in the current browsers, and we read the browser’s changelogs. So if MDN displays “This feature is part of Baseline”, I know I can use the feature.

On the other hand, if MDN displays “This feature is missing from Baseline 2023”, the information is meaningless. I don’t care about the status from many months ago when “Baseline 2023” was defined, I want to know the current status. And for that, I’ll need to look at the detailed compatibility table (= the browser versions).

I have other concerns: If “Baseline 2023” becomes widespread and e.g. added to the Lighthouse score, customer will demand that our products are “Baseline 2023”-compatible. And then we need to explain why this is meaningless since browsers are updated monthly and no one has such an old version. If we cannot convince them and they demand proof, it is very difficult to (convince our IT department to) install this old browser version.
Therefore, I’d prefer to drop the year numbers altogether and only talk about “Baseline”. I’m fine with sentences like “This feature has been part of Baseline since May 2023” or “The following features became part of Baseline in 2023, grouped by month” because with the month (and day?) included, they are self-explanatory and don’t depend on browser makers defining an arbitrary cutoff date that should be “Baseline 2023”.

[dfabulich]

I'm still not sure I understand, but I think you and I are having a disagreement about how often end users upgrade their browsers.

If “Baseline 2023” becomes widespread and e.g. added to the Lighthouse score, customer will demand that our products are “Baseline 2023”-compatible. And then we need to explain why this is meaningless since browsers are updated monthly and no one has such an old version.

I can't tell, but I think, in these examples, you might using "2023" to stand in for "many years ago," is that right? (Or else why would you say no one has "such an old version" as a browser from 2023?)

Alternately, I think we might not be in agreement about how frequently real end-users update their browsers. Browsers do ship new releases monthly-ish (even Safari releases a new point release with new features every month or two, often with new Web API features), but end users don't upgrade to those browsers very frequently.

Maybe I'm saying something you already know, but it's quite common to see users running 2+ year old browser versions. Today, at least 10% of users can't use features shipping in all major browsers in 2022. For example, many iPhone users only update their OS annually, or less so, and some iPhones can't upgrade to the latest OS, and so they can't install the latest version of Safari without buying a new device. It's not widely known, but the same is true of Google Chrome, since Google Chrome for Android revoked support for Android 5 in 2021 and Android 6 in 2022. Anyone on Android 6 or below can't use any features released in 2023 or later. Android 6 is 1.7% of Android share all by itself, and older versions of Android are even more common, adding up to 5%+ of Android users who can't use 2023 features.

https://gs.statcounter.com/os-version-market-share/android/mobile-tablet/worldwide
https://gs.statcounter.com/os-version-market-share/ios/mobile-tablet/worldwide

If, in fact, "Baseline 2023" would only be describing browsers such that "no one has such an old version," even in calendar year 2023, then, sure, I guess the idea of defining prior Baseline years would be pointless.

But that's not the world in which I live. I have to support users running Google Chrome on Android 6. So, even though a feature may be "Baseline 2023," I can't use it yet. (I don't know your business, but it would surprise me a great deal if anyone can reliably depend on features released in 2023 in calendar year 2023, just comfortably lopping off 10%+ of their users, unless developing for enterprise users who can be required to upgrade by corporate IT policy.)

If that's what's confusing us, if you serve companies where everybody reliably has a browser no more than six weeks old, but I serve public users who may be using a phone they bought in 2017 and can no longer upgrade, then clearly the thing to do is to have you use the latest Baseline year 2023, and I'll use an older Baseline year, perhaps 2022 or 2021.

Using a Baseline year is exactly what allows us to have this conversation clearly, without making huge assumptions about what does/doesn't work for others.

• "All of my users are required to upgrade frequently, so I ship features using Baseline 2023."
• "We're a large team aiming for maximum reach, so we ship features using Baseline 2017."
• "We're a small team who wants to be able to reach 95% of our users, and StatCounter indicates that we'll be OK using Baseline 2021 for that; we hope to adopt Baseline 2022 in six to nine months."

[atopal]

@dfabulich I think it's reasonable to change the definition of Baseline so that any given feature always has above a certain threshold of coverage, eg above 95%, and that will still not solve everyone's problem, that is to be expected. If you know which browsers you need to support down to the actual version, you should not use Baseline.

Baseline is meant to be a simplified feature status, when no other overriding data is easily available. For that purpose there is value in simply stating that you'll consider Baseline features to be safe. And then it's on us to make sure that our definition does not lead to surprising results for most people most of the time (though it can not work for everyone).

[tidoust]

New Baseline definition go deployed to MDN. This issue influenced the contents of the Baseline banner, which now contains an "available across browsers since [keystone date]" message to help developers position the feature on an interoperability timeline.

[styfle]

@tidoust Looks good!

I see it on the class page here:

• class docs
• class screenshot

However, I'm wondering why don't I see it on the const page here?

• const docs
• const screenshot

[foolip]

@styfle this is because the Baseline banner is only shown when there's a feature in web-features which covers the BCD key of the page. We do have https://github.com/web-platform-dx/web-features/blob/main/feature-group-definitions/class-syntax.yml for class, but no feature covering const yet.

We're doing it like this is a way to manage the rollout, so that a Baseline status is only shown when someone has reviewed it.