Re: [csswg-drafts] [css-backgrounds] Make box-shadow a Shorthand Property (#4431)

The CSS Working Group just discussed `Make box-shadow a shorthand`.

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: Make box-shadow a shorthand<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/4431<br>
&lt;emilio> TabAtkins: we've discussed about this in the past<br>
&lt;emilio> ... people want to animate one bit of a shadow, like increasing the spread etc<br>
&lt;lea> +q to express support<br>
&lt;emilio> ... you can always use custom props and so on and it seems so straight-forward that I think we could try<br>
&lt;TabAtkins> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613<br>
&lt;emilio> ... sebastian proposed a grammar (link above)<br>
&lt;smfr> q+<br>
&lt;emilio> TabAtkins: (describes linked proposal)<br>
&lt;emilio> lea: I want to express support, this is a very common thing. It's one of the first examples I use for custom props<br>
&lt;emilio> ... is there an inset prop?<br>
&lt;emilio> TabAtkins: yeah<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/4431#issuecomment-790113613<br>
&lt;emilio> lea: can we do it for text-shadow too?<br>
&lt;Rossen_> ack lea<br>
&lt;Zakim> lea, you wanted to express support<br>
&lt;emilio> TabAtkins: yeah, also in the proposal<br>
&lt;Rossen_> ack dbaron<br>
&lt;emilio> dbaron: I guess one of my reactions is that the stuff that background does is one of the most complicated parts of implementing value computations on CSS<br>
&lt;emilio> ... the code for dealing with that was a significant part of the old parser<br>
&lt;emilio> TabAtkins: for this there is one controlling property<br>
&lt;emilio> dbaron: true for backgrounds as well (for background-image)<br>
&lt;emilio> ... and you need to keep the whole list because you might inherit it somewhere where it matters<br>
&lt;Rossen_> q?<br>
&lt;emilio> TabAtkins: isn't this a common pattern like animation?<br>
&lt;emilio> dbaron: yeah, but it's special code every time<br>
&lt;emilio> smfr: should box-shadow-offset be further broken down into x/y offsets?<br>
&lt;emilio> TabAtkins: [meh reaction]<br>
&lt;emilio> q+<br>
&lt;emilio> ack smfr<br>
&lt;emilio> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to mention that -position needs renaming 'cuz it's not a &lt;position><br>
&lt;Rossen_> ack fantasai<br>
&lt;Rossen_> ack emilio<br>
&lt;fantasai> emilio: Regarding what dbaron said, not just about parsing complexity but also efficiency<br>
&lt;fantasai> emilio: you need to store 5 different arrays rather than one<br>
&lt;delan> present-<br>
&lt;fantasai> emilio: so it's also a bit more inefficient<br>
&lt;lea> fantasai: box-shadow-offset perhaps?<br>
&lt;fantasai> emilio: maybe OK if we consider these to be relatively uncommon<br>
&lt;fantasai> emilio: The parsing complexity is real. Background is the worst by far, but need to check also transitions/animations. It's not super amazing<br>
&lt;fantasai> TabAtkins: Question is, is linked list-valued properties something we want to add generally, or not<br>
&lt;emilio> TabAtkins: the main q is whether adding more list-valued shorthands is ok, and if it's not we should not do it consistently<br>
&lt;emilio> dbaron: I wouldn't say never do them but it's more expensive than you might thing<br>
&lt;emilio> TabAtkins: curious, is the opinion different depending on "there's one length-controlling property vs. shortest wins"<br>
&lt;emilio> dbaron: I don't think it makes a huge difference<br>
&lt;emilio> ... only if you truncate computed values perhaps<br>
&lt;emilio> TabAtkins: that seems fine<br>
&lt;emilio> Rossen: let's follow-up in 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/4431#issuecomment-1016728393 using your GitHub account


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

Received on Wednesday, 19 January 2022 18:05:20 UTC