Re: [csswg-drafts] [css-gaps-1]: Change the initial value for insets property to be 0 (#13137)

The CSS Working Group just discussed `[css-gaps-1]: Change the initial value for insets property to be 0`, and agreed to the following:

* `RESOLVED: Add an 'overlap-join' keyword to rule-inset.`

<details><summary>The full IRC log of that discussion</summary>
&lt;hoch> oSamDavis: The issue was closed and I reopened it. Last F2F we agreed that we would change the default value to 0, with the caveat we would introduce a keyword 'join' to give the 50% behavior.<br>
&lt;hoch> oSamDavis: In discussion, we realized 'join' could cause some undesired behaviors. e.g. making a notch at a cross-axis intersection corner. There are so many ways you can think about how a 'join' should join.<br>
&lt;kbabbitt> q+<br>
&lt;hoch> oSamDavis: Because of all these ways, we think the keyword isn't the best idea. Authors can still use percents and calc magic to accomplish what they want. We are thinking of deffering 'join' keyword.<br>
&lt;astearns> ack kbabbitt<br>
&lt;hoch> kbabbitt: &lt;shares screen> My issue with a 'join' keyword being -50% is it results in this behavior &lt;shows the notch example>.<br>
&lt;hoch> kbabbitt: There's a few different ways authors can achieve join. This dots example also show undesired behavior.<br>
&lt;astearns> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to comment on different types of joins<br>
&lt;hoch> kbabbitt: Authors can achieve any of these with calc and the width of the cross-gap decoration. There's not something they are blocked on. I'd like to wait, see what authors do with the feature, and then introduce a keyword based on thatj.<br>
&lt;hoch> fantasai: If we look closely I don't think authors would be happy with having to do calc. You are right there are different ways authors might want - overlap at the join OR prioritize one over the other<br>
&lt;astearns> q+<br>
&lt;hoch> fantasai: for basic solid lines, overlap works pretty well.<br>
&lt;hoch> fantasai: It starts to look weird for a t-intersection depending on the colors you are choosing.<br>
&lt;hoch> fantasai: So I can see authors wanting to go both ways. We could start with the simplest thing - overlap the intersection.<br>
&lt;hoch> fantasai: But it would be a keyword that is not the same as the inset value. It would have to be based on the context of the join.<br>
&lt;hoch> fantasai: You've convinced me in the issue that we do need a keyword.<br>
&lt;hoch> astearns: I also like these diagrams, but am not sure I like any of the join options.<br>
&lt;kbabbitt> q+<br>
&lt;hoch> astearns: You have very nice borders - why not have the default match borders?<br>
&lt;hoch> fantasai: miters are going to look weird at t-intersections<br>
&lt;astearns> ack astearns<br>
&lt;hoch> kbabbitt: The spec text actually leaves it up to the UA how they want to do border joins.<br>
&lt;hoch> kbabbitt: So if we're following that precedent, we could leave it up to the UA.<br>
&lt;astearns> ack kbabbitt<br>
&lt;hoch> kbabbitt: I achieved all these examples with calc. Using variables to set the rule-width, so I could use calc of -50% plus that variable.<br>
&lt;hoch> kbabbitt: We could assign a keyword to one of these, but is it going to be the future?<br>
&lt;hoch> fantasai: You mentioned in the issue this calc would only work if they all have the same thickness, which might not always be true. It's a complicated math expression, which is not a good developer experience. CSS is supposed to be reasonable for non-mathy types.<br>
&lt;hoch> fantasai: This is a basic use case. There is a variety of ways we could do joins. The simplest is overlap. I'd be find with introducing a keyword to do overlap and we can add new keywords in the future for other types.<br>
&lt;hoch> kbabbitt: If picking a keyword I agree to pick overlap. And hear the position that authors should have something simple.<br>
&lt;hoch> astearns: So is the keyword 'overlap'?<br>
&lt;hoch> kbabbitt: This is on the inset property<br>
&lt;hoch> fantasai: Seems reasonable<br>
&lt;kbabbitt> rule-inset: overlap;<br>
&lt;hoch> astearns: Are we arriving at a proposal to make an 'overlap' keyword and make it the default?<br>
&lt;hoch> kbabbitt: Not the default.<br>
&lt;hoch> &lt;discussion on the 0 behavior><br>
&lt;hoch> astearns: And you want that as the default?<br>
&lt;hoch> fantasai: There's a property that makes the lines go through though<br>
&lt;hoch> alisonmaher: yes, rule-break<br>
&lt;hoch> kbabbitt: Yes, this comes back around to the default behavior for grid.<br>
&lt;kbabbitt> rule-inset: overlap;<br>
&lt;fantasai> rule-inset: overlap-join;<br>
&lt;kbabbitt> rule-inset: overlap-join;<br>
&lt;hoch> kbabbitt: Is this something someone could intuit by looking at?<br>
&lt;hoch> astearns: Agreed that is better, though we may need more bikeshedding. Any other opinions?<br>
&lt;fantasai> rule-inset: butt-join<br>
&lt;hoch> PROPOSED: Add an 'overlap-join' keyword to rule-inset.<br>
&lt;hoch> RESOLVED: Add an 'overlap-join' keyword to rule-inset.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13137#issuecomment-4083588421 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 March 2026 15:46:48 UTC