Roll up css.properties.accent-color.maintains_contrast into parent

[ddbeck]

Summary

This undoes the structural changes represented by #26493 and the follow-up #26518, but keeps the data as partial_implementation.

I suspect we'll wish to discuss this at the next BCD meeting—before merging—since it touches on (so far minimal) guidelines for partial_implementation and when to use it.

Test results and supporting details

Roughly, the support details are the previous two PRs.

I think there was perhaps a case to be made for Safari being alone as a weird, but mostly functional outlier. But the sum of the two PRs are such that we have this story:

1. accent-color has 3 distinct behaviors for certain color values (Firefox and deskop Chrome; Chrome for Android; Safari).
2. Two of those behaviors (Chrome for Android and Safari's) are inaccessible for some color values.
3. The inaccessible color values differ across browsers.

That is to say, accent-color, taken as a whole, fails the contrast test incompatibly. I think it's easier to tell this story in the support for the property overall than it is to represent this as a behavioral subfeature.

That's the main story. There's a side story here that we typically use behavioral subfeatures to represent later additions to existing features or behaviors that are, by specification, discretionary between implementations (that is, "should" not "must"). Here we have behavior required by specification text ("must maintain contrast") that has existed since well before the first implementation (w3c/csswg-drafts@37aeebb). I think the use of a behavioral subfeature here breaks with convention, if not formal practice.

Related issues

• css.properties.accent-color - Partial support in Safari #16367
• Should css.properties.accent-color be partial or not? #26073
• Firefox 92 maintains CSS accent-color contrast for legibility #26493
• Chrome 93 also maintains CSS accent-color contrast for legibility #26518

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[caugner]

@ddbeck @Elchi3 What do you think about keeping the maintains_contrast subfeature, and just additionally marking the feature itself as partial?

[ddbeck]

This was on the agenda for the BCD call today. Since we lack guidelines for this sort of thing, it made it hard to come to a decision. So I'm going to do some backformation here: what would the guidelines look like to accept this change? I think there would have to be two: one to justify the partial and one to justify removing the behavioral subfeature.

I'd be interested in @Elchi3 or @caugner reviewing this, to figure out if I've even applied my own guidelines properly. 😄

Hypothetical guidelines

Partial implementation

You must set partial_implementation to true when the all of following conditions are met:

• incomplete: the feature does not implement mandatory specified behavior (that is to say, must not should behavior)
• inconsistent: the feature's behavior is inconsistent with at least one other browser (in other words, if all implementing browsers ignore part of the specification text then it's a de facto complete implementation)
• indistinguishable: the feature shows developer-observable evidence of support that would mislead feature detection

Examples of developer-observable evidence of support includes:

• CSS properties: CSS.supports() returns true for the property name and any value
• CSS values: CSS.supports() returns true for the property name and value
• API names: code such as "name" in ExampleInterface.prototype or "name" in window are true

Behavioral subfeatures

When not otherwise directed to do so by another guideline (such as secure_context_required), use behavioral subfeatures to represent the following cases:

• Contextual support conditions that are not feature detectable (for example, the supporting layout context for a CSS property or the effect of an IDL extended attribute)
• Changes in the behavior of a feature that were not part of the specification at the time the feature initially shipped (for example, a specification changed the intended effect of a CSS value or the type of a property)

Behavioral subfeatures are rare. Do not create a subfeature when any of these conditions are met:

• The behavioral subfeature's support data does not differ from the parent feature (in other words, support for the parent feature is equivalent to support for the behavioral subfeature)
• No browser implements the behavioral subfeature
• Every browser implements the behavioral subfeature

In such cases, consider using notes (or partial implementations) on the parent feature instead.

[caugner]

@ddbeck LGTM overall. Two notes:

• Re. the indistinguishable condition:
  • Overall, could it be explained in simpler terms?
  • Would "surprising", "misleading", or "deceptive" be a better word than "indistinguishable"?
• Re. behavioral subfeatures:
  • Shouldn't the conditions use the term "behavior" rather than "behavioral subfeature"?
  • Should we keep them around even once every browser implements them? (I think so.) And if so, should this be specified?

PS: Would exposure meet the "indistinguishable" condition (cf. this PR)?

[caugner]

This PR about white-space.shorthand_values makes me wonder whether the partial_implementation bit of the hypothetical guidelines should not apply to behavioral subfeatures themselves?

Otherwise, wouldn't it suggest to remove partial_implementation: true there for both Chrome and Firefox? Even if we keep the notes, developers looking at the MDN page might be mislead into thinking that short-hands (as described on the page) are fully supported. (Btw I checked and it looks like all three shorthand values were added together.)

This also had me thinking that is non-trivial to look up when a feature was introduced in the spec (although the research would be more justified if we recorded a link to the spec commit/PR).

[ddbeck]

@caugner

Regarding all the wording stuff: I wrote the guidelines very quickly. If I opened a PR with this, then I would expect to do some work to improve the writing here, in general.

• Should we keep [behavioral subfeatures] around even once every browser implements them? (I think so.) And if so, should this be specified?

Yeah, you'd pretty much have to keep them, or at least for a long time (maybe 5 years?). I suppose spelling this out would be necessary.

To make it possible to get rid of historic behavioral subfeatures, you'd have to invert the data: describe the old behavior as deprecated (or non-standard or both). For example, if you had a returns_promise subfeature, you'd restructure it as accepts_callback. This would be better in the long term (you'd eventually get rid of data that doesn't say anything interesting), but painful in the short term because at first (when some browsers implement the old behavior) you'd have to mark the behavior's parent features as partial_implementation.

PS: Would exposure meet the "indistinguishable" condition (cf. this PR)?

Yes, definitely. If I feature detected MediaStreamTrackProcessor (as in "MediaStreamTrackProcessor" in DedicatedWorker), then I'd get false even though the API is available through another object.

This PR about white-space.shorthand_values makes me wonder whether the partial_implementation bit of the hypothetical guidelines should not apply to behavioral subfeatures themselves?

For that feature, I'd suggest at this point to use separate subfeatures for each of the shorthand values (i.e., treat them like any other value for the property and list them one by one). I'm not sure I'd forbid partial_implementation on behavioral subfeatures in general, but I suspect that's going to be very rare.

[caugner]

What would probably help when documenting these guidelines is to provide a couple of real positive and negative examples for both partial implementation, and behavioral subfeatures.

As for this PR, I think we can go ahead and merge, and maybe we can continue the guidelines conversation in a BCD discussion, or directly in a PR adding the guidelines?

[ddbeck]

@caugner I've opened #26780 and #26781 to break out the data guideline discussions. If that's satisfactory, would you merge this PR?