Baseline status mismatch for accent-color across web-features and compute-baseline
#2880
Comments
|
The compat table on MDN shows the issue well: 
|
|
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 Possible alternatives you might consider:
All that said: for Does that answer some or all of your questions? |
|
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 This specific BCD key has a Baseline status of "high" and the 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:
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 There are a few other cases like
And one more case that seems similar to
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,
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. |
|
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
If all that sounds plausible then…
Yes, I could see web-features/packages/compute-baseline/src/baseline/index.ts Lines 64 to 89 in 8077c64 |
|
After meeting with MDN today, I think #2891 might also be of interest here. It would maybe complicate some clamping scenarios. |
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 theaccent-color.maintains_contrastsubfeature key absorbs all of the a11y issues. See #2874 and mdn/browser-compat-data#26073Baseline tools look up the Baseline status of individual BCD keys using compute-baseline, which now says that
css.properties.accent-coloritself is Baseline. As a result, the tools WILL NOT warn when they see the property.Is that the intended behavior?
The text was updated successfully, but these errors were encountered: