- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Aug 2022 15:17:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `list-valued properties`, and agreed to the following: * `RESOLVED: Keep list-valued property definition as-is (as specified in B&B). Genericize definition and move to V&U.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: list-valued properties<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7164<br> <TabAtkins> Rossen_: Who's in a good position to summarize?<br> <TabAtkins> fremy: We have a couple of list-valued properties (more than one value)<br> <TabAtkins> fremy: And sometimes these properties interact with each other, each with a list<br> <TabAtkins> fremy: So question is - how do you represent this value in computed/used values?<br> <TabAtkins> fremy: preserve author-provided length, repeat as necessary, truncate<br> <TabAtkins> fremy: Say author provides three values, bu tonly one is used, should used value report just the one or all three?<br> <Rossen_> q?<br> <TabAtkins> fremy: Lea mentioned on the call that for her it seems easier to ahve computed and used be the same<br> <TabAtkins> fremy: So this seems to mean repeating the value as necessary to match the controlling property's length, or truncating to match<br> <TabAtkins> fremy: sebastian had same<br> <TabAtkins> fremy: but seems strange to me<br> <TabAtkins> fremy: computed value is what you inherit from<br> <TabAtkins> fremy: seems strange to say you inherit value to children that doesn't have all the values author provided<br> <TabAtkins> fremy: Even if the parent doesn't use them, might want to use them in the children<br> <TabAtkins> fremy: But apart from that...<br> <emilio> q+<br> <TabAtkins> fantasai: issue was initially filed due to complexity of adding more such property groups<br> <TabAtkins> fantasai: specifically about box-shadow longhands<br> <TabAtkins> fantasai: So question was if there's a way to make this repeating list situation easier to implement, or at least consistent<br> <TabAtkins> fantasai: previously the spec deferred to bckground specs<br> <Rossen_> q?<br> <TabAtkins> fantasai: Which gets the length and repeats/truncates at used value time, computed value is as specified<br> <TabAtkins> emilio: Not in Blink tho<br> <Rossen_> ack emilio<br> <TabAtkins> emilio: the firefox behavior preserves the length of all lists<br> <TabAtkins> emilio: I think that's generally simpler, avoids interdependencies at computed value time,w hcih are annoying<br> <TabAtkins> emilio: Also it's weird to lose values because the controlling property wasn't long enough, when inheriting<br> <TabAtkins> emilio: So I prefer that behavior. IMPlementing Chrome behavior is just more special cases during style resolution<br> <TabAtkins> emilio: so I'd rather keep the props independent and match them up at used value time<br> <TabAtkins> dbaron: I think there may be some relationship between these rules and the interpolation rules<br> <Rossen_> ack dbaron<br> <TabAtkins> dbaron: One thing to watch out for is if we add to this set of properties, which have interp rules that do LCM interp rather than trunctation/repetition<br> <TabAtkins> dbaron: bc i think we have two interp variants<br> <TabAtkins> dbaron: there's def a variant where two diff lengths gives you a list of LCM length<br> <TabAtkins> dbaron: there's one where you get the longer length, padded with a neutral default for the shorter<br> <TabAtkins> TabAtkins: I assume the third would be to interp the shorter length and truncate?<br> <TabAtkins> dbaron: Don't think that's present in anything<br> <TabAtkins> astearns: There's def a variant where we just don't interp between diff lengths<br> <TabAtkins> fantasai: LCM seems awful<br> <TabAtkins> fantasai: 5 and 7 would give 35 values. probably not what the author wanted<br> <TabAtkins> dbaron: It does the right thing in many cases, such as stroke-dasharray<br> <TabAtkins> dbaron: Might be others that do that<br> <TabAtkins> fantasai: So my starting proposal is we keep the spec as-is (specified in B&B), maybe clarify. computed value is as specified, used value is repeated or truncated as necessary.<br> <TabAtkins> fantasai: And make sure all specs use that behavior and file tests and bugs as appropriate<br> <TabAtkins> fantasai: If we shoud do something different somebody should propose it<br> <fantasai> TabAtkins: I agree, I think that's the right proposal<br> <fantasai> TabAtkins: iank_ & co, does that sound like something we can do?<br> <TabAtkins> rune: dunno off the top of my head if we can do it<br> <dbaron> s/rune/futhark/<br> <TabAtkins> rune: I think it's probably fixable?<br> <TabAtkins> Rossen_: So not opposed?<br> <TabAtkins> futhark: Not right now based on what I know<br> <TabAtkins> Rossen_: And it makes sense as a path forward<br> <TabAtkins> s/rune/futhark/<br> <TabAtkins> Rossen_: So we have a proposal. Anything else to add?<br> <fantasai> TabAtkins: if this is the resolution, does that unblock our ability to do more sets of list-valued properties?<br> <fantasai> TabAtkins: or are we they still problematic to add?<br> <Rossen_> q<br> <TabAtkins> emilio: They're still harder to implement, but 🤷<br> <TabAtkins> emilio: Less special-casey than the current behavior for sure<br> <fantasai> s/behavior/Blink behavior/<br> <dbaron> s/current behavior/current Blink behavior/<br> <TabAtkins> Rossen_: so proposal is to keep the spec as is<br> <TabAtkins> Rossen_: did something need to be clarified?<br> <TabAtkins> fantasai: Don't specifically say the computed value is same as specified value, it's implied. can be louder in the spec so it's obvious<br> <TabAtkins> fantasai: Should review other list-valued specs besides B&B to make sure it's fine<br> <TabAtkins> fantasai: And might want to add a generic definition in V&U so we're not all reffing B&B.<br> <fantasai> TabAtkins: Proposed resolution is keep spec as-is, add generic definition to V&U<br> <TabAtkins> fantasai: And make sure all specs are consistent with it<br> <TabAtkins> Rossen_: So anythig to be added? Objections<br> <TabAtkins> RESOLVED: Keep list-valued property definition as-is (as specified in B&B). Genericize definition and move to V&U.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7164#issuecomment-1201340918 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 1 August 2022 15:17:53 UTC