-
Notifications
You must be signed in to change notification settings - Fork 645
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-values-5] Allow inherit
in calc()
(and friends), color-mix()
, RCS
#9757
Comments
Consider #el { --foo: 1 + 2 }
#el > * { --foo: calc(inherit * 2); z-index: var(--foo) } should Also, it's not clear if you are proposing this just for custom properties (with the idea to extend it to all properties in the future), or if you want it for all properties now. I'm concerned about the same serialization inconsistencies from #2864. |
Not sure where you see the ambiguity. Please note that:
In your example, if
Per my edit, custom properties and a restricted set of regular properties TBD. Worst case we could start from custom properties, but I'm hoping since this is a much more restricted feature, we could broaden scope a bit. |
I'm not saying it's ambiguous. I see that 5 results from a simple substitution in the unregistered case, but 6 seems maybe better? The inherited value could be automatically wrapped in parentheses. Less consistent with |
@LeaVerou I know there's also this proposal (#5055) from @tabatkins for We would need to ensure that inherit is seen as an invalid value when used inline in this context so that |
Not sure how that's related. This is about browser support, not whether a value is set. The fallback parameter in |
@LeaVerou using the example from the PR brief: :root {
--depth: 1;
* {
--depth: calc(first-valid(inherit, 0) + 1);
}
} …would be equivalent to this: :root {
--depth: 1;
* {
--depth: calc(inherit(--depth, 0) + 1);
}
} provided this stipulation I mentioned is possible/accurate:
That way, when That's the relevance explainer. We're still bike shedding the name |
@brandonmcconnell Again, that's not how |
@LeaVerou Ah I see. Thanks for clarifying that. some tangential thoughts about if/or to provide a solution for thisI know there's been discussion around an inline I wonder if we could use that or something similar to optimize this (down the road). Something like a logical OR would be ideal here, like This is a bit unrelated to this issue specifically, so we can save that discussion for a separate ticket once both are implemented. |
inherit
in calc()
(and friends), color-mix()
, RCSinherit
in calc()
(and friends), color-mix()
, RCS
In #2864 we resolved to add
inherit(property)
to CSS, starting from custom properties.inherit()
covers use cases across two main axes:However, for 2 we don’t actually need
inherit()
, simply allowinginherit
incalc()
would work fine, is more elegant and familiar thaninherit()
, and being more limited it could likely ship earlier, possibly even for regular properties.One downside is that unlike
inherit()
, it does not allow for providing a fallback value.Use cases
(These are a subset of the use cases for
inherit()
)Custom property value that depends on parent value
Generic
--depth
(1, 2)With
inherit()
:With
inherit
(note that the code had to be restructured due to the lack of fallback value):See also: #1962
Font metrics relative to parent
With
inherit()
:With
inherit
:And any other numerical typographic metric that can be specified in CSS, e.g.
font-stretch
,font-style
(for variable fonts) etcA few of the
currentBackgroundColor
use cases#5292
Way fewer use cases than
inherit()
but it could still be useful for creating variations of the parent background color like so:Matching nested radii for simple cases
#7707
Shipping
Clearly, this doesn't make sense for every property, but then again,
calc()
also doesn't. Also, we should define thatinherit
incalc()
computes to a value that would be useful, which would be different per property (though we could define a hierarchy, e.g.<number>
over<length>
if both are options), and IACVT if the computation doesn't make sense. We could ship for custom properties and an allowlist of regular properties to make this more tractable.The text was updated successfully, but these errors were encountered: