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

> > I'm pretty sure that with that, if one of the longhand properties has more things in its list that another longhand property from the same shorthand, then it just automatically repeats the things you have in your shorter lists
> 
> That is not correct, it's not the property with the largest list the one that decides. E.g. for backgrounds, if you have five of `background-size`, but only two of `background-image`, then you only get two background layers. The 3 extra background sizes are ignored. See [drafts.csswg.org/css-backgrounds-3#layering](https://drafts.csswg.org/css-backgrounds-3/#layering)

Yes, for each listified set of properties, we tend to pick one longhand that determines the length of the list. In backgrounds that's `background-image`, in animations it's `animation-name`, etc.

----

I _really_ like the idea of a `@border-style` rule for custom border styles, but I don't think it's the right solution for this problem.

Generally, separate rules that define things that need to be referenced are much more heavyweight for authors, and introduce a lot of complexity around scoping etc. They are good for making complex things possible, not for making simple things easy.

Additionally, for this particular proposal:
- A lot of the proposed syntax makes no sense to me. Without the comments, I wouldn't even be able to guess what was being specified.
- The `border-color()` function feels like a `var()`, so perhaps it should be a `var()` or something that nods to it. (possibly `var-nth()` for getting the nth value of a comma separated list?)
- Color, shape, and size should be separate, not all specified via `fill` (which has an existing meaning, see fill-stroke module)

That said, I think there are some *really* good ideas in there, and this should be explored as a separate proposal.

----

My position continues to be:
- This is the poster child of problem where the _vast_ majority of cases is very simple, but there are many niche complex cases and trying to solve for them will lead to **worse designs**. Instead of proposing solutions, we should first reach consensus about what the common cases are, and solve for them.
- I (quite strongly) believe that **the use case of separate border-styles, colors, or widths per side is niche and not worth optimizing for.** I'm fine with it having poor ergonomics if it helps us resolve on a solution that has good ergonomics for the common case and is consistent with the rest of the language. These cases should be *possible*, but they don't need to be *easy*, and should definitely not be syntax drivers! We can always introduce syntax later on that lets you group differently when using the shorthands, but anything that makes these cases easier should be a nice-to-have.
- The main things to optimize for IMO are:
  - multiple (but few) borders with the same color/style/width across all sides
  - specifying either the total width OR the individual widths without having to do manual math in either case.
  - I suspect that even within this set, 2-3 solid borders with the same width are > 50% of use cases.
- 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.
This rules out the `total-width()` idea as proposal. Total width needs to be the default for this property.
- Similarly for compat, **`border-style` and `border-color` should not be affecting box model dimensions**.
- Many of the functional solutions proposed here seem to be doing the same thing as [my most recent proposal](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3474612084), with worse ergonomics since some of the semantics that were done via separate properties are now done via functions, which means they cannot cannot cascade or be overridden separately etc. 
- Functions introduce the additional complexity that their return type needs to be specified. 
  - For `stripes()`, this forced us to introduce the complexity of `<1d-image>` values.  
  - For `total-width()`, it's unclear what the return type is. It cannot be just `<length-percentage>` or whatnot, as it's basically specifying a `<length-percentage>` with additional metadata . We can avoid this by having syntax instead of a function, e.g. a keyword. But since specifying the total width needs to be the default (see above) we'd need some pretty weird syntax that specifies a keyword and then the list of values the keyword applies to, without using a function. Having a dedicated property for this is much cleaner and avoids all this complexity.
  - Same for `border-set()`, but at least we could define that as a custom `border-style` of sorts.
- 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`? 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. 

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


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

Received on Friday, 26 December 2025 15:03:40 UTC