"Limited availability" when not actually available?

[SachaG]

I found the label "limited availability" a little bit confusing for some features that are not available in any browser:

Shouldn't there be a "not available" baseline stage? Sorry if this is not the right place to kick off this kind of discussion, but I just wanted to make a note of it somewhere. Feel free to close if not relevant.

[captainbrosset]

This is very much the right place for this discussion. Thank you for starting it.
I agree that this is something we should start thinking about, and I don't recall other issues/discussions on this topic.
Baseline only has 3 stages:

• false aka "Limited availability"
• low aka "Newly available"
• high aka "Widely available"

I think our starting assumption was that all features would at least be available in one browser.

As time goes by, we're seeing more and more use cases for creating web-feature entries very early in the repo, even if that means they're not yet available anywhere. For example, when an intent to implement email is sent by a browser vendor is a good time for us to "reserve" the feature identifier in the repo. Another case is when a feature is available in one browser, but only behind a flag, for early experimentation.

Here are the features in this category, unless I missed some:

• https://web-platform-dx.github.io/web-features-explorer/features/background-clip-border-area/

  Coming to Safari soon, it's already in TP.

• https://web-platform-dx.github.io/web-features-explorer/features/device-posture/

  I'd need to dig in this more. I know Diego, from my team, had worked on it at his time at Samsung, and that Edge and/or Chrome have implemented most of it in Chromium. Not sure why this is all red.

• https://web-platform-dx.github.io/web-features-explorer/features/element/

  Supported in Firefox, with the -moz vendor prefix. Maybe worth an editorial override?

• https://web-platform-dx.github.io/web-features-explorer/features/fit-content-function/

  This one is very specific to the fit-content function when used outside of grid, which only Firefox supports, but behind a flag.

• https://web-platform-dx.github.io/web-features-explorer/features/font-variant-emoji/

  Firefox and Safari support it behind a flag.

• https://web-platform-dx.github.io/web-features-explorer/features/hanging-punctuation/

  Safari has partial support.

• https://web-platform-dx.github.io/web-features-explorer/features/line-clamp/

  This one is particularly confusing because:

  The prefixed -webkit-line-clamp is widely supported but only works with -webkit-box-orient: vertical in combination with display: -webkit-box or display: -webkit-inline-box

  So, really, line-clamp is widely available, but you have to remember to use the prefix and the other box-orient property too.

• https://web-platform-dx.github.io/web-features-explorer/features/masonry/

  Masonry has been on a roller coaster for the past 7 years at least. It's been implemented in Firefox first, but only as an experiment. Spec and implementation work has recently picked up again, but the spec is completely changing.

• https://web-platform-dx.github.io/web-features-explorer/features/overflow-clip-margin/

  Safari has no support, but other browsers do, except that it's partially implemented only. It only works under certain situations.

• https://web-platform-dx.github.io/web-features-explorer/features/path-shape/

  This one appears as not supported because it includes the BCD key for support in shape-outside properties. If you remove that key, then the feature becomes supported in most browsers. Not sure if that's what we want, but worth investigating.

• https://web-platform-dx.github.io/web-features-explorer/features/prefers-reduced-data/

  Available in Chromium behind a flag.

• https://web-platform-dx.github.io/web-features-explorer/features/reading-flow/

  Also in Chromium behind a flag: https://developer.chrome.com/blog/reading-flow-display-contents#try_it_out

• https://web-platform-dx.github.io/web-features-explorer/features/ruby-overhang/

  Couldn't find any information about this one.

• https://web-platform-dx.github.io/web-features-explorer/features/speech-recognition/

  There's all sorts of prefixes and caveats to this feature, making it red here.

• https://web-platform-dx.github.io/web-features-explorer/features/temporal/

  Definitely not implemented anywhere, but this one is often the top request from JS devs when asked about what's missing from the language.

• https://web-platform-dx.github.io/web-features-explorer/features/webnn/

  Active work happening in this area from the WebML WG. There's working implementation in Chromium, but behind a flag.

• https://web-platform-dx.github.io/web-features-explorer/features/webxr-hand-input/

  Not supported anywhere, but documented on MDN and BCD.

• https://web-platform-dx.github.io/web-features-explorer/features/webxr-layers/

  Same as above. A bunch of WebXR things are fully documented, but appear as all red in BCD.

From this list, we can see that one very common pattern is when features are available in browsers but:

• Partially only, e.g, certain conditions apply, or bugs remain.
• Behind a flag only.
• Behind a vendor prefix.

I don't think that baseline should get a new level, such as "Not supported". Baseline is meant as a very simple summary of a feature's support.
However, I do think that we could let some of the more fine-grain BCD information appear in our calculated status. BCD often has data about flag requirements, prefixes, or partial implementations. Without changing any of our calculation code, I guess we could still add this information to the final computed data.

Idea: why not add a new field to the computed data of baseline:false features like reasons. This could be an object, where keys are browser IDs, and values are the data coming from BCD about flags, bugs, etc.

Or, let consumers write the code on their end to do the same thing with BCD.

@ddbeck @atopal

[jgraham]

I think there are two pre-release statuses we should care about:

• "Prototype" - for things that are not yet in any browser's default configuration, or only with vendor prefixes (ugh), and where there isn't yet general cross-vendor agreement about the long-term shape of the API. This would be the default state for stuff that's only behind flags.
• "Coming to the platform" - for things where there is general buy-in to the API shape and we expect to see multiple interoperable implementations.

As an intermediate step, marking everything that isn't shipping anywhere as "Prototype" seems fine.

Even for stuff that has shipped somewhere, we're still missing a status of "Not part of the open web", for things where we don't expect baseline status to ever be reached for the feature in its current form. That would include APIs which are shipping somewhere, but (for example) have negative standards positions from other vendors. Obviously this could change later on if vendors reevaluate their position, or find technical workarounds to their concerns.

[atopal]

I like the idea of adding a field to capture additional data that adds context, but doesn't directly make up the status of a feature. Re the pre-release statuses, definitely agree that we should have a way to signal to developers that something will be Baseline soon, once we have that information.,

[ddbeck]

I think this is closely related to #915. Right now, we only surface unqualified support in shipping browsers, as reported to us by BCD. BCD knows about but we don't expose:

• partial implementations in any release or anticipated in a future release
• features behind a flag/preference in any release
• complete implementations in "preview" releases (i.e., unversioned support data, like stuff in Safari TP)
• future-dated releases (e.g., if we know something is a Firefox beta and anticipate it will ultimately ride to release, but it's not in the current shipping release)

I think being able to express the notion that something is in an incomplete state in a browser would go a long way toward making the limited availability more useful in the situation where no browser has shipped a fully-realized implementation.

This would cover almost everything Patrick listed, except:

• features that are shipping only in browsers outside of Baseline's scope (e.g., the WebXR stuff that shipped to the Oculus browser and not elsewhere)
• features that have unshipped from all browsers in Baseline's scope (e.g., hand input for WebXR, which BCD says was once supported in Edge)
• features before they appear in BCD and a shipping browser

The last one is not a live problem yet. As far as I know, we don't have any published feature entries for things that aren't shipping somewhere and don't have BCD keys. That's the sort of situation where I'd expect to need a new primordial feature status (e.g., prototyping/design/etc.).

[ddbeck]

Also related to #955.

[captainbrosset]

This was discussed at yesterday's CG meeting. See the notes.

The summary is that we think we can handle the most common case of features being partially implemented/behind flags in code directly. That is, we'd leave the status unchanged, but surface the information that BCD has at the feature level. Consumers could then use this extra information to show, for example, a little beaker icon.

Over time adding more fine grain statuses to baseline, but for now, it seems like the 3 simple/summarized statuses are enough while getting developers used to the concept.

[jyasskin]

I filed GoogleChrome/webstatus.dev#1823 against one of the consumers of this data, and was pointed here. It seems wrong for the project to say to describe unavailable features as "limited availability". There's a lot of discussion above about features that are incomplete or only in non-default configurations. While you do have to make some decision about what kinds of features have "limited availability" within a single browser (e.g. "limited to beta users"), if a feature isn't shipping at all, it should be described as "not available" rather than "limited availability".

There's some resistance to adding a fourth state. I think being available somewhere is an important step on the uncertain path to being available everywhere, but if you really want to mix these, something like "not Baseline" would be more accurate than "limited availability".

[atopal]

I agree that "limited availability" is not precise, and it might make sense to differentiate further, but more states will make comprehension harder, so we'll need to have very good reasons to add another state.

Could you say more about the concerns you have with the current state beyond the fact that it's imprecise? You mentioned that devs seeing the "limited availability" tag might think that one browser has implemented the feature. That would be wrong, but I'm not sure what the consequences of that would be.

Also, MDN will only show features with at least one browser implementation, so in that case limited availability always means at least one browser has an implementation. Other places, like caniuse.com or webstatus.dev show all features, but they have the browser implementation status front and center, so it's not possible to see the feature name and Baseline status without also seeing the browser implementation status. It seems unlikely that people will get confused in that case.

Somewhat related, we also thought about and tested designs that said "Not Baseline". The problem with that is that it still says "Baseline" in the banner, so people only skimming will see "Baseline" (think of people skimming docs on MDN and quickly scrolling past the banner). So we opted for language that avoided using Baseline altogether if the feature is not Baseline.