Partial support and notes
Opened this issue · 5 comments
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/js-modules.yml
Lines 12 to 14 in 477f11f
#912 is another case currently in review.
In BCD, partial_implementation
must come with a note, and we should probably do the same.
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?
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.
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.
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.
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.