Re: [csswg-drafts] [css-backgrounds] allow optional forward slash in `border-*-radius` long hands (#12861)

The CSS Working Group just discussed ``[css-backgrounds] allow optional forward slash in `border-*-radius` long hands``, and agreed to the following:

* `RESOLVED: Allow forward slash in these properties.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: someone outside the WG wanted to propose we allow / separating the x and y values of border-radius, also in the longhands<br>
&lt;TabAtkins> fantasai: right now borde-rradius takes 1-4 values, a slash, then 1-4 values. x/y<br>
&lt;TabAtkins> fantasai: but in the longhands it's just two values, space-separated<br>
&lt;oriol> q+<br>
&lt;TabAtkins> fantasai: they thought it was confusing, wanted to put / in the longhands as well<br>
&lt;fantasai> oriol: This would have been good from the beginning, but now that we're using spaces, but at this point<br>
&lt;fantasai> oriol: It might add confusion, if an author sees the two options, wouldn't be obvious that they mean the same thing<br>
&lt;lea> q+<br>
&lt;kbabbitt> q+<br>
&lt;fantasai> oriol: I'm not strongly opposed, but lean against<br>
&lt;astearns> ack oriol<br>
&lt;astearns> ack lea<br>
&lt;fantasai> lea: Seems reasonable to me. I could argue that we should have done it originally, it is weird to be different.<br>
&lt;fantasai> lea: I'm in favor of this change.<br>
&lt;astearns> ack kbabbitt<br>
&lt;fantasai> kbabbitt: I empathize with the author<br>
&lt;fantasai> kbabbitt: but there are other places where we do this, concerned about lack of ocnsistency<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: in colors we introduced an alternate punctuation<br>
&lt;ChrisL> rssagent, draft minutes<br>
&lt;TabAtkins> fantasai: it's not common to set x/y radius independently in the longhands. it happens, but you're usually using the shorthand, or setting both to same value<br>
&lt;TabAtkins> fantasai: wrt other places where we use slash, mostly it's places where wer'e combining two longhands and need the / to separate two numbers<br>
&lt;TabAtkins> fantasai: don't think we have any other example of where a / is used in the shorthand to separate two values, but those same two values in the longhand aren't slash-separated<br>
&lt;TabAtkins> fantasai: like in background-position, the / separates sizing from offsets. but in the longhands they're separate things<br>
&lt;TabAtkins> fantasai: so I think the consistency argument here is an overall win for authors.<br>
&lt;fantasai> astearns: Slight concern that we can resolve to make this change but never gets implemented.<br>
&lt;fantasai> astearns: doesn't seem high priority for anyone<br>
&lt;fantasai> astearns: but I'm hearing some slightly more sentiment towards making the change than opposition<br>
&lt;fantasai> astearns: Shall we resolve to change the spec?<br>
&lt;fantasai> oriol: To clarify, we alias at parse time?<br>
&lt;fantasai> astearns: And continue return without slash for comat<br>
&lt;fantasai> fantasai: yes<br>
&lt;fantasai> PROPOSED: Allow forward slash in these properties.<br>
&lt;fantasai> RESOLVED: Allow forward slash in these properties.<br>
</details>


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


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

Received on Thursday, 13 November 2025 06:46:01 UTC