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.