- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Sun, 17 Jan 2021 01:44:32 +0000
- To: public-css-archive@w3.org
I just came across this issue again looking for something else. @tabatkins wrote > Discussion with @dbaron suggested that the effect would be that you basically just sub in the serialization of the computed value (probably per the well-specified serialization in Typed OM). > > If the property you're subbing in doesn't work for the property you're subbing into, it would follow the same rules as var(), and make it invalid at computed-value time. So it sounds like there is a clear implementation path, but the discussion just stalled 2 years ago. Can we move it forwards? I promised in the first post that if this is feasible, I could try and collect a list of use cases. Here are a few: - Many use cases for getting inherited custom property values #1962 [[tweet by @plinss](https://twitter.com/plinss/status/1350550362168545280)] - Font-weight values relative to parent (#2690, #2764) — and any other numerical typographic metric that can be specified in CSS, e.g. `font-stretch`, `font-style` (for variable fonts) etc - Many of the use cases for `currentBackgroundColor` (#5292) can be resolved with this - Child `border-radius` set to parent `border-radius` minus padding + border [[source](https://twitter.com/peterc/status/1350502284409643008)] - Swap foreground and background colors on certain descendant components [1](https://twitter.com/Paceaux/status/1350518907539513346) [2](https://twitter.com/FremyCompany/status/1350499409168117761) [3](https://twitter.com/snapeuh/status/1350492392550526979) - Decorative pseudo-elements that need access to the parent's background-color [[source](https://twitter.com/HugoGiraudel/status/1350496044681990147)] - Child `margin-left` set to `calc(-1 * inherit(padding-left))` [1](https://twitter.com/stephband/status/1350547014791081985) [2](https://twitter.com/MartijnSaly/status/1350496008594202625) - Store inherited property values in custom property to propagate to descendants [[source](https://twitter.com/cjw0/status/1350499207648583683)] - Lots more cases, as answers to my [tweet](https://twitter.com/LeaVerou/status/1350491359745077248) In terms of how it should behave, a few more thoughts: - Does it return the parent value regardless of what it is, or walk up ancestors until it finds a value or hit the root? This is especially relevant for non inherited properties. It seems like it could be more useful if it returned the closest non-initial value, rather than the direct parent, but then there are no guarantees about what element you're actually getting a value from. E.g. consider the "swap background and text colors in children" above. What if the parent ends up not having a color set at all, and `inherit(background-color)` ends up walking up the ancestors and returning e.g. the page's background? OTOH, that might actually be the background you're seeing... - It should probably have a fallback, just like `var()`. The fallback would apply when the returned value is `initial`. - As @upsuper and @tabatkins pointed out above, if after subbing the value, the resulting declaration doesn't make sense, the whole thing just becomes IACVT. - Can shorthands be referenced? If so, what do they return? If they cannot be referenced, this means that when we turn a property into a shorthand, code starts breaking (this was already a risk, it was just limited to JS). Also this would mean that even fairly "obvious" use cases would become complicated (e.g. `inherit(border-color)` cannot be used). - Some potential names: `inherit()`, `inherited()`, `parent()`, `ancestor()`, `closest()` -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2864#issuecomment-761713059 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 17 January 2021 01:44:34 UTC