Baseline status mismatch for accent-color across web-features and compute-baseline #2880
Description
Should Baseline tools like ESLint warn on accent-color? The feature is not considered Baseline, but the individual BCD key is fully supported across all major browsers now that the accent-color.maintains_contrast subfeature key absorbs all of the a11y issues. See #2874 and mdn/browser-compat-data#26073
Baseline tools look up the Baseline status of individual BCD keys using compute-baseline, which now says that css.properties.accent-color itself is Baseline. As a result, the tools WILL NOT warn when they see the property.
Is that the intended behavior?
Activity
rviscomi commentedon Apr 17, 2025
The compat table on MDN shows the issue well:
accent-coloris green across the board, indicating that the property is fully implemented. But there's a separate row for implementation issues related to color contrast.css.properties.accent-colorbe partial or not? mdn/browser-compat-data#26073ddbeck commentedon Apr 23, 2025
If you're computing from a single key, then yes this is expected behavior. In general, a per-key status will tell you whether that key and all of its ancestors are supported or not (unless you go to some extra lengths to call
computeBaseline()withcheckAncestorsset tofalse). A per-key status doesn't (yet?) have any additional context from other compat keys.Possible alternatives you might consider:
Use a
web-featuresheadline status (i.e., the status given via the JSON package, seen here at the top of https://github.com/web-platform-dx/web-features/blob/main/features/accent-color.yml.dist). In other words, trust us to group BCD keys sensibly. You might discover that we don't have the right level of granularity for you. I'd like to know if this is the case.Take both the
web-featuresheadline status and the per-key status and clamp to the "worse" result. For example,accent-color's status inweb-featuresand thecompute-baselineresult for BCD'scss.properties.accent-color, and take the less-supporting result.Check more keys. For example, you might want to check whether
accent-coloris supported by writing some logic in ESLint that says,accent-color(the property) is actuallycss.properties.accent-color+css.properties.accent-color.maintains_contrast. This will be VERY precise—you'll cover only the slimmest part of BCD that matters to you. However, BCD churns a bit; you might find yourself having to do a lot of maintenance if, for example, BCD renames or moves a compat key to a different part of the tree.All that said: for
accent-colorspecifically, I think BCD structured this data poorly. I've sent mdn/browser-compat-data#26605 to correct it, though it remains to be seen whether it's accepted.Does that answer some or all of your questions?
rviscomi commentedon Apr 24, 2025
Thanks @ddbeck!
To give us some more concrete examples to play with, I wrote a script to extract BCD keys whose status differs from their parent WebDX feature, limited to the types of keys Baseline tools tend to look at.
Results
One example where the granularity may be too coarse for an approach like this is
html.elements.img.loading, which belongs to theloading-lazyfeature.This specific BCD key has a Baseline status of "high" and the
loading-lazyfeature is "low". From a tooling perspective though, there's no reason to discourage developers from using<img loading>just because<iframe loading>isn't as well-supported.There are also lots of examples where a BCD key's status may be lower than its parent feature. Here are a few of them:
html.elements.audio.autoplay(false) <audiohtml.elements.iframe.csp(false) <csp(high)css.properties.animation-duration.auto(false) <animations-css(high)css.properties.clear.inline-start(low) <logical-properties(high)css.properties.forced-color-adjust(false) <forced-colors(high)In cases like these, I would expect Baseline tools to warn developers about using an HTML attribute or CSS property value that isn't widely available.
Interesting idea. This would completely address the second case above where the BCD key has a status that is lower than the parent feature. But I don't think it would help the
loading-lazycase. Maybe that's a good argument for splitting up that particular feature?There are a few other cases like
loading-lazy:css.properties.text-wrap-style.balance(low) >text-wrap-style(false)css.properties.transform-box.fill-box(high) >transform-box(low)css.properties.page(low) >page-selectors(false)css.selectors.first(low) >page-selectors(false)And one more case that seems similar to
accent-color, in which maybe the solution is to mark the BCD key itself as partial:css.properties.display.contents(high) >display-contents(false)But in the other cases above, I don't necessarily see a reason to hold back from using the features, as long as they meet my Baseline targets. For example,
transform-box: fill-boxis widely available and so is the valueview-box. Tools probably shouldn't warn when those values are used just because other possible values exist likecontent-boxandstroke-box, which are not widely available.Yeah this seems like a lot of maintenance overhead on the part of the tooling author, and it would have to be duplicated across every tool that checks that feature.
If anything, that association between keys should be centralized in web-features, sort of like what you were hinting at here:
And compute-baseline could handle the logic to take a single key and combine it with any other relevant keys to get the true status. There are so few of these edge cases that maybe this is a viable solution.
ddbeck commentedon Apr 24, 2025
Thank you so much for the breakdown here! Clamping seems like a good area to investigate more closely.
I'm seeing a few different ways to handle a case like
loading-lazy, if clamping is on the table. Not every feature would get the same treatment, so we'd probably need to do a mix of these:Split the feature.
In the lazy-loading case, caniuse lumps it together, so we did too. We could break with caniuse, if there's a strong story for it. It's at least plausible in this case: lazy-loading an image is something developers would be very likely to do independently of iframes.
(I think there's going to be a lot of enthusiasm for this approach once we implement some feature evolution mechanisms. It'd be much nicer for a feature's "later additions" to exist as separate, related features that eventually merge into a root feature, after they're well-established. Feature evolution is already on my agenda, with Consider handling feature identifier changes or aliases #91 being the most central part of it.)
Use an editorial override on the feature's headline status, setting a
compute_fromannotation in the authored YAML files.In the lazy-loading case, we'd pin the headline status to lazy image support. This would play nicely with the clamping approach: the headline status would line up with lazy-loading images (which I suspect is the much more common use of the attribute), while the per-key status would be worse for iframes. This is a little… impure, but we do it often enough anyway and makes clamping make sense for your application.
Override BCD on a key-by-key basis.
In the
css.properties.accent-color+css.properties.accent-color.maintains_contrastscenario (supposing Roll upcss.properties.accent-color.maintains_contrastinto parent mdn/browser-compat-data#26605 is not accepted, though I think it will be), we might just make a special case judgement that the two keys cannot be computed separately.(We need this option eventually anyway. Sometimes BCD shows a partial implementation that is more restrictive than the Baseline definition. Override individual BCD keys #1690)
If all that sounds plausible then…
Yes, I could see
getStatus()being the way clamping and exceptional case handling happens. I kinda imagined something like this for the method, but we never actually got to implementing it (because, for the longest time, no one was usingcompute-baseline!).web-features/packages/compute-baseline/src/baseline/index.ts
Lines 64 to 89 in 8077c64
ddbeck commentedon Apr 24, 2025
After meeting with MDN today, I think #2891 might also be of interest here. It would maybe complicate some clamping scenarios.
ddbeck commentedon May 15, 2025
With #2966, the contrast data is folded into the main
accent-colorfeature. This is reflected in v2.35.1.