Re: [csswg-drafts] [css-borders-4] Allow declaring `box-shadow-offset` with a single value (#8568)

The CSS Working Group just discussed ``[css-borders-4] Allow declaring `box-shadow-offset` with a single value``, and agreed to the following:

* `RESOLVED: Allow a single value for box-shadow-offset for that longhand property only`

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> SebastianZ: Proposal is to set a single value for the box shadow offset instead of having two values<br>
&lt;emeyer> …Setting one value would automatically set the other, so the same distance for both axes<br>
&lt;TabAtkins> q+<br>
&lt;emeyer> …Furthermore I suggest changing the syntax to avoid any conflicts that arise regarding a single value instead of two values<br>
&lt;emeyer> …We also have the values for blur and spread, which are length-percentage<br>
&lt;emeyer> …If we want to introduce a way to define offset by a single value, we have to think about how it can be done without conflicts<br>
&lt;astearns> ack TabAtkins<br>
&lt;lea> q?<br>
&lt;emeyer> TabAtkins: As noted in the issue, the shorthand already has a bunch of numbers, so we’d have to do something new to separate them<br>
&lt;lea> q+ to say I don<br>
&lt;emeyer> …The only author benefit would be to set 45 degree offsets a little more easily<br>
&lt;smfr> agree with Tab<br>
&lt;emilio> +1<br>
&lt;astearns> ack fantasai<br>
&lt;emeyer> …I suggest we reject as DONTCHANGE<br>
&lt;SebastianZ> q+<br>
&lt;emeyer> fantasai: I agree with regard to the shorthand<br>
&lt;lea> q+ to also agree that I don't think the complexity of this change is worth the use cases addressed, I'm not even convinced 45deg is that common<br>
&lt;astearns> ack lea<br>
&lt;Zakim> lea, you wanted to say I don and to also agree that I don't think the complexity of this change is worth the use cases addressed, I'm not even convinced 45deg is that common<br>
&lt;emeyer> …I don’t care if we make this possible on the longhand or not<br>
&lt;astearns> ack SebastianZ<br>
&lt;emeyer> lea: I agree that the complexity of the change isn’t worth it<br>
&lt;emeyer> SebastianZ: I want to note we have different issues that suggest to extend the other values as well, so at some point if we want to extend the shorthand, we’ll have to introduce a new syntax<br>
&lt;lea> q+ to add I think it's fine to support one length in the longhand, but it's not worth the complexity to deal with this in the shorthand<br>
&lt;emeyer> …On the other hand, I’d be fine for now that we just allow it on longhands and then we can separately discuss the shorthand syntax<br>
&lt;astearns> ack lea<br>
&lt;Zakim> lea, you wanted to add I think it's fine to support one length in the longhand, but it's not worth the complexity to deal with this in the shorthand<br>
&lt;emeyer> lea: I don’t see harm with allowing a single length in the longhand<br>
&lt;lea> +1<br>
&lt;fantasai> +1<br>
&lt;emeyer> SebastianZ: Maybe we can agree to add it to the longhand for now?<br>
&lt;TabAtkins> no opinion on the longhand<br>
&lt;fantasai> s/in the longhand/in the longhand, consistent with other properties in CSS; but not worth the complexity of allowing in the shorthand/<br>
&lt;emeyer> astearns: Agreed it’s a small use case, but the change to the longhand is also small<br>
&lt;fantasai> I'm in favor because it's how we handle other two-value properties. Even if the use case is small, the consistency is good.<br>
&lt;emeyer> RESOLVED: Allow a single value for box-shadow-offset for that longhand property only<br>
&lt;emeyer> SebastianZ: I’l file a new issue about the shorthand syntax<br>
&lt;emeyer> astearns: I think there’s a fair consensus here that we not do that<br>
&lt;emeyer> SebastianZ: There are several use cases to extend the other longhands and have other features there<br>
&lt;emeyer> astearns: I’m happy for you to open the shorthand issue if it refers to all those other use cases, not just this one<br>
</details>


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


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

Received on Wednesday, 30 August 2023 16:40:24 UTC