- From: Kevin Babbitt via GitHub <noreply@w3.org>
- Date: Fri, 10 Apr 2026 23:01:59 +0000
- To: public-css-archive@w3.org
I find @alisonmaher's point about debuggability to be compelling. Putting myself in the shoes of an author who has an existing flexbox and adds `column-rule: 1px solid red, 1px solid blue` to it, I'd be very confused as to why I mostly but don't always get alternation between red and blue decorations. So on that basis I thinnk not dropping should be the default. The toolbar case is important, but as alluded to in my original post, it really calls for some sort of primitive to attach decoration behavior to elements rather than to a given container's gaps. We haven't really explored that space yet, and in fact we've already deferred a similar idea out of level 1: decoration visibility on an element-by-element basis. So while I'm not 100% opposed to adding in an opt-in for dropping, I think the use case would be better served with new capabilities in a future level. ----- Aside: At the F2F, there was some side discussion about deferring varying decorations as a whole out of level 1, for lack of use cases that couldn't be solved with tables. @oSamDavis has been doing some research on this. He was able to construct the [calendar example](https://github.com/w3c/csswg-drafts/blob/main/css-gaps-1/explainer.md#scenario-6-calendar-layout-with-alternating-line-styles), which I previously thought required advanced features, using only what's in level 1. He also found [this example](https://stripe.com/pricing) of a responsive grid layout with varying decorations (though the lines are subtle). -- GitHub Notification of comment by kbabbitt Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13754#issuecomment-4227242792 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 10 April 2026 23:01:59 UTC