Re: [csswg-drafts] [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties? (#7164)

The CSS Working Group just discussed `[css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> Topic: [css-values][css-backgrounds][css-animations][css-transitions][fill-stroke] How to handle linked list-valued properties?<br>
&lt;emeyer> Github: https://github.com/w3c/csswg-drafts/issues/7164<br>
&lt;emeyer> TabAtkins: Issue 4431 asked to turn box-shadow into a shorthand.  Very reasonable.  Because it’s a list-valued property, we’d have to make all longhands the same.  It was brought up by dbaron that whenever you have these groups of longhands and have to sync up all the values, it’s problematic for implementations.<br>
&lt;emeyer> …What exactly are the reasons, and to what degree should we be avoiding them?  This touches on some things being proposed and probably coming, like Toggles.  It would be good to know how careful we need to be.<br>
&lt;emeyer> dbaron: I’m most familiar with an implementation that no longer exists, so this may be questionable input, but my experience was that it was a LOT of code to implement these.<br>
&lt;emeyer> …Given that, it’s not a that strong a preference.  It’s a case where you can get properties where 90% of the work is parsing, not implementation on the other end.<br>
&lt;lea> syncing up list-valued longhands is also a problem for authors. This does not match a human's mental model about this at all<br>
&lt;emeyer> TabAtkins: Do you recall if it was a particular type of syncing up, or if it was all equally hard.<br>
&lt;emeyer> dbaron: I think it was they were all equally difficult and yet things were sufficiently different that you couldn’t coalesce.<br>
&lt;emeyer> TabAtkins: We should get input from people working on extant rendering engines.  Anyone on the call that knows about that?<br>
&lt;emeyer> astearns: Doesn’t sound like we have current implementation experience here on the call.  Lea did mention a problem for authors.<br>
&lt;fremy> +1 leaverou<br>
&lt;emeyer> lea: When authors think about list-value properties, they think of each thing as a unit.  They think, I want this image at this size in this place, and the syntax forces them to do things in a way they don’t think about it.<br>
&lt;emeyer> TabAtkins: Agreed.<br>
&lt;emeyer> lea: Right, this makes sense with single values.<br>
&lt;emeyer> TabAtkins: We’re asking if it’s okay to expand for things that are list values.<br>
&lt;emeyer> florian: When used with a single value on the list, it’s useful to break up.  Authors can help by defining custom properties that define certain combinations.<br>
&lt;emeyer> TabAtkins: That’s partially true.  Authors can work around the present situation, and that’s good.  But forcing them to work around a lot when we could take that need away isn’t great.<br>
&lt;emeyer> …If we can avoid this being necessary in common cases, that would be great.<br>
&lt;emeyer> astearns: The issue is whether we’re going to more closely specify computed values of list values.<br>
&lt;emeyer> Sebastian: It’s not completely defined yet but most or all list-valued properties base their logic on the definition for background.  So they’re just referring to that and still differ on implementation.  Even within one engine.<br>
&lt;emeyer> astearns: The difference is something we need to address even if implementation difficulty is a problem.  I’m wondering whether we can get to a resolution about that specific difference and then people can start implementation to give feedback on difficulty.<br>
&lt;emeyer> TabAtkins: I’d like to have an idea of the matrix of current possibilities.<br>
&lt;astearns> ack fantasai<br>
&lt;emeyer> fantasai: The main question is are the lists truncated or extended at compute time or use-value time?  Specification says use-value.  It was suggested this might be easier if compute time was used.  The difference in behavior will affect inheriting, which most of these properties don’t do, and might affect result of getComputedStyle.<br>
&lt;emeyer> …I don’t think it would be a problem to switch over to say list-matching happens at computed value time, but don’t know if that would make implementation easier.<br>
&lt;emeyer> astearns: We need to clarify what the current implementations do, how difficult it would be to change, and what we’d like to do in general at computed value time.  We should take it back to the issue.<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-1123989840 using your GitHub account


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

Received on Wednesday, 11 May 2022 16:25:25 UTC