[css-borders] allow multiple borders

[jsnkuhn]

We've been hacking our way around the lack of official multiple border options for years with box-shadows, outline, drop-shadow. It seems like it's long past time to just allow multiple borders in a straight forward way.

problems with the current options:

• Hacking borders with outline on elements with focus messes up accessibility. Causing devs to need to replace that functionality. Often in reality this does not happen.

• Hacking borders with box-shadow leads to uneven "borders" on non 100% zoomed OS.

• Hacking borders with drop-shadow usually requires a large number of shadow because it's missing a spread option. Also has the same issue with non 100% zoomed OS.

Proposing to look something like this:

border: solid #000 1px, dashed red 3px, solid #000 1px;

border: solid var(--background-color) 3px, solid #000 2px;

[Loirooriol]

For a solid style (which is probably the most common usecase), the spec already has

border: solid 5px stripes(var(--background-color) 3px, #000)

[jsnkuhn]

yes, I've seen that and am not a fan. This proposed syntax takes into account the existence of those other border-styles. They don't get used as often but they still exist and so can not be ignored.

My understanding from the original proposal for stripe() was that it was intended to fix aliasing issues with existing solid stopped gradients. The rendering on the right was my understanding of what stripe was intended to be used for. (https://codepen.io/jsnkuhn/pen/PwPwoby?editors=0100)

It seems to me what your currently trying to do with stripe() in border here would be better accomplish by adding a square-gradient syntax?

[Loirooriol]

it was intended to fix aliasing issues

I don't think so. It was just having borders with multiple colors AFAIK.

Your examples don't look like borders to me? They rather seem like a linear gradient background-image.

[LeaVerou]

I do agree that at first listifying seems like a better solution, but if you dig a little deeper, it causes a bunch of weird side effects. See #2532 for a discussion.

That said, I don't much like stripes() (even though I proposed it 😂). I think it's a very weird and overcomplex solution to the rather simple use cases it's trying to solve. It would be much better if we could come up with a solution that is geared around listification of border properties.

The main problem is that we want this:

border-width: 10px;
border-color: red, black, white;

…to specify a 10px border, not a 30px border.
But on the other hand, this:

border: 10px solid red, 10px solid black, 10px solid white;

…should totally specify a 30px border!

There is also the issue that listification combines very oddly with the multi-side syntax:

border-color: skyblue orange yellowgreen indianred, black yellow

This is a completely nonsensical way to specify border colors. People think of all colors for a side as a group, they don't group colors by whether they are innermost or outermost.
Though different colors for each side are pretty rare, so I’m not sure this is a concern we should design the syntax around, and definitely not just cause for complicating the simple case.

Just as a strawman, what about:

• border-color is listified
• border-style may or may not be listified. Perhaps not listified in v1? We could even declare that more than 1 border makes all non-none border styles compute to solid if it would help implementors, since I've never seen a use case for anything else.
• border-width is not listified and specifies the total width
• border-width-relative: [<flex> | <length>]{1, 4}# (name TBB) which specifies relative proportions in fr (initial value: 1fr).
• To compute the actual rendered total border width, we take the sum of all lengths in border-width-relative and then use that OR border-width, whichever is larger.
• border is listified but lengths specify border-width-relative directly and border-width as the sum of all length-based widths (or just 0 and let the resolution rule above work its magic).

Note that border-width is intentionally not a shorthand that includes border-width-relative: we want setting border-width: 1px to work as expected, and set the border to a 1px border, not a number of colors × 1px border.

Some more examples:

The driving use case for stripes() (a black and a white 1px borders) would be either of these:

border: 1px solid white, 1px solid black;

border: white, black;
border-style: solid;
border-width: 2px;

border: white, black;
border-style: solid;
border-width-relative: 1px;

Rainbow border:

border-color: red, yellow, lime, aqua, blue, purple, fuchsia;
border-color-relative: 1px;

Border that is a generalization of double, with a custom color between two 1px borders:

border: white, red, white;
border-style: solid;
border-width-relative: 1px max(1px, 1fr) 1px;

Would produce a border that is of total width medium (border-width initial value) or 3px (whichever is larger) that consists of two 1px white borders, and 1px or more red, depending on what medium resolves to.

---

Clearly this needs work, as it's a strawman I just came up right now, but I think it's a much better direction than stripes() (and likely easier to implement?).

CC @fantasai @SebastianZ @noamr (fellow co-editors)

[noamr]

A thought that comes from reading this.
Can some of these use cases be generalized as a gradient, given that gradients can be made to look like stripes?
Then if we can have a version of border-image that uses a different image per-border, or something to that effect, perhaps we gain the entire CSS image ability to style the borders rather than having something bespoke?

[LeaVerou]

A thought that comes from reading this. Can some of these use cases be generalized as a gradient, given that gradients can be made to look like stripes? Then if we can have a version of border-image that uses a different image per-border, or something to that effect, perhaps we gain the entire CSS image ability to style the borders rather than having something bespoke?

That’s basically the direction of stripes(), but I think introducing a new concept of a <1d-image> into the language is overkill for this, which may explain the lack of implementations despite it being in the spec for a while now. I also think it's too far from author intent — people are not thinking in terms of stripes for these effects, they are thinking "I want two borders".

[noamr]

A thought that comes from reading this. Can some of these use cases be generalized as a gradient, given that gradients can be made to look like stripes? Then if we can have a version of border-image that uses a different image per-border, or something to that effect, perhaps we gain the entire CSS image ability to style the borders rather than having something bespoke?

That’s basically the direction of stripes(), but I think introducing a new concept of a <1d-image> into the language is overkill for this, which may explain the lack of implementations despite it being in the spec for a while now. I also think it's too far from author intent — people are not thinking in terms of stripes for these effects, they are thinking "I want two borders".

Ah gotcha.
Another thing I'm concerned about here is that borders also affect layout and this can get really messy...
Would it make sense to introduce something like this for outline instead? outline has the advantage of not affecting layout in addition to having a uniform width/style.

[Loirooriol]

I like stripes(). 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.

[Loirooriol]

Another thing I'm concerned about here is that borders also affect layout and this can get really messy...

And that's precisely why stripes() is good: it's confined to border-color, which doesn't affect layout.

Would it make sense to introduce something like this for outline instead?

stripes() is also defined to work on outline-color. I don't think it's good to force authors who want multi-colored borders to use outlines.

[Crissov]

((As part of a larger work-in-progress proposal, I recently pondered how to use stripes as (non-fading) gradient lines, and perhaps vice versa. This feels missing from 1D and 2D images, although the background properties can already achieve some of it.))

[SebastianZ]

@LeaVerou Your proposal seems much more complex to me than the current solution via stripes().

To compare it with your example, here's how it looks using the current syntax:

border: 2px stripes(white, black);

Furthermore, your proposal seems to be similar to the resolution from the Tokyo F2F 2017 with the differences of border being listified and a new border-width-relative being introduced. And those two changes increase the complexity.

Also, it's not totally clear from your proposal how all the border-* longhands are affected by this.

Would produce a border that is of total width medium (border-width initial value) or 3px (whichever is larger) that consists of two 1px white borders, and 1px or more red, depending on what medium resolves to.

Side note: medium is defined to be 3px wide.

@jsnkuhn:

yes, I've seen that and am not a fan. This proposed syntax takes into account the existence of those other border-styles. They don't get used as often but they still exist and so can not be ignored.

As currently defined, border-style still does affect the rendering when using stripes(), see https://drafts.csswg.org/css-borders-4/#border-color:~:text=The%20same%20border%20colors%20with%20border%2Dstyle%3A%20dotted.

What you currently can't have with the current solution is different border styles. Though as noted by @LeaVerou in #2532, there aren't many use cases for that. And if there were, we could still introduce a solution that listifies border-color and border-style.

My understanding from the original proposal for stripe() was that it was intended to fix aliasing issues with existing solid stopped gradients.

Which "original proposal" are you referring to? As noted by @Loirooriol, stripes() was initially introduced to solve the use case of multiple borders.

@Crissov:

((As part of a larger work-in-progress proposal, I recently pondered how to use stripes as (non-fading) gradient lines, and perhaps vice versa. This feels missing from 1D and 2D images, although the background properties can already achieve some of it.))

For "solid stopped gradients" we resolved on adding *-stripes() functions in #7244 (comment).

---

The only thing that still feels a bit strange to me is that we defined <image-1D> for border-color and outline-color, while it actually defines an image. See #9735 for a discussion around that.

But in general, I still believe stripes() is a straightforward solution for defining multiple borders.

Sebastian

[LeaVerou]

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, 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!"

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!

---

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 always 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 >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.

[LeaVerou]

@noamr

Would it make sense to introduce something like this for outline instead? outline has the advantage of not affecting layout in addition to having a uniform width/style.

We can't piggyback on outline for all use cases as that tends to be used to indicate focus.
💡 That said, another solution might be to introduce a new outline-like property, e.g. outline-inset, and then listify both outline properties. That would also help with some use cases that currently hog outline with a negative outline-offset.

---

This idea is also quite interesting:

I like the idea of having multiple borders like in option A, but it feels "weird" to have both be 1px and the black one be outside of the white one. I would expect them to stack like the backgrounds, from top to bottom, instead of being cumulative. The border in the picture would be something like: border: 1px solid white, 2px solid black; But maybe that's not as intuitive? Also it may not work with transparent borders which may be something people want.