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

At the risk of sounding like a broken record, it's still unclear to me what is the issue with [my listification strawman](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3474612084), which is by far more consistent with how this problem is solved in other parts of the language.

I just did another editorial pass in hopes it might help alignment because I’m genuinely baffled. To me it seems like it lets us have our cake and eat it too:

- ✅ Listification on par with how other CSS properties work
- ✅ Natural syntax for common cases
- ✅ Can be used without learning any new primitives (I can see authors trying the shorthand version even without seeing it in the docs)
- ✅ `border-width` that is backwards compatible and still provides a hard guarantee about the shape of the box model
- ✅ Can set **either** total width **or** individual widths without mental math in either case
- ✅ Keeps border width, style, and color orthogonal (or at least as orthogonal as they previously were)
- ✅ Preserves `border-color` as a non-layout-affecting property.
- ✅ Actually useful for border-styles != `solid` (whereas `stripes()` just produces [extremely weird results](https://drafts.csswg.org/css-borders/images/multicolor-border-dotted.png))
- ✅ Allows widths, colors, and styles to cascade separately, even when set by different sources
- ✅ Better pixel snapping behavior (I think?)

It seems to me that it pretty much solves nearly all issues, and provides very elegant syntax for 100% of the use cases that actually matter, so I’m not sure why we're exploring vastly more convoluted solutions instead of working towards making listification work (lots of room for improvement in my proposal!), which is the most natural, CSS-y solution to this. Occam's razor!

I just re-read responses and it seems that several people have expressed support for listification, but their voices have been drowned out:
- @mirisuzanne in https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3526126572
- @JoshTumath in https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3528964439
- @kepstin in https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3543092710

Additionally, [both](https://x.com/LeaVerou/status/1985123158370680869) [author polls](https://front-end.social/@leaverou/115482600983968371) overwhelmingly show support for shorthand listification over functional syntaxes, at least for the simplest, most common cases.

A lot of the initial pushback around complexity seems to have been around issues that were addressed with the Nov 22 edits, which introduced `border-width: auto` as the new initial value and removed the warts around `border-style`.
Among the rest:

### Not great for separate colors/styles/widths per side 

This seems to be the biggest point of contention. It was [raised](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3482546664) by @tabatkins, and more recently highlighted in @noamr's [summary](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3686683356):
> Listifying in the way proposed here feels confusing because it's not clear when we are listing the 4 sides vs. listing outwards-going borders.

I think we tend to over-index on this because we see the entirety of the syntax. I will repeat that separate colors/styles/widths per side are exceedingly niche even for one border. I have only seen them for:
- Creating triangles (a hack now obsoleted by better techniques)
- Creating the illusion of height (e.g. in a button), by having different border-widths
That’s about it. 
Separate colors/styles/widths per side **for multiple borders** are practically nonexistent. I cannot recall a single real-world example. **I strongly suspect we are investing a ton of effort solving problems no-one has, and in the process making the solutions for the real problems that authors _do_ have a lot worse.**

Note that I’m not including cases where you *only* have borders on certain sides. That *is* common, but is not a problem with this syntax: you'd just use e.g. `border-left` instead of `border`.

Additionally, I’d argue this is not a listification problem, it's a problem inherent in the language when it comes to these things, e.g. look at the 8 value `border-radius` syntax!
We just don't have any precedent of listifying side properties (I think).

Arguably, it's not even a CSS problem! It occurs whenever you have MxN values that you can only specify with a specific grouping. In some cases it makes more sense to group by M and in other cases to group by N. It also comes up when writing out HTML tables, CSV, JSON etc.

If we determine it's such a big problem, we can solve it much better via grouping functions, which would help single border cases too (by letting them be specified in the shorthand), e.g. `border: 7px solid sides(red, yellow, lime, aqua)`.

### Multiple border styles is a bad idea

@tabatkins was against having multiple border styles, but from reading [their comment](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3482546664) it seemed to me that the issues were aesthetic, not around implementation difficulty. 

Since then, use cases have emerged for multiple border styles (e.g. the complex example [here](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3474612084), and @mirisuzanne brought some up too), so unless multiple borders are actually hard to implement they seem nice to have. Not necessary, but also not something we should go out of our way to actively *avoid*, unless they are hard to implement.

Having to repeat `solid` to specify the number of borders is not great (if we decide that `border-style` is the list length determining property), but nobody is forcing us to use `border-style` for this. Given the way the proposal is designed, `border-color` can absolutely be the list length determining property, and is much more natural for this role.

Meaning, this (with nothing else applied) would actually produce two `medium` borders, one white and one black:

```css
border-color: white, black;
border-style: solid;
```

### "But what about gradient borders!"

@tabatkins and @noamr raised that it doesn't do gradient borders as an issue. It is unclear to me why this may be something we should design around. I have not seen anyone need gradient borders of that type, at least outside of demos. @tabatkins said "That style isn't particular common these days, but the 3d border styles we used to have utilized it, and that style might return.". There is an infinite set of styles that _may_ or may not come into fashion in the future. That's not a reasonable way to design language features.

But even if gradient borders were in high demand, I don't see how this:

```css
border: 7px solid stripes(red, yellow, lime, aqua, blue, purple, fuchsia);
```

is meaningfully better than:

```css
border: 7px solid;
border-color: red, yellow, lime, aqua, blue, purple, fuchsia;
```

and while more verbose, this is less cognitively taxing:
```css
border: solid; /* or border-style: solid; */
border-color: red, yellow, lime, aqua, blue, purple, fuchsia;
border-width-relative: 1px;
```

In the latter, I didn't need to count how many colors I have and multiply their number by the border width I want each individual color to have.

And as @mirisuzanne [pointed out](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3526126572), **authors don't want that type of gradient border**. When they *do* use gradients, they are of the type that was addressed by [`background-clip: border-area`](https://github.com/w3c/csswg-drafts/issues/9456).
I worry that this gradient border thing is yet another case of solving problems no-one has, and prioritizing them above real problems that authors have repeatedly demonstrated they have.


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


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

Received on Saturday, 27 December 2025 19:08:16 UTC