- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Oct 2025 16:54:06 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-borders-4] Interaction of single-path `border-shape` with non-uniform `border-width` ``, and agreed to the following: * `RESOLVED: take stroke color and width from first border properties not none in logical order` * `RESOLVED: add a half-border-box value and make it default specifically for one-shape border-shape` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> noamr: continuation from F2F, did some work on how border-shape should work when there's only 1 shape provided<br> <kbabbitt> ... where width, color, and style are taking from<br> <kbabbitt> ... concept that came from hallway convos in f2f which I wanted to propose & hopefully resolve on<br> <kbabbitt> ... with and color are taken from first border which is renderable<br> <kbabbitt> ... meaning it has more than 0 width and is not noe<br> <kbabbitt> ... in order of top right bottom left<br> <kbabbitt> ... first renderable border would apply width and color to border shape<br> <astearns> q+<br> <kbabbitt> s/noe/none/<br> <kbabbitt> ... in addition, border would be rendered as: shape would use geometry box that is halfway between border and padding box<br> <kbabbitt> ... border-width as stroke that goes towards border box and padding box<br> <kbabbitt> ... if you use %, circle, anything responsive<br> <kbabbitt> ... similar to how borders work inside border box<br> <kbabbitt> ... using % with this you would be good to fo<br> <kbabbitt> ... leaving border style open, not sure we can use strange border styles in border shape<br> <kbabbitt> s/fo/go/<br> <kbabbitt> ... leave border style an unspecified issue<br> <kbabbitt> astearns: I am with you on taking color and width from first property that is not none<br> <kbabbitt> ... a little concerned about also adding more than 0 width stricture<br> <kbabbitt> ... would mean that as someone is animating width, could have color suddenly shift<br> <kbabbitt> noamr: no objection to just taking first border that's not none<br> <kbabbitt> astearns: other comments or questions?<br> <kbabbitt> fantasai: lot of interesting things here, can we break down into pieces?<br> <kbabbitt> ... first where we take color and width from<br> <kbabbitt> astearns: comments or questions on that?<br> <kbabbitt> ... take color and width from first property that is not none in TRBL order<br> <kbabbitt> fantasai: should it be TRBL or logical order?<br> <kbabbitt> ... logical is probably better<br> <kbabbitt> noamr: shorthands usually don't do that<br> <kbabbitt> fantasai: yes but you're more likely to get primary border that way from design perspective<br> <kbabbitt> noamr: don't have objection to that, more a convenience since hopefully people use 1 border color<br> <kbabbitt> fantasai: but with more than 1, more likely people will use block-start or inline-start one as stronger one<br> <kbabbitt> astearns: so you're okay with that noamr?<br> <kbabbitt> noamr: yes<br> <kbabbitt> astearns: other coments on that first portion?<br> <kbabbitt> astearns: Proposed resolution is that we will take stroke color and width from first border properties not none in logical order<br> <kbabbitt> astearns: objections?<br> <fantasai> block-start inline-start block-end inline-end<br> <kbabbitt> RESOLVED: take stroke color and width from first border properties not none in logical order<br> <kbabbitt> astearns: second part?<br> <kbabbitt> noamr: geometry box between border box and padding box<br> <astearns> ack astearns<br> <kbabbitt> ... we can give it a name, half border box, we could resolve on that, as if border was half the width that it is<br> <kbabbitt> astearns: if we define half border box here, will we want to retrofit other box geometry props to add that value?<br> <fantasai> It's the box that is halfway between the border-box and padding-box, more or less (ignoring scrollbars)<br> <kbabbitt> noamr: doesn't hurt to have half border box, just a bunch of WPTs<br> <kbabbitt> ... useful in some cases, like when you have double border style and want shape that works with it<br> <kbabbitt> astearns: would it go between the 2 borders or in center of combined width?<br> <kbabbitt> noamr: center of combined width, between padding edge and border edge<br> <kbabbitt> astearns: if your double style borders are same width<br> <kbabbitt> ... if not, some nonsense value<br> <kbabbitt> fantasai: in any case, for the single stroke case this gives you a much more natural way of expressing shapes<br> <kbabbitt> ...assuming something that looks like a box, stroke same of border width, outer edge will land on what border would have been, same for inner<br> <kbabbitt> ... makes it easy to draw a rectangle that exactly matches what border would have been<br> <kbabbitt> ... or modify it, make it a bit squiggly<br> <kbabbitt> astearns: yay for more expressability, boo for complicating things<br> <kbabbitt> ... use case here weighs in favor of expanding possibilities<br> <kbabbitt> noamr: uncomplicated if not used as default<br> <kbabbitt> ... default works like stroke that goes through bordeer<br> <kbabbitt> astearns: Proposed resolution is to add a half-border-box value and make it default specifically for one-shape border-shape<br> <kbabbitt> fantasai: for the one you're stroking, so drawn border is half and half on each side of shape<br> <kbabbitt> ... for double shape, we fill in between and don't want that as default<br> <kbabbitt> noamr: probably border box for one padding box for other<br> <kbabbitt> astearns: other comments or questions on default we're adding for one-shape border-shape?<br> <kbabbitt> ... objections?<br> <kbabbitt> RESOLVED: add a half-border-box value and make it default specifically for one-shape border-shape<br> <kbabbitt> astearns: anything more?<br> <kbabbitt> noamr: border style remains unspecified<br> <kbabbitt> ... don't need to resolve on that<br> <kbabbitt> astearns: are you going to continue conversationj about that in this issue?<br> <kbabbitt> noamr: will open a new issue<br> <kbabbitt> astearns: ok<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11662#issuecomment-3357273733 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 October 2025 16:54:07 UTC