-
Notifications
You must be signed in to change notification settings - Fork 641
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-color] Inconsistency of inherited value for color #10536
Comments
Right, CSS color 4 says:
You said:
Yes, that gives you the used value of the color property. Consider
and
the used value of the color property is
That isn't bending, but it does give you the actual value.
which is why they fail a bunch of WPT tests related to currentColor, at the moment. |
Aren't https://github.com/web-platform-tests/wpt/blob/master/css/css-color/color-mix-currentcolor-003.html and https://github.com/web-platform-tests/wpt/blob/master/css/css-color/color-mix-currentcolor-nested-for-color-property.html essentially about the problem statement in this issue? Browsers pass these tests, but they do not apply the <style>
body {
color: green;
}
div {
color: color-mix(in srgb, currentColor 50%, white);
}
div > div {
color: inherit;
}
</style>
<div>
<div>This text should be pale green</div>
</div> has reference <style>
div {
color: color-mix(in srgb, green 50%, white);
}
</style>
<div>
<div>This text should be pale green</div>
</div> According to the strict interpretation, it could be |
Thanks for the report, it seems those tests need to be revised. |
But isn't the solution to those tests more desirable than implicit recursion? It feels like the same reason why for example relative font size does not apply recursively, unless specified with an explicit (e.g. wildcard) match. To me it makes more sense to clarify that within the How would you otherwise avoid this recursion if you don't want it? You might get weird issues like https://gitlab.gnome.org/GNOME/gtk/-/issues/6833 that are hard to solve just using CSS. |
I've recently tried to firm up the css implementation in GTK to deal properly with currentcolor, and found some inconsistencies with the newer additions to the css-color spec.
In a situation like this:
What is the used value of the color property for the b element?
Trying to find the used value for the color property on the b element
according to the specs:
Since there is no cascaded value, the specified value is found by inheritance,
so the specified value is the computed value of the color property
on the parent element (css-cascade-5).
For finding out what that is, we look at css-color-5 and find that
the computed value for color-mix with currentcolor is the same color-mix
expression. So the computed value of the color property for the inner
div is
And thus, this is the specified value of the color property for the b element.
The computed value for the b element gets determined the same way again:
a color-mix expression with currentcolor computed to itself. So the
computed value of the color property on the b element is again
To find the used value, we need to substitute currentcolor, since we
are dealing with the color property, the value to use for currentcolor
is the inherited value of the color property (css-color-4), i.e. again
Substituting that into the computed value gives me
which is bad, since we haven't gotten rid of currentcolor this way.
If we bend the interpretation of the color spec to mean that inside the color property, currentcolor
is replaced by the used value of the color property on the parent element, we end up with
which resolves to
This is what my GTK code currently produces.
But when I look at browsers, I get
which seems to indicate that browsers instead ignore what css-cascade-5 says and always inherit
the used value for the color property.
I think the specs are inconsistent and need to be clarified in this regard.
The text was updated successfully, but these errors were encountered: