Partial support and notes

[foolip]

Both BCD and caniuse have a concept of partial support. Examples:
https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrientation/lock#browser_compatibility
https://caniuse.com/webp

We have already accumulated a number of features that could benefit from the same:

web-features/feature-group-definitions/avif.yml

Line 6 in 477f11f

# TODO: Add notes about animated AVIF coming later in Safari (but don't mark this as partially supported)

web-features/feature-group-definitions/js-modules.yml

Lines 12 to 14 in 477f11f

	# TODO: Consider notes or partial implementation for Safari 10.1 due to the
	# lack of support for nomodule. It's important for fallback behavior, but in
	# the long term not important if JS modules support is completely ubiquitous.

web-features/feature-group-definitions/webp.yml

Line 6 in 477f11f

# TODO: Add notes about animated WebP coming later in Chrome (but don't mark this as partially supported)

#912 is another case currently in review.

In BCD, partial_implementation must come with a note, and we should probably do the same.

[atopal]

What's the implication for the Baseline status of those items? Is that something we need to assess on a case by case basis or does it make sense to consider partial implementations generally not baseline?

[foolip]

I think partial implementation should mean not Baseline, so we for things we consider partially supported we should currently mark them as not supported and add TODOs. This data wouldn't be for more accurate Baseline data, but to capture nuance accurately if web-features is imported to caniuse.com.

[foolip]

Note that there are things that BCD considers partial_implementation that I think we should still override and say it's not important enough for the whole feature to be considered partial. A missing onfoo event handler property is the most obvious such case, where it makes sense to point out at the most granular level in BCD, but it's at most worthy of a note for the overall feature.

[ddbeck]

I think partial implementation should mean not Baseline,

I just wanted to chime in to say that I think this is correct. I think "partial" ought to mean "baseline: false with annotations" not a "half Baseline" or something.

[mirisuzanne]

Short term, I think it's more helpful to say 'this sub-feature is fully supported' when browsers are consistent in what part they support, and when that part can be used independently. If/when browsers do extend the feature, authors will discuss support for the new sub-feature separately.

Long term it might make sense to merge sub-features back together into a complete feature - but it seems to me like 'partial support' is only real useful as a flag when the sub-parts can't be easily distinguished, or the feature isn't usable.

There are many cases where this merging happens over time without anything being considered 'partial' along the way. When a new option is added to an old feature, we give that new option a new name - we don't un-baseline the existing functionality.

[jgraham]

Strong +1 to what @mirisuzanne says.

In general the idea of "partial support" feels unhelpful; in cases where we can quantify that some parts of a feature are supported and others aren't we should split the feature so that the actual state of support is reflected in the data. In other cases it might be hard (e.g. where it's about support for certain subset of possible input values in an API), but all implementations have some bugs and limitations and at some point we need to make a call between "not usable" and "usable".

[bramus]

I’ve found my way to here through GoogleChrome/webstatus.dev#1141, which is about popover that was Baseline, but then wasn’t, but now is again.

I think that the reason why the feature was initially considered to be Baseline is because the partial_implementation field from BCD was ignored – something that is issue right here is also touching upon.

Before mdn/browser-compat-data#25787 – which marks the feature a included in Safari iOS 18.3 – the BCD entry for popover looked like this:

            "safari_ios": {
              "version_added": "17",
              "partial_implementation": true,
              "notes": "On iOS and iPadOS, popovers are not dismissed when the user taps outside of the popover area, see [bug 267688](https://webkit.org/b/267688)."
            },

Had the partial_implementation field been taken into account when computing the Baseline status, the feature would never have been marked as Baseline Newly Available.

Looking at the source of compute-baseline, this function needs to be adjusted:

web-features/packages/compute-baseline/src/browser-compat-data/feature.ts

Lines 124 to 130 in b44c75c

	/**
	* Find out whether this feature's support data says that a given browser
	* release is supported (`true`), unsupported (`false`), or unknown (`null`).
	* Note that this ignores qualifications such as partial implementations,
	* prefixes, alternative names, and flags.
	*/
	supportedIn(release: Release): boolean | null {

[ddbeck]

Replying to @bramus, specifically on this point:

Had the partial_implementation field been taken into account when computing the Baseline status, the feature would never have been marked as Baseline Newly Available.

We do take partial_implementation into account. Right now, the calculation treats all partial_implementations from BCD as if they were wholly unsupported. This fails to expose potentially useful information to developers (e.g., you wouldn't know that you can't trust feature detection for popover). But in the absence of notes (or more structured data from BCD), it's the appropriately conservative course to take—we can't automatically judge the severity of a partial.

That said, the source comment is very badly written (by me) and can be read to mean the exact opposite of what it does. I've sent #2620 to correct this.

For popover specifically, the fault here was in underlying data, not in the calculation. The history for popover is hard to follow, but here's my best attempt to thread together what happened:

1. In May 2024, we started computing popover's status from BCD (Add popover.dist.yml #1100). At the time, BCD incorrectly reported that Safari fully supported light dismiss (BCD source at v5.5.28). We published a status that said popover was Baseline newly available; the calculation was correct, but the upstream data was wrong.

2. In September 2024, BCD was corrected to reflect the incomplete implementation in Safari (Update Safari iOS data for api.HTMLElement.popover mdn/browser-compat-data#24379). When we upgraded the BCD package for web-features, our computation picked that up, correctly regressing popover to limited availability.

   This is the point where this issue would've helped. We couldn't tell consumers of web-features data why we had previously reported popover as Baseline and what was broken about popover in Safari before 18.3. Baseline status regressions should require a note #1971 covers this even more specifically, but it's blocked on this more general issue.

3. In January 2025 (last week), BCD was updated to show that light dismiss was fixed in Safari (Safari iOS 18.3. fully supports popover mdn/browser-compat-data#25787). When we upgraded the BCD package for web-features, our computation picked that up too, correctly progressing popover to Baseline available.

[bramus]

Thanks for the clarification @ddbeck; I appreciate the detail that went into it.