- From: Noam Rosenthal via GitHub <noreply@w3.org>
- Date: Sat, 27 Dec 2025 20:51:20 +0000
- To: public-css-archive@w3.org
> 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](https://github.com/mirisuzanne) in [[css-borders] allow multiple borders #13044 (comment)](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3526126572) > * [@JoshTumath](https://github.com/JoshTumath) in [[css-borders] allow multiple borders #13044 (comment)](https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3528964439) > * [@kepstin](https://github.com/kepstin) in [[css-borders] allow multiple borders #13044 (comment)](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](https://github.com/tabatkins), and more recently highlighted in [@noamr](https://github.com/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. That's not the issue though. The problem is that different borders by side already exists so reading listified borders that mean something different feels ambiguous. If we were to design borders from scratch in a world where different borders per side didn't exist perhaps I'd feel differently. This: ```css border: solid #000 1px, dashed red 3px, solid #000 1px ``` Reads to me like top/right/bottom or something like that. It needs somewhere that says "this is different from classic per-side borders". That's why I thought of a function-style but all of these are tradeoffs. btw I think it would be good to brainstorm this in a F2F or a breakout or something similar. -- GitHub Notification of comment by noamr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3694217134 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 20:51:21 UTC