Re: [csswg-drafts] [css-borders] allow multiple borders (#13044)

@tabatkins All good arguments — in a theoretical universe where every possible combination is equally likely.

> multiple dots/dashes would look _horrific_

Yes, they would, but people rarely use anything other than `solid`. If it helps, we could simply not listify `border-style`, but then you end up with the weirdness we have in `background` where `background-color` can only be specified in the last layer, and cannot be combined with anything else. FWIW I would argue that the striped dots that the `stripes()` solution enables also looks horrific. 

If multiple styles are hard to implement, that's one thing. But if not, IMO it's fine if they look horrific, because **nobody actually does that**. 
As a general principle, I think it's totally fine for weird edge cases to have weird syntax if it helps expose a nicer syntax for the things _people actually do_. Designing an API that is great for the complex cases that no-one needs and adds more complexity in the simple cases that people _actually_ reach for, is an antipattern.

> Further, as noted, understanding a comma-separated border-color that also sets different colors per side is, imo, near impossible. 

Yes, _as noted_ [**by myself**](https://github.com/w3c/csswg-drafts/issues/2532) so trust me, I’m well aware. 😁 
However, people rarely (if ever) do that anymore.
When styles have different borders per side, it's typically on/off rather than different colors, and they tend to do it by adjusting width, not color, because no-one wants angular hard transitions in the corners.

> Multiple border also doesn't allow for gradient fades unless you go to enormous effort faking it with stacked 1px borders. That style isn't particular common these days, but the 3d border styles we used to have utilized it, and that style might return.

`stripes()` also doesn't support gradient fades well? But most importantly, **nobody wants to do gradient fades in their borders**. Sure, this style might theoretically return, but prioritizing imaginary future use cases over the real use cases people actually have seems a very strange tradeoff.

> So that's why we settled on the design we did, and I still strongly believe it's the optimal solution, given the constraints. There are some alternatives that read better in the simplest possible case (all solid shape, each 'ring' the same color, which is the exact scenario you used in your poll), but fall apart the moment things get more complex.

Again, I’m well aware. 😒 I was there, and I supported `stripes()` at the time! But over time I realized I was also designing for these theoretical more complex cases that pretty much never come up in practice.

The _actual_ multi-border scenarios I have seen in real-world websites are:
- Simple: 2-3 solid borders, all the same width
- More complex: 2-3 solid borders, some with a different width

That’s literally it. And `stripes()` is currently suboptimal for both of these: You have to do mental gymnastics like "so I want each of my borders to be 1px wide, and I want 3 borders, so 3 * 1px = 3px". Or worse, "I want a 3px border and two 1px borders before and after it, 1px + 3px + 1px = 5px". Ideally, it should be possible to specify either the total border OR the widths of individual borders directly.

Of course my experience is not universal — it's entirely possible there are more complex use cases that are common and I simply haven't seen them or forgot about them.  If people actually do these things in the wild, that completely changes the tradeoffs involved. It would be very productive if those who believe more complex use cases are common (@tabatkins @noamr @SebastianZ @castastrophe @Crissov @Loirooriol), to bring some forwards.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3483209299 using your GitHub account


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

Received on Tuesday, 4 November 2025 00:36:31 UTC