- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 13 Nov 2025 07:29:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders] allow multiple borders`. <details><summary>The full IRC log of that discussion</summary> <fantasai> lea: Years ago we got a use case from APA around having both white and black borders<br> <fantasai> lea: to make sure border was visible regardless of colors<br> <fantasai> lea: We introduced 1-dimensional images and stripes() function<br> <fantasai> lea: Which in hindsight I think was overengineered<br> <fantasai> lea: We expanded border-color to accept stripes() and it would curve around the border<br> <fantasai> lea: So initial motivation was that listifying border-color created some weird issues<br> <fantasai> lea: because specify border-width: 2px; you could end up with 6px border because it's multiple colors<br> <fantasai> lea: If we naively listify border colors, you have to specify colors in a weird order that's confusing<br> <fantasai> lea: These are problems<br> <lea> https://x.com/LeaVerou/status/1985123158370680869<br> <fantasai> lea: When this issue was opened, I revisited this question<br> <lea> https://front-end.social/@leaverou/115482600983968371<br> <fantasai> lea: Posted some polls<br> <fantasai> lea: There are 2 author intents: I want to specify width of entire border, or I want to specify width of individual borders<br> <fantasai> lea: As you can see, overwhelmingly people prefer listifying<br> <fantasai> lea: but then we'd need to support multiple border-styles<br> <miriam> on the other hand: solid, dotted, solid could look excellent<br> <fantasai> lea: another issue with listifying is, how do we reconcile issue of border-width<br> <fantasai> lea: honoring that while also being able to say 1px white, 1px black<br> <fantasai> lea: One idea I had was to have border-width specify width of the total border (as it is today)<br> <emilio> q+<br> <fantasai> lea: So layout would still be as expected<br> <fantasai> lea: But if you have a border shorthand specifying multiple border widths, they would dereference a new longhand<br> <fantasai> lea: where you can specify a list of border widths ando/ro fr<br> <fantasai> lea: just like in stripes() function<br> <fantasai> lea: Another concern is that even though this looks nice for simple cases, it makes some other cases more difficult<br> <fantasai> lea: Actual use cases are overwhelmingly simple<br> <fantasai> lea: People don't generally do differnet colors on each side<br> <fantasai> lea: So yes, doing layers around and around would still be awkward, but nobody really needs it<br> <fantasai> lea: But if can't resolve to that, there are other solutions<br> <fantasai> lea: Maybe we can listify outline rather than border since it doesn't affect layout<br> <fantasai> lea: but I don't think stripes is natural<br> <oriol> q+<br> <ntim> q+<br> <astearns> ack emilio<br> <miriam> q+<br> <fantasai> emilio: Whatever solution we come up with, it has to specify width of each border individually<br> <fantasai> emilio: otherwise you end up with snapping issues<br> <fantasai> emilio: 3 colors with 2px, it's an issue<br> <fantasai> emilio: borders snap to pixels<br> <TabAtkins> qq+ about snapping<br> <TabAtkins> ack about<br> <Zakim> about, you wanted to react to emilio<br> <lea> q+<br> <fantasai> emilio: Need to make sure each stripe is device-pixel sized. Otherwise it looks like crap<br> <astearns> ack oriol<br> <fantasai> oriol: I disagree that stripes() is overengineered. To me it seems simple.<br> <fantasai> oriol: I like that it allows grouping each side the various colors<br> <fantasai> oriol: because with multiple border solution you have to specify inner ones, then outer ones, etc.<br> <fantasai> oriol: it's harder to visualize what colors go to which place<br> <fantasai> oriol: I also don't like that the styles will always be solid, and need to keep repeating 'solid' for each layer<br> <fantasai> oriol: with stripes() you only need to specify the style once<br> <fantasai> TabAtkins: Small question, snapping every color, in existing two-tone borders, do we snap those?<br> <fantasai> emilio: I think the width is not snapped, but when you paint you snap<br> <astearns> ack ntim<br> <fantasai> ntim: Problem I have with stripes is, naming is indicates that striping is on the other axis ...<br> <fantasai> ntim: One thing that could be possible is making stripes take sizes<br> <fantasai> TabAtkins: it already does that<br> <fantasai> florian: You still have to specify the total explicitly though<br> <TabAtkins> have to say `border: 5px stripes(white 1px, black 3px, blue 1px)`<br> <fantasai> ntim: makes sense<br> <fantasai> ntim: So I guess my main issue is the axis<br> <TabAtkins> can't just say `border: stripes(white 1px, black 3px, blue 1px)` and magically have it know it's 5px wide<br> <fantasai> ntim: Also a lot of ppl use box-shadow for this use case<br> <TabAtkins> (tho we could probably fix that somehow)<br> <florian> q?<br> <florian> q+<br> <fantasai> ntim: could we just make that more convenient?<br> <florian> q-<br> <fantasai> ntim: also easier to implement<br> <florian> q+ to bikeshed and propose "bands" instead of "stripes"<br> <astearns> ack miriam<br> <fantasai> miriam: I'm interested in having a box-shadow approach, but big difference wrt layout<br> <fantasai> miriam: so stacking multiple borders wouldn't be the same<br> <fantasai> miriam: might want either or both<br> <fantasai> miriam: doesn't remove need for multiple borders<br> <fantasai> miriam: I like the just list them syntax, and disagree that we always want solid<br> <TabAtkins> box-shadows all stack on top of each other; people "use box-shadows" by using a wide, fully opaque shadow, then gradually adding narrower shadows.<br> <fantasai> miriam: def situations where combining dots with solid and dashes could get interesting results<br> <fantasai> miriam: so not a useless feature<br> <astearns> ack lea<br> <fantasai> lea: box-shadow is what ppl have, but it's a hack<br> <TabAtkins> I challenge Miriam to come up with a single example of two-dots that doesn't look horrible. ^_^<br> <fantasai> lea: You have to adjust all the lengths because they stack z-axis, not in space<br> <fantasai> lea: We could use outline, but they are used for focus rings<br> <fantasai> lea: We could have an outline-inset that goes on the inset<br> <ntim> (box-shadow is easier to implement because it would be a parse-time translation)<br> <dholbert> (TabAtkins / emilio - I just checked `groove`, following up on Tab's question a few minutes ago, and Firefox/Chrome both antialias it, based on a screenshot of `data:text/html,<div style="border: 2px groove black">Hello` on my 150% HiDPI screen on Linux)<br> <fantasai> lea: A few other things to mention<br> <oriol> q+<br> <miriam> I didn't say _every_ combination would look good :)<br> <fantasai> lea: Current stripes() has indirection issue. I need to add up my stripes. Should be able to specify intent directly<br> <fantasai> lea: Weird to have two border-width properties, but hope is that weirdness is internal<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <miriam> but I think dotted, solid, dotted could look great<br> <fantasai> lea: people will very rarely need to set border-width-foo themselves<br> <fantasai> lea: listifying also allows to easily set sizes and colors independently, which is useful<br> <fantasai> lea: wrt snaps, any solution we pick will have this issue<br> <fantasai> lea: We could skip allowing flexin, but then authors will do it themselves with calc(), so you still have to deal with rounding<br> <fantasai> lea: so seems better to have author intent directly so we can make intelligent decsions<br> <fantasai> lea: Oriol mad epoint I made around how it is confusing to specify multiple colors per side<br> <fantasai> lea: but people generally don't do it<br> <fantasai> lea: it's not controversial that it's awkward<br> <TabAtkins> thanks, dholbert, that's useful to know. and presumably negates emilio's point about needing to snap the stripe colors, then. ^_^<br> <fantasai> lea: I agree<br> <fantasai> lea: but not a confusing thing that people will hit<br> <florian> q?<br> <fantasai> lea: Also he said you need to specify solid multiple times, that's how this works<br> <fantasai> lea: but if you wnat to specify once, it's easy, following existing pattern just set border-style after the shorthand once<br> <fantasai> lea: Wrt confusing stripes() direction that tim mentioned<br> <fantasai> lea: I agree, it's confusing<br> <fantasai> lea: Would expect it to work like background clipping<br> <dholbert> (I disagree that it negates emilio's point; I don't think we want to draw inspiration from how 'groove' is implemented...)<br> <adamargyle> +1 reserve stripes() for something else some other time<br> <astearns> ack florian<br> <Zakim> florian, you wanted to bikeshed and propose "bands" instead of "stripes"<br> <miriam> q+<br> <fantasai> florian: To extent that name is problem, maybe consider bands() or something<br> <fantasai> florian: calculating the total is annoying, well, we can introduce an `auto` value<br> <lea> q+<br> <fantasai> florian: sum up all the definite lengths<br> <noamr> color-sequence?<br> <fantasai> lea: yeah, it'd be weird to do that with stripes() but with border-width-foo would be fine<br> <lea> s/border-width-foo/border-width-relative/<br> <fantasai> oriol: Instead of adding a new auto size, we could say that if you specify border shorthand and you omit the width component then it could automatically take from stripes function<br> <lea> that means we can no longer use `border-color` in the whitelist of properties that don't affect box model<br> <fantasai> oriol: if you specify in border-color wouldn't be able to, but for shorthand could do it<br> <fantasai> lea: [comment above]<br> <fantasai> oriol: wouldn't have an effect, only when setting shorthand<br> <fantasai> astearns: not hearing consensus, so take to 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/13044#issuecomment-3526041843 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 07:29:09 UTC