- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 31 Mar 2026 18:56:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-gaps-1] `overlap-join` with `between` rule visibility``, and agreed to the following: * `RESOLVED: Trim the unjoined segments. TBD how exactly that should work.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> kbabbitt: at gap breakout we resolved to add overlap-join keyword<br> <TabAtkins> kbabbitt: when you have decos in crossing directions they overlap<br> <TabAtkins> kbabbitt: while implementing that, there's a weird edge cases about "between"<br> <TabAtkins> kbabbitt: because overlap-join takes you to the intersection, you get a little bit sticking out<br> <TabAtkins> kbabbitt: my reaction when I saw it is this is wrong, and we should leave the deco flush with the remaining items<br> <TabAtkins> kbabbitt: do people think authors would want this sticking out, or should we trim?<br> <TabAtkins> kbabbitt: when there's no intersecting deco?<br> <miriam> q+<br> <TabAtkins> fantasai: I think your heuristic makes sense to me<br> <Rossen> ack miriam<br> <TabAtkins> miriam: would trimming be the same as what you do at the edge of the grid?<br> <TabAtkins> kbabbitt: yes, effectively<br> <florian> q?<br> <TabAtkins> miriam: if so, yeah, doesn't feel as magical<br> <fantasai> But it gets weird here: https://github.com/w3c/csswg-drafts/issues/13697#issuecomment-4101453468<br> <TabAtkins> kbabbitt: specifically, it means that overlap-join extends the decoration when there is a decoaration to join with, and doesn't when there's not<br> <hoch> q+<br> <florian> q+<br> <TabAtkins> kbabbitt: [shows another example of the gaps extending or not]<br> <TabAtkins> fantasai: given this illustration i think we don't want to trim it flush<br> <TabAtkins> TabAtkins: i disagree, i htink trimming would look good<br> <TabAtkins> kbabbitt: [shows an example of what it would actually look like]<br> <astearns> +1 to trimming (treating gap-less sections as grid edges makes sense to me)<br> <TabAtkins> miriam: going back to the previous image, there was a q about top and bottom... you said it would trim the top and not the bottom?<br> <TabAtkins> kbabbitt: it would trim the tops of all lines, and the bottom of this lone line, but not the bottom of these others that area cctually joining<br> <Rossen> ack hoch<br> <TabAtkins> hoch: i'm wondering if this beahvior... would it be better to address this by changing the definition of what the outside is?<br> <TabAtkins> hoch: if we make this magic only apply to the join keyword, if authors want it for a not-quite-overlapping join they can't get it<br> <TabAtkins> hoch: so what if we defined this as making these edges count as "outside" edges?<br> <TabAtkins> kbabbitt: we can indeed define edges from interior insets<br> <fantasai> +1 hoch<br> <TabAtkins> hoch: right so what if instead of changing this keyword, we change the definition of which corners are edge vs interior<br> <TabAtkins> hoch: in these cases they are "edge" insets rather that interior ones<br> <miriam> +1 that's what I was trying to get at as well<br> <TabAtkins> kbabbitt: let me restate<br> <TabAtkins> kbabbitt: suggestion is to have differentiated inset properties based on whether there's an intersection or not?<br> <TabAtkins> hoch: yes<br> <Rossen> ack florian<br> <TabAtkins> florian: havne't thought about this latest variant... but until that point i think it made sense<br> <TabAtkins> florian: the various examples differed in how wrong they felt, some could go either some were def wrong, but they were all at least somewhat better with the "fixed" behavior<br> <Rossen> ack fantasai<br> <Zakim> fantasai, you wanted to say this also allows more control<br> <TabAtkins> fantasai: i think hoch's propopsal makes sense for antoher reason, you might not want those perfectly flush, might want them inset or outset a bit<br> <TabAtkins> fantasai: by defining them as an exterior join you get that control<br> <TabAtkins> arronei: i think it could lend to future designs we were talking about during break, corner joins being defined differently (rounded, chamfered, etc)<br> <fantasai> PROPOSED: Define ends of segments that do not join to an intersection to be "exterior" insets (which can be controlled as such).<br> <TabAtkins> arronei: so as we separate this out a bit it might lead to taht future work<br> <fantasai> TabAtkins: overlap-join keyword, which property?<br> <fantasai> kbabbitt: the inset properties<br> <fantasai> TabAtkins: those have edge/interior/start/end?<br> <fantasai> kbabbitt: yeah<br> <fantasai> TabAtkins: So if we have this behavior, then this wouldn't be controlled by the inset property<br> <fantasai> fantasai: It could be<br> <fantasai> kbabbitt: If we want a different offset, then it may be a separate property. Or maybe a separate ?<br> <TabAtkins> fantasai: if you already ahve edge vs interior, you'd set interior to overlap-join and the exterior to 3px<br> <fantasai> TabAtkins: Ah, thought we would add a new property to enable that<br> <fantasai> TabAtkins: but if they're always exterior joins ...<br> <fantasai> TabAtkins: and then overlap-join would be specifiable for any interior join then that's ok<br> <TabAtkins> fantasai: so if you set interior and exterior to overlap-join, you'll get an outset at the edges<br> <TabAtkins> alisonmaher: would you really want the exterior edge to extend out?<br> <TabAtkins> fantasai: yes. i imagine you'd want that?<br> <TabAtkins> fantasai: i think if you want an outset of 3px at these "no item" "interior" corners, you probably want it on the actual exterior corners too<br> <TabAtkins> fantasai: i can imagine for the shorthand, if you just said "overlap-join" we'd default that to the interior and give exterior a 0 default<br> <fantasai> TabAtkins: and then overlap-join would be specifiable for any interior join then that's ok<br> <fantasai> (oops sorry mispasted)<br> <TabAtkins> (this is definitely running into my "there are about 20 types of joins" problem with defining gap-image)<br> <TabAtkins> kbabbitt: i see where the train of thought is going... i think i need to whiteboard this out and think about it<br> <fantasai> Rossen: So proposal: define ends of segments that do not join to an intersection to be "exterior" insets (which can be controlled as such).<br> <fantasai> TabAtkins: Maybe just "trim those by default"?<br> <oSamDavis> I think the issue is that there's no separate edge-interior property, so controlling edge controls all edges<br> <TabAtkins> yeah that's my concern too, oSamDavis<br> <TabAtkins> there is https://drafts.csswg.org/css-gaps/#insets-edge-interior for inside vs outside<br> <alisonmaher> +1 we'd need separate controls for that likely<br> <TabAtkins> fantasai: if all your other edges aren't flush it's unlikelly you want these to be flush<br> <TabAtkins> kbabbitt: I think i'm good with TAb's higher-level resolution<br> <fantasai> PROPOSED: Trim the unjoined segments. TBD how exactly that should work.<br> <fantasai> RESOLVED: Trim the unjoined segments. TBD how exactly that should work.<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-4164736783 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 31 March 2026 18:56:12 UTC