- From: Schalk Neethling <volume4.schalk@gmail.com>
- Date: Tue, 15 Jul 2025 14:04:28 +0200
- To: Daniel Beck <daniel@ddbeck.com>
- Cc: Patrick Brosset <Patrick.Brosset@microsoft.com>, Masataka Yakura <myakura.web@gmail.com>, "public-webdx@w3.org" <public-webdx@w3.org>
- Message-ID: <CAGtcKu6v-=7bMJ8ELMxi3uC+4MNZvmevdFJrSLMo15p+ZU5q0g@mail.gmail.com>
I also appreciate this conversation, as I was also not aware of the additional nuance around limited availability. This also leads me to wonder whether there is a way to indicate limited availability, but the feature set is on track to be newly available, as there are no strongly held negative stances from other browser engines. The other one I have heard discussed, and which goes in tandem with this, is limited availability, but on track towards being newly available, and can also be responsibly used today, either through progressive enhancement or a solid polyfill. Something like anchor positioning comes to mind, and things like text-box-* On Tue, Jul 15, 2025 at 12:24 PM Daniel Beck <daniel@ddbeck.com> wrote: > I think Patrick's answer is a good one. I'll add a few more distinctions: > > "Limited availability" is really a shorthand for "not meeting the > requirements for Baseline." But "not meeting the requirements for Baseline" > also includes a couple of other states that the web-features data can > represent, including "discouraged" (being formally deprecated, marked > obsolete, and so on) and pending removal (e.g., DOM mutation events). > > There are also conditions we can't yet represent. Most imporantly, I'm > thinking of features where there's a negative standards position from one > or more vendors. For those cases, "limited availability" is true. But > there's also no real prospect of that feature ever becoming Baseline. > > So "Limited availability" is the most common case for non-Baseline > features, but it's not the only one. I'd discourage (pun intended) everyone > from characterizing "limited availability" as a sort of "pre-Baseline" > condition because some are post- or never-Baseline. > > I hope this helps! > > Daniel > > On Tue, Jul 15, 2025 at 9:26 AM Patrick Brosset < > Patrick.Brosset@microsoft.com> wrote: > >> Hello Masataka, >> >> Thank you for your question. It shows that we do need to clarify this >> whenever/wherever we communicate about Baseline. >> For reference, the source of truth on this is: >> https://github.com/web-platform-dx/web-features/blob/main/docs/baseline.md >> >> Baseline is a status, and it has two sub statuses. >> >> A web feature earns the Baseline status as soon as it becomes supported >> across all of the browsers from the core browser set. >> However, within this status, we differentiate features based on how long >> they've reached the status with two sub statuses. >> >> These sub statuses are called "Newly Available" and "Widely Available". >> >> >> - Newly Available is reached as soon as the feature is supported >> across all the browsers from the core browser set. >> - Widely Available is reached 30 months after that point. >> >> >> So, technically speaking, there are only two Baseline stages. >> >> If a feature is not yet supported across all of the browsers we care >> about, then it doesn't have the Baseline status yet. We call this "Limited >> Availability". >> >> Now, in practice, that means we often talk about these three things >> together: Limited Availability, Newly Available, and Widely Available. We >> often talk of these as a series of events that web features tend to go >> through during there lifetimes. >> Saying that Baseline has three stages is technically incorrect, but a >> shortcut we often take to introduce people to the Baseline concept. At >> least, I know I've used this shortcut quite a few times in various >> presentations. >> >> Do folks here think we should be stricter in enforcing the definition? >> >> Patrick >> >> ------------------------------ >> *From:* Masataka Yakura <myakura.web@gmail.com> >> *Sent:* Sunday, July 13, 2025 18:05 >> *To:* public-webdx@w3.org <public-webdx@w3.org> >> *Subject:* [EXTERNAL] Baseline stages: two or three? >> >> [You don't often get email from myakura.web@gmail.com. Learn why this is >> important at https://aka.ms/LearnAboutSenderIdentification ] >> >> Hello, WebDX! >> Hope you all having a good week. >> >> I have a quick question of the stages of Baseline. The definition on >> the WebDX website [1] says: >> >> > Baseline features are available across popular browsers. Baseline has >> two stages: >> > >> > * **Newly available**: The feature works across the latest devices and >> browser versions. The feature might not work in older devices or browsers. >> Indicated with a blue icon. >> > * **Widely available**: The feature is well established and works >> across many devices and browser versions. It’s been available across >> browsers for at least 2½ years (30 months). Indicated with a green icon. >> > >> > Prior to being newly available, a feature has **Limited availability** >> when it's not yet available across all browsers. >> >> while web.dev Baseline page [2] says: >> >> > Baseline has three stages: >> > >> > * **Limited availablity:** The feature is not available in all the core >> browsers. >> > * **Newly available:** The feature becomes supported by all of the core >> browsers, and is therefore interoperable. >> > * **Widely available:** 30 months has passed since the newly >> interoperable date. The feature can be used by most sites without worrying >> about support. >> >> and I wonder which to follow when I explain Baseline to people. >> >> I really like WebDX's explanation of "across browsers" as it captures >> the essence of "Baseline." However, when I think about explaining >> Baseline in slides or bullet points, presenting it with three distinct >> labels feels much easier to me. >> >> So, what do you folks think? What's the group's perspective on this? >> >> Thanks a lot, >> Masataka >> >> [1] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb-platform-dx.github.io%2Fweb-features%2F%23how-do-features-become-part-of-baseline%253F&data=05%7C02%7Cpatrick.brosset%40microsoft.com%7C675ba75e203d4c9491ba08ddc2273135%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638880196686288078%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=%2BYy7k%2FWHo87qFF2T1phSf3ZTO214AU44Vt%2Bu5jiFhSY%3D&reserved=0 >> <https://web-platform-dx.github.io/web-features/#how-do-features-become-part-of-baseline%3F> >> [2] >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fweb.dev%2Fbaseline%23how-do-things-become-baseline&data=05%7C02%7Cpatrick.brosset%40microsoft.com%7C675ba75e203d4c9491ba08ddc2273135%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638880196686302039%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=IrwpDNOSIMryyncnKR1hJnIWfKro3a9Lse9WL%2FpSaec%3D&reserved=0 >> <https://web.dev/baseline#how-do-things-become-baseline> >> >> -- >> Masataka Yakura >> <myakura.web@gmail.com> >> >>
Received on Tuesday, 15 July 2025 17:00:31 UTC