Re: [csswg-drafts] [css-gaps-1] `overlap-join` with `between` rule visibility (#13697)

The CSS Working Group just discussed ``[css-gaps-1] `overlap-join` with `between` rule visibility``, and agreed to the following:

* `RESOLVED: go with new approach about whether there is a junction to handle or not`
* `RESOLVED: option A for naming, use 'junction' and 'cap'`

<details><summary>The full IRC log of that discussion</summary>
&lt;JoshT> javierct: [shares screen]<br>
&lt;JoshT> ... we have resolved on overlap-join to join decorations<br>
&lt;JoshT> ... then in f2f, we talked about what happens with unjoined ones. do we want to extend them across empty cells?<br>
&lt;JoshT> ... how exactly we're not sure, so we want to resolve on them today<br>
&lt;JoshT> ... we want to only join segments that we want to join<br>
&lt;JoshT> ... suggestion was: currently we have edge and interior points. instead, we could do 'does this point have a crossing decoration - something to join with - or not?'<br>
&lt;JoshT> ... we think this is the way forward<br>
&lt;JoshT> ... so 'does this end point meet an intersection or not?'<br>
&lt;JoshT> ... edge endpoints still don't have anything to join, so the author could still set a different behaviour<br>
&lt;JoshT> ... we might want to control them separately, still<br>
&lt;JoshT> ... question is 'edge' and 'interior' names don't make sense any more. Kevin asked on social media. 'cap' and 'junction' or 'open' and 'close'<br>
&lt;JoshT> s/close/closed/<br>
&lt;JoshT> ... our current behaviour is still preserved, but we can deal with the cases discussed in the f2f<br>
&lt;JoshT> astearns: suggestion is to choose between these two names?<br>
&lt;JoshT> javierct: we resolved on trimming the ones with no intersection to join with<br>
&lt;JoshT> ... proposal for that is this behaviour to move from edge/interior to some other distinction<br>
&lt;JoshT> ... we want to know if that's the correct way to solve this problem. and then work out the names<br>
&lt;JoshT> astearns: so for first part, do we continue with previous edge/interior distinction, or go with 'is there a junction or not'? options?<br>
&lt;JoshT> ... it makes sense to me. I'm concerned if people will say 'I want to treat the non existent junctions at the edge separately to interior ones'<br>
&lt;JoshT> javierct: that's something we considered. we don't have use cases to treat them differently<br>
&lt;JoshT> astearns: i would be happy to change it to the proposal<br>
&lt;JoshT> ... no other opinions. shall we resolve?<br>
&lt;JoshT> RESOLVED: go with new approach about whether there is a junction to handle or not<br>
&lt;JoshT> astearns: any opinions on name options? or additional options?<br>
&lt;bramus> junction seems fine<br>
&lt;JoshT> ... i prefer junction rather than open or closed is that it seems more direct<br>
&lt;hoch> +1 for junction<br>
&lt;JoshT> q+<br>
&lt;emeyer> +1 to junction (if we’re not going to use intersection)<br>
&lt;bramus> scribe+<br>
&lt;SebastianZ> For what it's worth, I agree with astearns.<br>
&lt;bkardell> junction seems pretty good<br>
&lt;astearns> ack JoshT<br>
&lt;bramus> JoshT: fan of junction, not sure what cap means<br>
&lt;davidjmarland> same<br>
&lt;bramus> javierct: look at diagrams here. cap is somewhat abstract I guess … would not know what it means in terms of english … like top or cap<br>
&lt;emeyer> +1<br>
&lt;astearns> ack ChrisL<br>
&lt;Zakim> ChrisL, you wanted to check this is for selectors-5, right?<br>
&lt;emeyer> q+<br>
&lt;bramus> … it is a bit abstract. the cap/junction was the most voted one in the bsky thread by kbabbitt<br>
&lt;bramus> … people were leaning towards it<br>
&lt;hoch> q+<br>
&lt;bramus> … one could make similar args about open/closed<br>
&lt;bramus> … could look at it as  ?? but agree with astearns that junction makes more sense<br>
&lt;bramus> JoshT: definitely agree with junction<br>
&lt;bramus> … in British English we might call cap a “dead end” more or “cul de sac”<br>
&lt;davidjmarland> short?<br>
&lt;PaulG> terminator?<br>
&lt;bkardell> oooh terminator<br>
&lt;emeyer> q-<br>
&lt;astearns> ack hoch<br>
&lt;rachelandrew> I thought terminator as well<br>
&lt;bramus> hoch: part of the origin of cap was from the CSS Propertye for svgs: stroke-line-cap<br>
&lt;emeyer> I was going to make the same point about SVG terminology.<br>
&lt;bramus> … so there is precedent fo rindicating this dangling line<br>
&lt;hoch> q-<br>
&lt;bramus> JoshT: makes sense<br>
&lt;bramus> +1<br>
&lt;JohnJansen> I thought "end cap" which I have on the end of my garden hose to prevent leaking...<br>
&lt;JoshT> astearns: shall we resolve on option A for now and leave it open for later bikeshedding?<br>
&lt;JoshT> PROPOSED: option A for naming, use 'junction' and 'cap'<br>
&lt;RRSAgent> I have made the request to generate https://www.w3.org/2026/04/22-css-minutes.html fantasai<br>
&lt;bkardell> I like terminator<br>
&lt;JoshT> RESOLVED: option A for naming, use 'junction' and 'cap'<br>
&lt;JoshT> astearns: in the write up, I think it should be called in option A put 'start' and 'end' values at the end of all of the longhands<br>
&lt;bramus> +1<br>
&lt;SebastianZ> +1<br>
&lt;davidjmarland> +1<br>
&lt;jBreiland> +1<br>
</details>


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


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

Received on Wednesday, 22 April 2026 16:30:05 UTC