- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 19:59:57 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders] Allow multiple borders by listifying them`, and agreed to the following: * `RESOLVED: Listify border properties with border-width determining the number of borders` * `RESOLVED: Drop stripes() from css-images unless independent use cases come up to justify it.` * `RESOLVED: 'border-style: none' is not a listifiable value. It cancels the entire border.` * `RESOLVED: Listify the outline properties in the same way.` * `RESOLVED: outline-style: auto cannot be listified` * `RESOLVED: outline-offset does not participate in the coordinated list property group, it outsets the innermost outline` * `RESOLVED: Specify inside-out order for now, mark issue prominently in the spec, open an issue in GH, and work on a poll of authors.` <details><summary>The full IRC log of that discussion</summary> <fantasai> lea: Awhile back we had demand for multiple borders, e.g. dark and light border to ensure visibility<br> <fantasai> lea: Also authors often want to nest borders for aesthetic reasons<br> <TabAtkins> q+<br> <fantasai> lea: Last time, we resolved to add a stripes() function that would be a 1D image<br> <fantasai> lea: Several problems<br> <fantasai> lea: 1) can't specify total border, need to specify individual widths<br> <fantasai> lea: 2) doesn't handle pixel-snapping for border-widths<br> <fantasai> lea: It's also overcomplicated solution, because introduces a new primitive not used anywhere else<br> <fantasai> lea: Also doesn't allow for multiple border styles<br> <fantasai> lea: And doesn't fit existing patterns, like listifying properties<br> <fantasai> lea: Original reason to not listify was, if you specify border-color: red, white, black; then you didn't want border-width: 1px to give you a 3px border<br> <fantasai> lea: Many solutions were posted in the thread<br> <fantasai> lea: One solution that we discussed yesterday is to listify the border properties, but make the coordinating list base property be border-width<br> <fantasai> lea: It preserves the guarantee that `border-width: 1px` gives you a 1px border width<br> <fantasai> lea: It preserves that border-color doesn't change the border width -- this keeps it safe for certain places where you can't use layout-affecting properties<br> <fantasai> lea: No new concepts, no new properties, it's the existing primitives we have extended in a way that has a lot of precedent.<br> <fantasai> lea: It doesn't allow you to set the total border width and divide it up<br> <dholbert> q+<br> <fantasai> lea: but that's problematic because each stripe would need to be pixel-snapped individually, and then you wouldn't necessarily get your specified total width<br> <fantasai> lea: The majority of use cases are 2-3 borders. more than that is rare.<br> <fantasai> lea: and we can easily extend to outlines<br> <fantasai> lea: So proposal is to drop stripes(), listify border properties with border-width as the base properties, and do the same with outlines<br> <astearns> ack TabAtkins<br> <fantasai> example: border-width: 1px, 2px; /* two border stripes */<br> <astearns> q+<br> <fantasai> TabAtkins: Agree. You can do some weird things, don't do them. Some things that are complicated are long to write, but that's fairl.<br> <miriam> +1 to this proposal<br> <astearns> ack dholbert<br> <fantasai> dholbert: So border shorthand, when serializing, would it have space-separated comma-separated lists?<br> <fantasai> lea: Yes<br> <fantasai> dholbert: If you don't specify all the colors, what happens?<br> <fantasai> fantasai: Repeat, just like backgrounds<br> <emilio> q+<br> <fantasai> lea: Poll on Twitter/Mastodon, and vast majority of authors preferred listifying border properties compared to stripes() or doing it with longhands.<br> <fantasai> lea: This allows both shorthands and longhands to work.<br> <fantasai> astearns: Serialization, assuing if the specified value is not a list, then absolute no changes to serializaiton?<br> <fantasai> lea: Exactly<br> <astearns> ack astearns<br> <fantasai> lea: One thing TBD is if you specify 'none' in your border-style property. Does that remove that particular border<br> <fantasai> lea: but it's a detail<br> <fantasai> florian: I think you can just say only 'none' for the whole thing<br> <fantasai> TabAtkins: Yeah, we have precedent in both directions...<br> <fantasai> lea: If none cancels out the particular value, it gives you something useful, but mildly<br> <astearns> ack emilio<br> <emilio> q-, was going to mention border-style<br> <fantasai> emilio: it's a bit weird but yeah<br> <noamr> With the CSS borders co-editor hat on, ship it!<br> <astearns> ack fantasai<br> <emilio> ack emilio<br> <emilio> fantasai: agreed that none should collapse the border to nothing<br> <dbaron> At least we're not doing the solution from 2001 in https://github.com/mozilla/mozilla-history/commit/1704f7364f3a92f7e6962fc7d9fb4dc6d7994ab6<br> <TabAtkins> I agree with Lea, a "none" sub-border should just collapse away that sub-border<br> <emilio> ... we can expand later<br> <fantasai> fantasai: we can make the restriction syntactically<br> <emilio> lea: are there any opinions that that this is the right solution<br> <emilio> florian: are there use cases to allow repeating?<br> <emilio> q+<br> <emilio> ... if we're not sure we can start restricted<br> <fantasai> florian: If we don't have a need, we don't need to make it work<br> <emilio> lea: it's a bit weird if we don't allow listifying anything<br> <emilio> fantasai: it's a bit easier to implement<br> <astearns> ack emilio<br> <fantasai> fantasai: mostly wrt testing<br> <fantasai> emilio: given 'none' already suppresses the whole border-width, it would be weird ... you're proposing to collapse the layer?<br> <lea> q?<br> <fantasai> TabAtkins: Yeah, it collapses to zero width<br> <fantasai> emilio: Don't see a use case, so slight preference to not allow none to be listifyable<br> <fantasai> TabAtkins: animations and transitions can listify none<br> <fantasai> TabAtkins: also have other way around, can specify none or a list<br> <fantasai> TabAtkins: I forget which ones<br> <fantasai> fantasai: Don't have to do it now, so let's not do it<br> <astearns> ack dbaron<br> <fantasai> dbaron: I think existing precedence for repeated properties (though I don't like these repetitions) is that computed values retain the original lengths<br> <fantasai> dbaron: if border-width has 3 values and border-style has 2 values, they still have those lengths<br> <fantasai> dbaron: But then they can't influence each other<br> <fantasai> dbaron: So it depends on 'none' not computing border-width differently<br> <fantasai> emilio: Yeah, we're shipping that. It's pretty straightforward<br> <fantasai> dbaron: supporting 'none' with the list makes it dependent on that<br> <fantasai> astearns: Sounds like we make it non-listyfiable for now<br> <lea> PROPOSED: 1. Listify border properties with border-width determining the number of borders<br> <fantasai> PROPOSED: Listify border and outline properties, using -width as the base property.<br> <lea> PROPOSED: 2. Drop stripes() from css-images unless independent use cases come up to justify it<br> <fantasai> RESOLVED: Listify border properties with border-width determining the number of borders<br> <lea> PROPOSED: 3. `none` in `border-style` cannot be part of a list, it cancels the entire box-model. Will revisit later.<br> <fantasai> RESOLVED: Drop stripes() from css-images unless independent use cases come up to justify it.<br> <fantasai> RESOLVED: 'border-style: none' is not a listifiable value. It cancels the entire border.<br> <dbaron> https://chromestatus.com/feature/5133099851317248<br> <lea> PROPOSED: 4. Do the same thing for outline properties<br> <lea> PROPOSED: 5. `outline-style: auto` also cannot be listified<br> <fantasai> fantasai: What is the resulting outline width?<br> <fantasai> dholbert: It's determined by the 'auto'.<br> <lea> PROPOSED: 6. `outline-offset` is not listified<br> <fantasai> lea: outline-offset? Is it listified?<br> <fantasai> [genera]: no<br> <fantasai> RESOLVED: Listify the outline properties in the same way.<br> <fantasai> RESOLVED: outline-style: auto cannot be listified<br> <fantasai> RESOLVED: outline-offset does not participate in the coordinated list property group, it outsets the innermost outline<br> <miriam> my instinct is inside-out<br> <fantasai> fantasai: Are we listing inside-out or outside-in?<br> <fantasai> fantasai: I think we should go outside-in, because the outermost is the most prominent.<br> <smfr> q+<br> <lea> q?<br> <fantasai> fantasai: Lea pointed out also that we should be consistent with border-shape's two-value syntax<br> <lea> q+<br> <smfr> q-<br> <astearns> ack lea<br> <fantasai> lea: Another precedent is that when ppl use box-shadow, they are listing these from inside out?<br> <iank_> q+<br> <fantasai> noamr: With border-shape, it's outside in. We never resolved on that, but it was Simon's proposal.<br> <fantasai> noamr: A lot of things are outside-in.<br> <miriam> backgrounds confuse me every time<br> <astearns> ack iank_<br> <lea> q+<br> <fantasai> iank_: Issue to spec how it works with collapsed borders<br> <miriam> ah, sure<br> <astearns> ack lea<br> <fantasai> for backgrounds, if you break on every comma, you see the stack from top to bottom<br> <TabAtkins> here we go, the box-shadow usage with a good example https://www.sitepoint.com/css3-multiple-borders/<br> <fantasai> lea: Seems like there's a lot of arguments about this. Maybe we should get more data from authors?<br> <dholbert> q+<br> <fantasai> florian: Feels very subjective, maybe culturally sensitive ...?<br> <noamr> We should accept the results of the poll if it matches what we think in advance :)<br> <fantasai> TabAtkins: let's just do a poll and see if we get a strong signal<br> <noamr> q+<br> <astearns> ack dholbert<br> <lea> qq+ to reply<br> <fantasai> dholbert: Mildly concerned about how this works with border-radius and corner-shape. If you have 3 hairline borders and a curve, need to preserve each hairline along the border?<br> <noamr> Oh I was going to reply<br> <fantasai> emilio: That's well-defined<br> <smfr> q+<br> <dbaron> Proposal for collapsed borders: for the tiebreaking purposes any multiple-border is treated by its total width and as a new "multiple" style that ranks second highest just below "hidden". The ordering (which side is inside and which side is outside) is determined by the element + side of the border that actually won.<br> <fantasai> emilio: You may antialiias a little bit in the curve<br> <astearns> ack noamr<br> <Zakim> noamr, you wanted to react to dholbert<br> <fantasai> noamr: Don't also listify the border-radius. One per corner. Works the same as double borders today that we have to do<br> <astearns> ack noamr<br> <noamr> q-<br> <astearns> ack smfr<br> <fantasai> smfr: Rendering 2 borders next to each other without anti-aliasing is super hard. Much easier to render a solid color and then render solid color on top of it<br> <fantasai> smfr: So really you want layered borders, rather than multiple borders<br> <fantasai> emilio: isn't that the case with border and outline?<br> <dbaron> (I think smfr was talking specifically about rounded corners but that didn't get in the minutes.)<br> <fantasai> smfr: Yes, we play painting tricks to make that work. But it'll get very complicated.<br> <fantasai> TabAtkins: If we apply border-rounding rules with each layer, why get more fuzzing than today?<br> <fantasai> smfr: With straight edges it's ok, but transforms or corner radius gets blurry<br> <astearns> ack lea<br> <Zakim> lea, you wanted to react to dholbert to reply<br> <fantasai> lea: For many of these things, mental model is nesting boxes.<br> <fantasai> lea: They have to adjust the border radius themselves, and they don't get access to pixel-snapping<br> <fantasai> lea: No matter what we do, we can do better than current workarounds<br> <TabAtkins> or people do box-shadows (and depend on them being opaque, so the overpaint is fine)<br> <fantasai> nsull: If two boxes taking up same space, or using shadows?<br> <fantasai> lea: 2 workarounds. 1. Use shadows or border+outline. OR 2. Nest elements<br> <fantasai> lea: If you nest them, you have to adjust the radius yourself etc.<br> <fantasai> dbaron: wrt why this case of borders is worse --<br> <fantasai> dbaron: normal way of doing anti-aliasing, you draw a thing and then say "this border covers 30% of that pixel, so we will make it 30% redder"<br> <fantasai> dbaron: Then you draw the thing that does the 70%.<br> <fantasai> dbaron: but what got lost is that the 30% and 70% were completely different parts of the pixel<br> <fantasai> dbaron: each draw operation you lose that information<br> <fantasai> dbaron: so what you actually end up drawing is 30% and 70% with random intersection where you've got 4 quads of each rather than 2 pieces that should together cover the pixel<br> <noamr> q+<br> <fantasai> dbaron: so you get a visible artifact there<br> <astearns> ack dbaron<br> <fantasai> dbaron: a lot of things today involve overlap, so you don't see the problem<br> <astearns> ack noamr<br> <fantasai> noamr: If it's difficult in a browser, I wonder people who do this today, it's probably even more difficult<br> <lea> +1 noamr<br> <fantasai> noamr: Fact that it takes some paint work to do correctly probably means it belongs in the Web platform<br> <dbaron> s/things today/the workarounds people use today/<br> <astearns> ack fantasai<br> <noamr> +1<br> <emilio> fantasai: [missed]. When you draw an element you want border-box sizing etc. The shape the user is perceiving is the shape of the outer edge of the border<br> <emilio> ... so that's the most prominent part of the border<br> <emilio> ... so if border shape is outside in, the listified border should go outside-in<br> <emilio> q+<br> <emilio> ... we should keep them consistent<br> <lea> I'm not comfortable resolving on this without any data from authors.<br> <astearns> ack emilio<br> <fantasai> emilio: When you specify border-radius, you're also specifying the outline of the outer bord<br> <dbaron> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cstyle%3E%0A%0Adiv%20%7B%0A%20%20border%3A%205px%20solid%20green%3B%0A%20%20border-radius%3A10px%3B%0A%7D%0A%0Adiv%20%3E%20div%20%7B%0A%20%20border-radius%3A%205px%3B%0A%7D%0A%0A%3C%2Fstyle%3E%0A%0A%0A%3Cdiv%3E%3Cdiv%3Ehello%3C%2Fdiv%3E%3C%2Fdiv%3E shows artifacts in Chrome today<br> <fantasai> [Clarified that border-radius is a corner property not a border property and doesn't get listified]<br> <fantasai> emilio: If I specified red, white, blue, would imagine from top to bottom....<br> <smfr> q+<br> <fantasai> emilio: But given fantasai's point that border-radius and other things go from outside in, I think I'm convinced we should go outside-in<br> <noamr> radial gradient is one of the only things that goes outwards<br> <fantasai> dholbert: As soon as you have more than one color, top to bottom or outside-in seems most intuitive<br> <lea> s/PROPOSED: Listify border and outline properties, using -width as the base property./RESOLVED: Listify `border` and `outline` properties and their longhands, using -width as the base property./<br> <astearns> ack smfr<br> <fantasai> smfr: Not sure replicating with multiple borders is the way to go<br> <fantasai> smfr: Might want to layer the borders<br> <lea> q+<br> <fantasai> smfr: Maybe we can have border blend modes ...<br> <noamr> q+<br> <fantasai> smfr: Widths that add up has antialiasing problems, but also might not do the things you want in some cases<br> <nicole> q+<br> <fantasai> TabAtkins: box-shadows overlap, but ppl don't use it that way. Use opaque box-shadow<br> <fantasai> TabAtkins: multiple boxes are drawn independently<br> <fantasai> hober: Good to start with the coping mechanism, but maybe that's not what pple wan tto do?<br> <fantasai> fantasai: Reason you can't use stacking is because people frequently want transparent stripes in between that let the background shine through, and you cannot do that with stacked painted borders.<br> <astearns> ack lea<br> <fantasai> lea: Stacked workaround already exists with box shadow, they can already do it with pretty reasonable DX<br> <fantasai> lea: what they can't do is what's proposed here<br> <fantasai> lea: and there are things you cannot do today, like transparent areas that show through<br> <fantasai> lea: als once different border styles come into question, you almost never want to stack them<br> <dholbert> scribe+<br> <astearns> ack fantasai<br> <dholbert> fantasai: if you have solid colors, and you know you have solid color stripes, you could draw them as stacked<br> <smfr> q+<br> <dholbert> (z-axis stacked)<br> <astearns> ack noamr<br> <fantasai> noamr: We can also allow a negative border-width, to allow you could go backwards. Then you can do things on top of each other<br> <fantasai> fantasai: I think that's not a bad idea!<br> <noamr> q-<br> <astearns> ack nicole<br> <fantasai> nicole: I like the simplicity of listing borders one at a time. That's what they think.<br> <fantasai> nicole: But the moment smfr described, started thinking of other possibilities. So maybe we can allow both.<br> <astearns> ack smfr<br> <fantasai> smfr: One way to specify this is to specify the inside and outside edge of each stripe<br> <lea> q+<br> <smfr> border: 0px 4px red, 1px 3px blue;<br> <fantasai> TabAtkins: I see what you're sayin,g and I think that's a vast overcomplication of the 95% case.<br> <nicole> q+<br> <lea> +1 TabAtkins<br> <fantasai> TabAtkins: For almost all cases we will care about, that'll do more than we want to do<br> <fantasai> dholbert: Snap edges to device pixels?<br> <fantasai> smfr: Could degenerate the stripes, e.g. 1 number becomes stripes<br> <fantasai> nicole: As long as when you leave it off it stacks one outside the other, seems cool<br> <astearns> ack lea<br> <fantasai> lea: I understand it sounds really cool, but agree with TabAtkins about how common it is<br> <fantasai> lea: Expecialy if we filter to what box-shadow can't already do<br> <fantasai> lea: If use cases do come up, we can always add a switch later so you have a listified border that later is stacked instead of arrayed.<br> <fantasai> lea: let's focus on what we need to do right now<br> <astearns> ack nicole<br> <noamr> +1<br> <fantasai> fantasai: So outside-in vs inside-out. Propose outside-out.<br> <lea> q+<br> <fantasai> smfr: If you're writing it causes a shift, so maybe better inside-out?<br> <fantasai> hober: My intuition is that we add going outward. I have a border, then add a second border<br> <fantasai> florian: Might depend on your box-sizing mental moder. If border-box, outside in and content-box inside out?<br> <fantasai> florian: Not saying we should change behavior, but mental model might be different.<br> <astearns> qq+<br> <fantasai> miriam: It's just much more intuitive to go inside out<br> <fantasai> florian: If you're sizing from the border box, you are pacing the borders from the outside in.<br> <fantasai> florian: If you're thinking from content box outward, you add out.<br> <fantasai> astearns: Let's pick one for now and open an issue.<br> <fantasai> astearns: Put a note in the spec, say this may change.<br> <fantasai> astearns: Seems like we are divided here.<br> <dbaron> Maybe it's natural if you're starting inside-out for an image but outside-in for a div.<br> <fantasai> astearns: I think we start with outside-in, because that matches border-shape.<br> <TabAtkins> i'm with outside for now. my intuition leans to inside out, but I want to poll<br> <fantasai> astearns: Might want to change them both if they need to change.<br> <noamr> https://github.com/w3c/csswg-drafts/issues/13308 is the relevant issue for border-shape<br> <astearns> ack astearns<br> <Zakim> astearns, you wanted to react to nicole<br> <astearns> ack lea<br> <fantasai> lea: I'm not comfortable resolving without getting data from authors, but I suppose we could follow this plan.<br> <fantasai> emilio: As long as the issue is very prominent in the spec so no one ships it.<br> <kizu> q+<br> <fantasai> kizu: For inside-out, if you have 1 border it's on the outside. If you think about adding borders, you add it outside.<br> <fantasai> kizu: Slightly different from thinking about backgrounds, but if you transition from one to another it might be better to think inside-out.<br> <fantasai> kizu: But could resolve either way for now.<br> <smfr> q+<br> <astearns> ack kizu<br> <astearns> ack smfr<br> <fantasai> smfr: If in the future we extend to each stripe has inside and outside, you want the ordering to match paint order.<br> <fantasai> smfr: So if we decide order here without painting order, we're locked into something there.<br> <fantasai> ChrisLilley: Not clear to me. Implementation can easily start painting at the end.<br> <fantasai> smfr: Paint order is what background is/<br> <fantasai> smfr: (reverse paint order)<br> <fantasai> smfr: whereas stripes is geometric order<br> <lea> Straw poll: What should `border-color: white, black;` do? https://usercontent.irccloud-cdn.com/file/SKzg5MiI/image.png<br> <fantasai> smfr: My proposal would have to require an inner and outer edge<br> <fantasai> smfr: In the future if we have 2 numbers ...<br> <fantasai> nicole: do we need a z-index number?<br> <fantasai> smfr: maybe it's ok<br> <fantasai> smfr: ok, I'm ok with either<br> <nicole> A<br> <TabAtkins> A<br> <lea> A<br> <fantasai> POLL: Borders are listed 1.) Inside-out or 2.) outside in<br> <miriam> A<br> <kizu> A<br> <fantasai> B<br> <ChrisLilley> A<br> <iank_> B<br> <smfr> A<br> <noamr> B<br> <astearns> A<br> <alisonmaher> B<br> <ntim> A<br> <florian> tess: A<br> <astearns> A for Tess<br> <emilio> A<br> <dholbert> (neutral)<br> <flackr> A<br> <bramus> A<br> <miriam> (but looking at it makes me feel less strongly, lol)<br> <dshin-moz> A<br> <lea> https://usercontent.irccloud-cdn.com/file/Hoj0fpaM/image.png<br> <florian> neutral (intuition is A, consistency argues B)<br> <fantasai> florian: The consistency argument makes sense<br> <dbaron> (I can't figure out which way the ones in https://bugzilla.mozilla.org/show_bug.cgi?id=112990 went...)<br> <dbaron> very weakly towards B I think<br> <fantasai> fantasai: Is border-shape shipping anywhere?<br> <fantasai> noamr: Not shipped, open issue.<br> <fantasai> noamr: So would need to consider this.<br> <fantasai> lea: Per TAG consistency is not the only principle.<br> <fantasai> lea: Like we could say there are different considerations here.<br> <fantasai> astearns: but then I'll be sad<br> <ChrisLilley> looks like A is in the lead<br> <fantasai> ntim: Consistency makes the mental model easier<br> <fantasai> iank_: I'd also be interested in a poll of web devls<br> <ChrisLilley> 14 to 3 with 3 undecided<br> <fantasai> lea: Should we ask about border and outline together or separately?<br> <fantasai> florian: This poll will be very sensitive to context.<br> <fantasai> dholbert: Should consider both, so we should poll together.<br> <TabAtkins> btw, i feel like a rainbow border will do better for fantasai's objection, with a white image and box background<br> <TabAtkins> make box and backgroudn the same color, so that doesn't influence at all<br> <fantasai> +1 to TabAtkins<br> <ntim> could we ask about border-shape as well?<br> <fantasai> kizu: We could have 4 images, each one in both directions, so two good images and two bad images, but each will have same colors<br> <noamr> Yea we need to also attach a picture of border-shape(circle() rect())<br> <fantasai> RESOLVED: Specify inside-out order for now, mark issue prominently in the spec, open an issue in GH, and work on a poll of authors.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13044#issuecomment-3813591962 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 19:59:58 UTC