- From: Noam Rosenthal via GitHub <noreply@w3.org>
- Date: Fri, 26 Dec 2025 19:04:43 +0000
- To: public-css-archive@w3.org
> 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. +1. Adding a name/reference pair to the mix is not going to reduce complexity here. > * 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). 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. > * 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. > * 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? -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3693248783 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 19:04:44 UTC