- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 21 Aug 2025 08:32:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders-4] corner-shape initial value ("round") is strange in some cases (e.g. bevel)`, and agreed to the following:
* `RESOLVED: corners: <'corner-shape'> || <'border-radius'>`
* `RESOLVED: Add corners-* shorthands as longhands of corners, parallel to border-*-radius/corner-*-shape`
* `RESOLVED: Use 'corner' and 'corner-*' for all`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> s/Topic: [css-selectors-4]/Subtopic: [css-selectors-4]/<br>
<TabAtkins> noamr: this was originally aobut confusion with "round" being initial value for corner shapes<br>
<TabAtkins> noamr: but we resolved on that. the resolution led us to have a shorthand that includes both border-radius and corner-shape<br>
<TabAtkins> noamr: which is supposedly more coherent to read, becuase it doesn't default to round<br>
<TabAtkins> noamr: you specify the corner shape, then the radiuses<br>
<noamr> https://github.com/web-platform-tests/wpt/blob/9a533af8ca6f850effb6df5d6ce7bfaacecb971d/css/css-borders/corner-shape/corners-valid.html<br>
<TabAtkins> noamr: i impld behind a flag in chrome<br>
<TabAtkins> noamr: there were a couple things to reoslve on. do we like this?<br>
<TabAtkins> noamr: and whether it should be 'corner' or 'corners'<br>
<TabAtkins> noamr: so the syntax is, you always need a shape and one or two radiuses<br>
<TabAtkins> noamr: you can have 1-4 repetitions, slash-separated<br>
<TabAtkins> noamr: standard corner copying rule<br>
<TabAtkins> normal means radius 0<br>
<lea> q?<br>
<lea> q+<br>
<SebastianZ> +1 on the suggested syntax<br>
<astearns> ack lea<br>
<kbabbitt> q+<br>
<TabAtkins> lea: why do we need a shorthand that sets everything? why is that desirable? why not us e the longhand in this case?<br>
<SebastianZ> q+<br>
<TabAtkins> lea: these can get confusing to read, like border-radius with all of its values. like border shorthands can't do different borders on each side<br>
<TabAtkins> lea: you use longhands if you try to do everything<br>
<TabAtkins> lea: shorthands that try to do everything get confusing, even people here probably make mistakes<br>
<fantasai> border-radius: <length-percentage [0,∞]>{1,4} [ / <length-percentage [0,∞]>{1,4} ]?<br>
<TabAtkins> TabAtkins: I'm not sure I udnerstand what's confusing here...<br>
<astearns> https://github.com/web-platform-tests/wpt/blob/9a533af8ca6f850effb6df5d6ce7bfaacecb971d/css/css-borders/corner-shape/corners-valid.html<br>
<TabAtkins> lea: like, line 15, do we want to encourage this?<br>
<noamr> notch 10px / squircle 30% 10px / 1rem bevel / 2px round<br>
<lea> notch 10px / squircle 30% 10px / 1rem bevel / 2px round", "10px notch / 30% 10px squircle / 1rem bevel / 2px round<br>
<astearns> ack fantasai<br>
<lea> corners: normal / superellipse(-0.5) 30% 10px / 10px 1rem notch", "normal / 30% 10px superellipse(-0.5) / 10px 1rem notch;<br>
<TabAtkins> fantasai: i pasted the border-radius syntax into IRC. want to emphasize that this pattern is inconsistent with that one<br>
<astearns> lea note that there are two string values from the lines you pasted<br>
<TabAtkins> fantasai: border-radius takes the values for every corner in sequence, 1-4, then the slash doesn't separate the sides, but to seaprate x/y coords.<br>
<lea> q+<br>
<TabAtkins> fantasai: that allows you to specify one value and have it repeated up to 4 times, and can do it independently in x/y<br>
<TabAtkins> fantasai: if we follow that pattern in the corners shorthand, the corner-shape values woudlnt' be split up by slashes<br>
<SebastianZ> reverting my +1 :)<br>
<TabAtkins> fantasai: slash only disambiguates x/y in border-radius<br>
<TabAtkins> fantasai: most time, people just want to say the shape once and then give the border radiuses<br>
<TabAtkins> fantasai: not repeat the corner just because radius is changing<br>
<TabAtkins> fantasai: following the pattern of border-radius would make this easier<br>
<fantasai> corners: <'corner-shape'> || <'border-radius'><br>
<TabAtkins> fantasai: i think that would be pretty straightforward and reduce repetition<br>
<TabAtkins> noamr: then you can't have different corner shapes<br>
<TabAtkins> fantasai: you can, corner-shape takes four values<br>
<astearns> q+<br>
<TabAtkins> line 15 would be: notch squricle bevel round 10px 30% 10px 1rem 2px / 0 10px 0 0<br>
<astearns> ack kbabbitt<br>
<TabAtkins> line 15 would be: notch squricle bevel round 10px 30% 10px 1rem 2px / 10px 10px 1rem 2px<br>
<TabAtkins> kbabbitt: I think it was mentioned that the shapes were a required part, our usual pattern is that values not specified are inferred as defautls<br>
<TabAtkins> kbabbitt: i think if we take elika's suggestion that's the behavior that would fall out of it<br>
<TabAtkins> noamr: that wouldn't fix the issue this was posted for, then<br>
<TabAtkins> noamr: the issue is that people were confused "round" is the default<br>
<florian> q?<br>
<florian> q+<br>
<TabAtkins> noamr: with a round default, people would still be confused<br>
<TabAtkins> kbabbitt: so it's justa bout requiring explicitness to avoid confusion?<br>
<TabAtkins> noamr: that, plus ergonomics for putting them together<br>
<astearns> ack SebastianZ<br>
<TabAtkins> SebastianZ: elika's syntax is what jskuhn suggested<br>
<TabAtkins> SebastianZ: would we really want to just let the shape be defined there? or should we alway srequire radius as well<br>
<TabAtkins> noamr: if radius goes to zero the shape doesn't do anything<br>
<TabAtkins> fantasai: no, you can make them both optional, it's fine<br>
<astearns> ack lea<br>
<TabAtkins> fantasai: author can be doing more specific things later, just relying on the reset behavior. i do this with borders a lot. no reason not to make it optional<br>
<TabAtkins> lea: yeah, fantasai's point about slashes working different is great. we shoudl be consistent<br>
<SebastianZ> s/jskuhn/jsnkuhn/<br>
<TabAtkins> lea: that said, i'm not sure expanded border-radius was godo i nthe first place<br>
<TabAtkins> lea: if someone want to set all corners to same value, we should ahve a propery that does<br>
<TabAtkins> TabAtkins: you can, `corners: 5px round`<br>
<fantasai> TabAtkins: you can just say 'corners: round 10px'<br>
<TabAtkins> lea: i'm not sure we *want* to allow the shorthand to set everything<br>
<TabAtkins> lea: shorthands are about reduction of knowledge. a microsyntax makes things harder<br>
<romain> +1<br>
<TabAtkins> lea: experience shows authors don't use shorthands above a certain level of complexity<br>
<SebastianZ> q+<br>
<TabAtkins> lea: I find it's pretty low, too. authors don't even use background shorthand fully.<br>
<astearns> q-<br>
<TabAtkins> lea: if we want people to set top-left corner shape together with its size, we can have a property for that<br>
<TabAtkins> lea: or block-start corners, etc<br>
<TabAtkins> lea: I dont' think we should stuff everything into a complex shorthand<br>
<TabAtkins> q+<br>
<astearns> ack florian<br>
<TabAtkins> florian: I kinda agree people will mostly use shorthands for simple things<br>
<TabAtkins> florian: but with border-radius you already have the options, following the pattern is fine<br>
<TabAtkins> florian: you'll always have the longhands<br>
<TabAtkins> florian: but we already have a few reasonable syntaxes, and it's consistent with border-radius<br>
<TabAtkins> florian: not a fan of border-radius, but would like to keep it going.<br>
<TabAtkins> florian: also, earlier you said people found it confusing the default is round, is that because they didn't realize that with 0 it's square anyway?<br>
<TabAtkins> noamr: part was just trying to use corner-shape for a bevel, and saying "my corner is round just because I give it a radius"...<br>
<TabAtkins> noamr: round being the default is more historical than intentional<br>
<TabAtkins> noamr: it's also slightly more convenient feature-detection wise to set 'corners', can use border-radius by itself for a round version then 'corners' for a better one<br>
<fantasai> TabAtkins: I don't think we need to justify having a shorthand<br>
<TabAtkins> SebastianZ: their argument was, when you don't apply border-radius, the shape is square<br>
<TabAtkins> SebastianZ: so an initial "round" value was confusing<br>
<astearns> ack fantasai<br>
<TabAtkins> fantasai: I don't think... there are cases in shorthands where we default to something other than initial value, but only with very good reason, because other values are implying a different value<br>
<TabAtkins> fantasai: not the case here, if you have radiuses, round is the right thing to default to<br>
<TabAtkins> fantasai: because if border-radius creates rounded, but 'corners' defaults to bevel, that's confusing<br>
<TabAtkins> fantasai: the previous shorthand syntax proposal required you to repeat your corner shape on each corner, if you want different radiuses<br>
<TabAtkins> fantasai: but if we switch to the one that matches border-radisu, you don't have to do that<br>
<TabAtkins> fantasai: that's why we designed border-radius the way we did<br>
<astearns> ack SebastianZ<br>
<TabAtkins> SebastianZ: Lea already brought up a good point. I think in addition to corners, we should have shorthand for the different corners. we have that for corner-shape and border-radius<br>
<TabAtkins> fantasai: agree<br>
<TabAtkins> noamr: just another 16 properties (corner + sides * logical)<br>
<TabAtkins> florian: do we care about the memory cost of all these shorthands?<br>
<TabAtkins> emilio: long hands matter, shorthands not as much<br>
<astearns> ack TabAtkins<br>
<fantasai> TabAtkins: I agree that complicated shorthand sare bad, but this is not a complicated shorthand itself,<br>
<fantasai> TabAtkins: It just invokes existing shorthands by combining them with ||<br>
<fantasai> TabAtkins: This is the simplest thing we can do<br>
<lea> q+<br>
<fantasai> TabAtkins: Just because longhands are complicated ...<br>
<fantasai> TabAtkins: Having more limited shorthand is not good<br>
<astearns> ack lea<br>
<fantasai> TabAtkins: We only skip the ability to represent values in a shorthand if it's really untenable<br>
<SebastianZ> q+ on naming the shorthand(s)<br>
<TabAtkins> lea: it's not a design goal to expose the complexity of all long hands. borders all allow setting individual values per corner<br>
<TabAtkins> lea: but we don't allow setting everything in the shorthand<br>
<fantasai> TabAtkins: Agree, but syntax for 'border' shorthand intentionally doesn't put all 4 things together<br>
<fantasai> lea: What we're doing here is very similar<br>
<fantasai> lea: If we design 'border' today, we would enable setting all the values<br>
<astearns> ack fantasai<br>
<lea> s/lea: If we design 'border' today, we would enable setting all the values/lea: it's as if we were designing `border` today and trying to make it set separate color, width, style values for each side/<br>
<TabAtkins> fantasai: I agree with Tab<br>
<TabAtkins> fantasai: if we dont' have a compelling reason to disable the ability to represent all the longhands, we try to make it possible<br>
<TabAtkins> fantasai: and this is a case where if you want to do the simple things, it is very simple. it's *possible* to do the complex things.<br>
<kbabbitt> +1<br>
<TabAtkins> fantasai: it's fine if 90% of the time you just use the simple version, that's what shorthands are for<br>
<TabAtkins> fantasai: doens't mean we should blocka syntax that allows all the values<br>
<fantasai> PROPOSED: corners: <'corner-shape'> || <'border-radius'><br>
<TabAtkins> astearns: can we resolve to use the new proposed syntax?<br>
<TabAtkins> astearns: any more discussion about the syntax? if we have the shorthand at all, sounds like this should be the syntax.<br>
<florian> +1<br>
<TabAtkins> astearns: objections?<br>
<fantasai> RESOLVED: corners: <'corner-shape'> || <'border-radius'><br>
<fantasai> PROPOSED: Add corners-* shorthands as longhands of corners<br>
<TabAtkins> astearns: now, should we add shorthands for all the corner variations, to match border-radius<br>
<kbabbitt> q+<br>
<astearns> ack kbabbitt<br>
<TabAtkins> kbabbitt: not an objection, just clarifying request<br>
<TabAtkins> kbabbitt: sounds like a tuple for each corner<br>
<fantasai> RESOLVED: Add corners-* shorthands as longhands of corners, parallel to border-*-radius/corner-*-shape<br>
<astearns> ack SebastianZ<br>
<Zakim> SebastianZ, you wanted to comment on naming the shorthand(s)<br>
<lea> q+<br>
<TabAtkins> SebastianZ: I had a pragmatic reason for renaming to 'corner' rather rthan 'corners'<br>
<TabAtkins> SebastianZ: tool completion is usually alphabetic<br>
<astearns> we’re modeling after border-radius, not border-radii…<br>
<TabAtkins> SebastianZ: i think shorthands will be used more than longhands, but 'corners' sorts after 'corner-'<br>
<astearns> ack lea<br>
<TabAtkins> lea: we don't usually design around tooling, tooling can change more easily than css<br>
<TabAtkins> lea: that said, the one reason I can think of for naming it corner is it follows the prefixing practice<br>
<noamr> q+<br>
<TabAtkins> lea: but also, seeing "corner: ..." in a stylesheet looks a little werid<br>
<TabAtkins> lea: there's some precedent, "columns" vs "column-width"<br>
<astearns> ack noamr<br>
<florian> q+<br>
<TabAtkins> noamr: why I suggested corners before is, unlike border/background, you don't have a concept of "a" corner. You dont' say "what corner does it have", you say "what corners does it have". unlike "what border does it have"<br>
<TabAtkins> noamr: so it just works better in English I think<br>
<astearns> ack florian<br>
<TabAtkins> florian: for short shorthand, 'corners' is okay either way. for the mid shorthands, the resolution says 'corners-top-left', sounds bad. want to go singular for that<br>
<fantasai> PROPOSED: s/corners-*/corner-*/ on the shorthand<br>
<fantasai> PROPOSED: s/corners-*/corner-*/ on the long shorthands<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask wrt the shorthands<br>
<TabAtkins> florian: in some cases singular is obvious, in some it's arguable, but it's definitely not correct to be plural everywhere<br>
<fantasai> astearns: border-radius, not border-radii<br>
<fantasai> TabAtkins: People don't talk about border-radii of the box<br>
<TabAtkins> s/border-radii/border-radiuses/<br>
<fantasai> fantasai: Should we resolve on the long shorthand?<br>
<fantasai> fantasai: since they're singular<br>
<fantasai> florian: We well have the mid shorthands, for two corners each<br>
<TabAtkins> SebastianZ: we should be consistent across the shorthands<br>
<fantasai> SebastianZ: We should be consistent across the shorthands, regarding the naming<br>
<fantasai> TabAtkins: do you mean all of them, or all of the mid shorthands<br>
<TabAtkins> astearns: all of them<br>
<kbabbitt> +1 to singular in all the shorthands<br>
<TabAtkins> noamr: i'm convinced consistency is more important than English practice here<br>
<TabAtkins> astearns: sound slike consensus for 'corner' in all cases<br>
<TabAtkins> astearns: objections?<br>
<TabAtkins> RESOLVED: Use 'corner' and 'corner-*' for all<br>
<fantasai> I was ambivalent, but I'm convinced by the "one vs two vs four" of shorthand<br>
<TabAtkins> lea: the tag principle does stress consistency, but says other things can take precedence<br>
<TabAtkins> fantasai: I was ambivalent until we started talking about the longer shorthands<br>
<TabAtkins> fantasai: corners-top-left only sets one corner, but corners-top is setting two<br>
<TabAtkins> fantasai: corner-top-left and corners-top is confusing<br>
<lea> q+<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to respond to lea<br>
<TabAtkins> fantasai: both singular or both plural is fine. but corner-top-left is just kinda weird anyway<br>
<ydaniv> q+<br>
<TabAtkins> lea: have we considered having a singular when setting one corner and a plural when setting multiple?<br>
<TabAtkins> astearns: yes, we just discussed that. I agree it's too confusing<br>
<astearns> ack ydaniv<br>
<TabAtkins> TabAtkins: agreed<br>
<TabAtkins> ydaniv: some people look at it like 'corners' is a namespace<br>
<TabAtkins> ydaniv: corners-top-left is like corners.topLeft<br>
<fantasai> s/corner-to-left is just kinda weird anyway/but corner-top-left and corners-top, where one is plural and the other not, is going to be confusing for authors/<br>
<TabAtkins> ydaniv: so it's not that weird to some people<br>
<florian> q?<br>
<TabAtkins> florian: also note that a large fraction of the population doens't have native plurals<br>
<TabAtkins> florian: if you have to already intuit English grammar when programming, not impossible, but one more thing to remember<br>
<fantasai> s/confusing for authors/confusing for authors, and corners-top-left where we're pluralizing a singular is also weird/<br>
<fantasai> +1 wrt i18n<br>
<TabAtkins> astearns: cutting bikeshedding short. if someone thinks having two words for the shorthands is something to do, we can discuss it later<br>
<TabAtkins> astearns: break time<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11623#issuecomment-3209549632 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 August 2025 08:32:47 UTC