Re: [csswg-drafts] [css-values-4] inherit() function: like var() for parent value, for any property (#2864)

The CSS Working Group just discussed `[css-values-4] inherit() function: like var() for parent value, for any property`, and agreed to the following:

* `RESOLVED: adopt an 'inherit' function to values-5`

<details><summary>The full IRC log of that discussion</summary>
&lt;Rossen_> Topic: [css-values-4] inherit() function: like var() for parent value, for any property<br>
&lt;Rossen_> github: https://github.com/w3c/csswg-drafts/issues/2864<br>
&lt;dlibby_> leaverou: numerous request to extend var() to arbitrary properties, can't do this generally due to cycles. seems to be a less powerful pattern that may be possible<br>
&lt;dlibby_> leaverou: we can use it to get the value from the parent<br>
&lt;dlibby_> leaverou: should we do work to pursue this? I volunteer if consensus that it is a good idea<br>
&lt;dlibby_> leaverou: I can point to many use cases, in case they are not obvious.<br>
&lt;Rossen_> q?<br>
&lt;Rossen_> ack hober<br>
&lt;dlibby_> emilio: seems implementable, but we want it to work like var() at the token level<br>
&lt;dlibby_> emilio: you need to define for each property how it serializes, etc.. it's a lot of work<br>
&lt;dlibby_> leaverou: would be equivalent to the token sequence<br>
&lt;dlibby_> emilio: but what sequence? font-stretch as an example. you need to get interoperable serialization for all properties<br>
&lt;dlibby_> leaverou: don't you need that anyways?<br>
&lt;dlibby_> emilio: yes, just pointing out it is a lot of work<br>
&lt;dlibby_> Rossen_: this is indiciative of how long it might take to implement<br>
&lt;dlibby_> emilio: seems fine to implement<br>
&lt;castastrophe> q+<br>
&lt;fantasai> [what emilio is saying is that as a prerequisite to this, we need to get interop on serialization of all properties, which is something we don't have yet]<br>
&lt;fantasai> [that requires a bunch of spec work, QA work, and implementer follow-up to fix all the inconsistencies]<br>
&lt;dlibby_> castastrophe: for container queries, computing ancestors comes down to a 'contract' as things are flagged as cascading 'down'<br>
&lt;leaverou_> q?<br>
&lt;TabAtkins> q+ TabAtkins<br>
&lt;dlibby_> castastrophe: can we use a similar mechanism (!inherited) to indicate such a pattern<br>
&lt;Rossen_> ack castastrophe<br>
&lt;TabAtkins> ack TabAtkins<br>
&lt;dlibby_> emilio: i don't think that is necessary, as long as you inherit with the same property, you already need the complete ancestor style<br>
&lt;smfr> q+<br>
&lt;dlibby_> TabAtkins: shouldn't need that since there is no circularity<br>
&lt;Rossen_> ack smfr<br>
&lt;leaverou_> q?<br>
&lt;dlibby_> smfr: concerned about impl complexity vs. usefulness. in the example, you could say inherit z-index to a font property<br>
&lt;dlibby_> leaverou: there are use cases that you have to use a mixture of properties<br>
&lt;dlibby_> emilio: this would be implemented via existing serialization rules, so this doesn't explode, you don't convert between properties, use serialization syntax, then reparse token stream<br>
&lt;dlibby_> leaverou: in most cases you'll probably end up with an invalid declaration<br>
&lt;dlibby_> Rossen_: hearing consensus on what we want to achieve, but some warning on how long this might take<br>
&lt;dlibby_> Rossen_: any other points on the topic?<br>
&lt;dlibby_> leaverou: proposed resolution - add an inherit function to values-4 to get the value of parent properties<br>
&lt;dlibby_> RESOLVED: adopt an 'inherit' function to values-5<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2864#issuecomment-816280875 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 8 April 2021 22:48:51 UTC