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

@Loirooriol 
> > For compat, `border-width: 1px` must continue to specify the total width
> 
> How so? E.g. `border-width: 1px; border-style: solid, solid` could end up with a total width of 1px+1px=2px and this is new syntax, so not constrained by compat.

Remember that the `border-width: 1px` and the `border-style: solid, solid` might be cascading from different sources, each making different assumptions.
When forced to pick the lesser of two evils, I think _not_ breaking box model assumptions is far more important than not breaking stylistic choices.

Additionally, if `border-color` is chosen as a the property that determines the length of the list, it means that we can never expose it in whitelists of non-layout affecting properties, whereas it currently could be included. And making `border-style` the property that determines the length of the list is pretty weird.

> > we should first reach consensus about what the common cases are, and solve for them
> 
> I think we should reach consensus on the minimal usecases that we want to support. E.g. while separate border-styles would be nice to have, I'm not sure we have to necessarily allow that. If they are not covered, `stripes()` seems the simplest mental model for me. But if they need to be covered, then `stripes()` doesn't suffice.

I think separate border styles are a nice to have, but not a hard requirement. There are, however, valid use cases for them (as discussed earlier), and ideally we should not pick a syntax that actively excludes them.
I think even separate colors/styles/widths per side can be a nice-to-have, I'd be totally fine with syntax that doesn't even allow it, as there is always the escape hatch of nesting multiple elements.
`stripes()` has the issue I mentioned earlier, as it requires mental math for setting the total border width. Additionally, it makes it impossible to set the colors separately from their widths (even with custom properties!), which I can see as being useful.

-----


@noamr 
> > * For **compat**, `border-width: 1px` **must** continue to specify the total width. This is a non-negotiable requirement, as a lot of existing content depends on a box model with certain dimensions. Same for a single border specified via the shorthands.
> > * Similarly for compat, **`border-style` and `border-color` should not be affecting box model dimensions**.
> 
> Note that `border-style` also affects the box model (when `none` vs something else). 

That's a good point!
Point still stands for `border-color` though.

> I don't know how bad it is to extend the effect `border-style` has on layout in terms of web compat. I think it's probably the only way to effectively expose the mental model of "multiple borders" without creating too many gotchas around pixel snapping or ambiguity between border listification and side listification.

> If we go with the above constraints, I doubt that we'd reach something substantially different from `stripes`. btw `stripes` seems like it can be a little finicky when it comes to pixel snapping.

Any solution seems like it would have the same gotchas around pixel snapping, so I think this may be a red herring. But I agree that something like `border-set()` seems to have similar issues as `stripes()`.

> > * I think solutions that break the orthogonality of style, border, and color, are severely problematic. Let's take the `border-set()` idea as an example. What happens when authors combine it with a `border-color` or `border-width`?
> 
> I'm suggesting that when using `border-set`, `border-color` and `border-width` act as a fallback for browsers that don't support `border-set`. In addition, `border-color` can be used in an interesting way, with a keyword like `currentbordercolor`, allowing relative colors and using it as a way to have different colors per side without making the `border-set` function express this complexity directly.

Experience shows that whenever we introduce syntax that makes other syntax not work, that ends up being problematic. Authors are confused why their perfectly valid syntax has stopped working, and/or have very valid use cases in mind around combining the two primitives and are puzzled why things don't work. Positioning and layout is a common example of this.
Closer to borders, its inability to play well with the rest of border/corner syntax is part of the reason why `border-image` is so underused.
Generally, it's an antipattern to design solutions that are escape hatches which force you to recreate things you could have gotten cheaply before, just to get a small increment of power.

Also, preserving cascading of these properties separately is important. The geometry of the borders and their colors are often set via different parties. E.g. a design system may set border widths and styles, whereas individual components or uses customize their colors by assigning different design tokens to them.

None of these is a complete dealbreaker, but the advantages a given proposal with these issues brings need to justify its downsides.

The potential for using `border-color` as a variable however to produce relative colors in a custom border style is _really_ interesting. And on par with how some of the native border styles work. E.g. `groove`, `ridge`, `inset`, `outset` all take `border-color` as input and produce derivative colors for shading.
But, just like `@border-style`, I see this as an interesting feature for making border styles more customizable, and I don't think it's the solution for multiple borders, where the colors desired may be entirely different.

> > * We should not be considering only how things are set, but also how do they cascade, how do they behave when set via different sources (e.g. a design system sets defaults that individual use cases can customize), what the computed style is, etc.
> 
> I think that people that use `border-set` for multiple borders would most likely cascade custom properties and assemble them at the end. Is there any scenario that's not good enough for?

Custom properties are great in tightly coupled scenarios, where it's the same party setting both. They don't work well in scenarios where different parties are setting each design component, which could be argued is the fundamental scenario cascading was designed around. When there is a clear hierarchy of responsibilities (e.g. design system > design system components > design system users) it can work, but it falls apart when there isn't one (e.g. design system + component from different sources). 

This is also the case when authors are overriding UA styles. E.g. if a UA style is using this to ensure a legible outline regardless of background, how is the DX for authors wanting to customize the light and dark colors used without overriding the geometry as well?


-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3694143606 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 18:27:21 UTC