- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 22 Apr 2026 16:45:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-gaps-1] Dropping decorations for suppressed gaps`, and agreed to the following: * `RESOLVED: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout` * `RESOLVED: gaps that fall on an external fragmentation boundary consume a decoration from the pattern` <details><summary>The full IRC log of that discussion</summary> <emeyer> +1<br> <JoshT> oSamDavis: issue was about assigning 13663, we resolved to add linear assignment<br> <JoshT> ... we've come back with some investigations<br> <JoshT> ... question of whether to ????, we want to drop in that case, but we don't want to drop by ?????<br> <JoshT> ... on the issue, we have a couple of examples why it would be confusing if done by default<br> <JoshT> ... although it could be common for authors to want to drop<br> <JoshT> ... we thought about other cases to drop<br> <JoshT> ... supressed gaps for fragmentation<br> <JoshT> ... we resolved to suppress the gaps when they coincide with fragment breaks<br> <JoshT> ... we want to drop decorations to match behaviour of printing when you want to preserve the pattern<br> <JoshT> ... for collapsed tracks in grid, we said assignment happens after tracks have collapsed<br> <JoshT> ... all in all, our proposal is number 1, we want to drop in flex but not by default. 2, we want to drop decorations that follow fragment breaks<br> <JoshT> ... and 3, we don't want to drop track collapse in grid<br> <JoshT> astearns: for 1, i understand that for multiline flex containers, we will not drop by default<br> <JoshT> ... but we want the option to drop between lines in a flex layout<br> <JoshT> ... seems reasonable<br> <JoshT> fantasai: probably the best way to know if we got the right call is to ship it and see who complains<br> <miriam> q+<br> <JoshT> astearns: that does increase compat risk, but edge case<br> <JoshT> miriam: i'm not sure if I understood your clarification. we're not suppressing at the wrap point?<br> <JoshT> fantasai: if you have a repeating one, then the pattern continues. you won't draw the decoration at the end because you skip it<br> <JoshT> oSamDavis: for role visibility items, we could have the drop on items that keep setting the same decorations<br> <JoshT> astearns: i also had miriam's confusion<br> <JoshT> ... we are not dropping the decoration. we are only changing how the decoration pattern is applied to exisiting gaps<br> <JoshT> fantasai: the alt proposal is assigning into that non-existing gap and therefore not drawing one of the items in the pack<br> <JoshT> astearns: let's not talk about dropping a decoration but applying the pattern to multiline flex containers<br> <fantasai> s/pack/list<br> <JoshT> PROPOSED: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout<br> <JoshT> RESOLVED: The gap decoration pattern is applied to the actual gaps that exist in a multiline flex layout<br> <JoshT> astearns: given that way of expressing the 1st option, what is the second resolution about frag?<br> <astearns> ack miriam<br> <JoshT> oSamDavis: suppressed gaps, we apply the decoration to suppressed gaps<br> <JoshT> astearns: suppressed gaps are just those gaps that would fall on a frag boundary?<br> <JoshT> oSamDavis: yes so the pattern is preseved<br> <JoshT> astearns: for a fragmented flex layout, we assign gap decorations to ?????<br> <JoshT> oSamDavis: yes but to ????????<br> <astearns> s/????????/grid as well<br> <JoshT> fantasai: this relates to previous resolution. I think for that one, there's arguments in both directions. for this one, an author is going to notice when the gap gets out of sync<br> <JoshT> ... the proposed resolution makes sense. otherwise people will get things they don't expect<br> <fantasai> s/is going/is not going/<br> <JoshT> astearns: here we're talking about multiline frag breaks<br> <JoshT> PROPOSED: gaps that fall on an external fragmentation boundary consume a decoration from the pattern<br> <fantasai> +1<br> <JoshT> RESOLVED: gaps that fall on an external fragmentation boundary consume a decoration from the pattern<br> <JoshT> astearns: for track collapsing in grid?<br> <JoshT> oSamDavis: apply gap decorations to actual gaps in grid<br> <JoshT> ... it's what we resolved on in previous issue. just clarifying it's no change<br> <JoshT> astearns: is it clear that the resolutions we just took do not contradict the previous resolution<br> <JoshT> oSamDavis: yes<br> <JoshT> astearns: then we should be OK<br> <JoshT> fantasai: so if the gap is collapsed away, we pretend it's not there for gap decorations?<br> <JoshT> oSamDavis: yes<br> <JohnJansen> I do think it's important to clarify that this new resolution does not impact the previous resolution.<br> <JoshT> astearns: if it's clear that these new resolutions don't contradict, it can be an editorial point in the spec and we can move on<br> <JoshT> JohnJansen: i liked that we clarified that it does not contradict<br> <JoshT> astearns: it's in the minutes now so we can move on<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13754#issuecomment-4298143982 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:45:50 UTC