- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 15:53:06 +0000
- To: public-css-archive@w3.org
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: WG considered parent() and decided to stay with inherit()` * `RESOLVED: define inhert() on custom properties only, as a step towards full thing` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> scribe+<br> <fantasai> lea: as pointed out, we already drsolved to do it<br> <fantasai> lea: but might be a good strategy to split out into parts<br> <TabAtkins> lea: There was a lot of use-cases for cusotm property inheritance, it has defined serialization and a lot of uses<br> <fantasai> lea: and precedent in container queries of starting with cascading properties, even though plan is to expand later<br> <fantasai> Laptop: another possibility could be to have custom properties plus a regstricted set of regular properties in L1<br> <astearns> s/Laptop/lea/<br> <TabAtkins> lea: The advantag ei sit covers mor euse-cases, the disadvantage is it's harder for authors to udnerstand which is which<br> <TabAtkins> lea: but tha'ts a problem with any allowlist, and there's several in cSS<br> <TabAtkins> lea: So I lean toward the "allowlist of properties"<br> <TabAtkins> lea: It would also be nice to resolve on a name, the issue still doesn't reflect consensus<br> <TabAtkins> lea: Seems consensus leans toward parent<br> <bramus> q+<br> <TabAtkins> lea: If that's the case, would be good to record a resolution<br> <fantasai> bramus: wanted to ask about naming towards parent()<br> <fantasai> bramus: that might imply from some non-native speakers to select the direct parent?<br> <fantasai> dbaron: that's exactly what it means<br> <lea> s/So I lean toward the "allowlist of properties"/So I lean toward custom properties + restricted allowlist of regular properties/<br> <fantasai> bramus: won't walk up to ancestors?<br> <fantasai> TabAtkins: it will inherit, so get the value from the parent<br> <fremy_> q+<br> <astearns> ack bramus<br> <TabAtkins> (I still like inherit(), but I'm happy with parent() )<br> <astearns> ack fremy_<br> <fantasai> fremy_: I think parent() is fine<br> <lea> fyi list of proposed names here: https://github.com/w3c/csswg-drafts/issues/2864#issuecomment-1645708854<br> <fantasai> fremy_: only thing I wonder if instead we can do var() with parent as first keyword<br> <fantasai> fremy_: then easy to add new sources later<br> <fantasai> fremy_: it's a bit longer though<br> <TabAtkins> var(parent --foo)<br> <fantasai> fremy_: just want to propose that but don't have a strong opinion<br> <lea> q?<br> <lea> q+<br> <fantasai> fremy_: but parent() doesn't express that it's a variable<br> <Rossen_> ack lea<br> <fantasai> lea: relating it to var() makes it sound like it's only for custom properties<br> <astearns> +1 lea<br> <fantasai> lea: but the goal is to extend to all properties<br> <fantasai> lea: highly unlikely that var() wil extend to all properties<br> <TabAtkins> right, impossible<br> <fantasai> fremy_: fine by me, if no objection to parent()<br> <oriol> q+<br> <fantasai> astearns: other opinions?<br> <astearns> ack oriol<br> <fantasai> oriol: about naming issue, I do like inherit() as a function<br> <fantasai> oriol: we already have the 'inherit' keyword<br> <fantasai> oriol: so this is an obvious extension to it<br> <fantasai> oriol: why add a completely different keyword<br> <fantasai> oriol: inherit also looks at the parent<br> <fantasai> +1 to oriol's argument<br> <Rossen_> +1 to inherit<br> <lea> inherit was a poor name, but I can see the argument for consistency.<br> <fantasai> astearns: any other opinions about inherit() , parent() etc?<br> <fantasai> dbaron: I think I might have a slight preference for parent() because inherit() is about taking the value from the same property and copying from parent to child<br> <fantasai> dbaron: but this is more general, says take the value of that property to use in this parent<br> <lea> q?<br> <fantasai> astearns: so argument for consistency is less because slightly different interpretation?<br> <fantasai> dbaron: that said not a strong preference<br> <fantasai> lea: the way I see inherit is, by default the default argument is the property itself, therefore can omit parens<br> <fremy_> if there is no strong preference, maybe we can strawpoll and just take the most popular one?<br> <fantasai> lea: whereas if you use a different property, you need to add parens and put as argument<br> <fantasai> POLL: 1. inherit() 2. parent()<br> <bramus> 2<br> <oriol> 1<br> <fantasai> 1<br> <Rossen_> 1<br> <dbaron> 2<br> <fremy_> 1<br> <SebastianZ> 1<br> <astearns> 1<br> <ydaniv> 1<br> <bts> 1<br> <TabAtkins> 1 or 2<br> <lea> abstain<br> <changseok> 1<br> <florian> 0<br> <miriam> either<br> <dholbert> abstain<br> <fantasai> astearns: not seeing a reason to change<br> <fantasai> PROPOSED: WG considered parent() and decided to stay with inherit()<br> <fantasai> RESOLVED: WG considered parent() and decided to stay with inherit()<br> <fantasai> astearns: you were arguing for doing just custom properties, or just custom properties and small subset, or doing all at once<br> <fantasai> dbaron: to be clear, talking about source property, not the property you're using the function in<br> <fantasai> [correct]<br> <fantasai> lea: want to hear from implementers<br> <fantasai> astearns: option to do custom properties now and rest later makes some sense to me<br> <fantasai> astearns: I'm less convinced about small subset<br> <fantasai> +1 to astearns<br> <emilio> +1<br> <fantasai> astearns: why should we do that?<br> <fantasai> lea: primary issue with arbitrary properties is primarly shorthands, and a lot of use cases (if not most) that don't require them<br> <emilio> q+<br> <fantasai> lea: so I suspect we can cover a fairly large percentage of use cases by having a well-selected allow-list<br> <fantasai> lea: while not needing to solve serialization<br> <fantasai> lea: but I'm not an implementer, great to hear from someone who is<br> <astearns> ack emilio<br> <fantasai> emilio: not particularly about shorthands, but let's consider a single example<br> <fantasai> emilio: you have font-family, and browser disagree whether to serialization as ident or string<br> <fantasai> emilio: and how you do that changes where it's valid to use<br> <fantasai> emilio: I think some properties first is a lot more controversial<br> <fantasai> emilio: for variables, you just have the tokens the author wrote, so no disagreements between browsers<br> <fantasai> fantasai: that's a large QA project<br> <fantasai> fantasai: [explains]<br> <fantasai> dbaron: we could get a bunch of the work done to detect differences by writing a fuzzer<br> <fantasai> dbaron: then we could look at how much work it is<br> <fantasai> fremy_: we tried when we did TypedOM, and ended up not finishing because so big<br> <fantasai> TabAtkins: big, but also I had other things to work on<br> <dbaron> s/a fuzzer/a fuzzer, with WPT as input/<br> <fantasai> TabAtkins: wasn't like it was unsolveable<br> <fantasai> iank_: it's solveable, but non-trivial amount of work<br> <fantasai> astearns: just so I'm clear on the inherit question<br> <fantasai> astearns: if we don't allow non-custom properties at the outset, ppl can work around it by setting a value on a var, and using inherit on that var<br> <fantasai> TabAtkins: yes<br> <fantasai> astearns: proposed to resolve on custom properties only at the outset<br> <TabAtkins> (finding a good allowlist is nearly the same work as finding all the differences and working toward fixing them)<br> <fantasai> RESOLVED: define inhert() on custom properties only, as a step towards full thing<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-1645794662 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 15:53:08 UTC