- From: Lea Verou via GitHub <noreply@w3.org>
- Date: Sun, 02 Nov 2025 23:35:41 +0000
- To: public-css-archive@w3.org
I don’t have much of a horse in this race, if folks love `stripes()` that much, fewer new things to be specced 😅 That said, it has been 3 years since @SebastianZ [added it to the spec](https://github.com/w3c/csswg-drafts/pull/7029), so it’s time to consider why it has not been picked up by anyone despite the problem it’s solving being very common. IMO, it’s because it’s an overcomplex solution to the problem, introducing a new concept to the language without sufficient justification (e.g. other use cases being solved), and requiring authors to transform their mental model from borders as box strokes to borders as stripes painted on a given surface. Complexity is not just about syntax signal-to-noise, the cognitive overhead of having to transform input to a different mental model is far worse than typing a few extra characters. **Nobody** looks at this and thinks _"ooh, I know, I need **stripes** around it!"_ <img width="224" height="177" alt="Image" src="https://github.com/user-attachments/assets/152738f9-2bbb-45b8-a593-59414f472f20" /> Additionally, even if people _were_ thinking of it in terms of stripes, what does `border: 2px solid stripes(white, black)` even mean? There are infinite ways to paint the border area with black and white stripes, and there is nothing in the syntax indicating which one this is. @SebastianZ > @LeaVerou Your proposal seems much more complex to me than the current solution via stripes(). _Both_ are my proposals 🙂 The complexity of the new proposal is primarily **internal** (or at least that’s the hope), in how things are resolved, but hopefully, the outwards API exposed is simple and much more aligned with how borders are currently specified and reasoned about. Also, there are two mental models to think about widths when you have multiple borders: 1) via the width of the individual borders 2) via the total width of the border area, which is then divided into multiple colors. Both come up, but the former is _much_ more common. The `stripes()` way only supports the latter and requires authors to transform their mental model in the common case. The newer proposal supports _both_. ---- @noamr > Another thing I'm concerned about here is that borders also affect layout and this can get really messy... Why? The total width is well controlled via `border-width`, and that’s what's affecting layout, not how it’s painted. ---- @Loirooriol > I don't like the complexity of this other proposal that allows specifying multiple border styles if then > > more than 1 border makes all non-none border styles compute to solid > `border-image` has its own problems like not respecting `border-radius`, so I don't think it's a good solution. I agree that it’s always suboptimal to have properties restrict their values based on other properties. That said, using `border-radius` together with `border-image` is a pretty common need, whereas the vast majority of borders being used in today’s UIs are `solid`, to the point it has become boilerplate. Also, this was proposed as a temporary measure, so implementations don't need to deal with unnecessary complexity up front. It may end up not being needed, since UAs already have code to paint these borders. It may even turn out to be easier than the current `stripes()`-based solution that requires them to implement dots and dashes painted with multiple colors, which no-one needs, ever. This is [a real example from the spec](https://drafts.csswg.org/css-borders/#border-color)! <img width="450" height="270" alt="Image" src="https://github.com/user-attachments/assets/56a65967-2cd6-4589-a342-5324b851664b" /> ---- Again, I’m sure there are warts to be figured out, but I think finding a good way to listify border properties is a much better path forwards than `stripes()` (for borders — nothing against better ways to do stripes for backgrounds!). Anyhow, because data is better than opinions, I posted two polls: - https://x.com/LeaVerou/status/1985123158370680869 - https://front-end.social/@leaverou/115482600983968371 So far, they seem to be **sweepingly** verifying my hypothesis with < 10% voting that the stripes() syntax makes more sense to them and almost 90% voting for some form of listification. Some quotes: > Calling it "stripes" when you want there to be exactly 2 colors seems wrong. It's much easier conceptually to add two borders together rather than make 1 border and then divide it in 2. > I literally tried A before and was confused when it didn’t work. > is the ‘2px’ meant to imply total width, half of which is one colour and half is another? I think that would be very confusing. > I think a syntax where you effectively specify multiple borders (option A) makes most sense to me. > the first one is more compatible with existing css syntax dont you think ? > I definitely prefer a syntax where I specify the width of each border, not the combined width. With B or C, what would happen if I specified a third color? Honestly, after seeing these responses I think _any_ form of listification is better than `stripes()`, even one with all the problems i originally pointed out in #2532. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3478492464 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 2 November 2025 23:35:42 UTC