Skip to content

[css-gaps] Gap decorations with collapsed gutters #11814

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Loirooriol opened this issue Mar 4, 2025 · 5 comments
Closed

[css-gaps] Gap decorations with collapsed gutters #11814

Loirooriol opened this issue Mar 4, 2025 · 5 comments

Comments

@Loirooriol
Copy link
Contributor

https://drafts.csswg.org/css-grid/#collapsed-gutter

When a collapsed track’s gutters collapse, they coincide exactly—​the two gutters overlap so that their start and end edges coincide.

Does this mean that the gap decorations will overlap? That doesn't sound great.

@kbabbitt
Copy link
Collaborator

kbabbitt commented Mar 5, 2025

Interesting. Naively, I'd have expected the two gutters adjacent to a collapsed track to consolidate down to a single gutter rather than overlapping each other.

I suppose one use case for the spec'ed behavior might be where you have varying gap decorations over the grid, and if a track changes state from collapsed to un-collapsed or vice-versa, you want gap decorations in subsequent tracks to "stay with" those tracks. But then that means either you have overlapped decorations, or you need to define which one "wins" like we do for collapsing table borders.

@Loirooriol
Copy link
Contributor Author

This is also somewhat related to #10813. My conclusion there was that a collapsed track gets assigned the size of minus one gutter (and that's why the gutters overlap). But that's not great for decorations, so if we do something else, we need to think how abspos "items" will be affected.

@kbabbitt
Copy link
Collaborator

I tracked the text specifying that gutters overlap back to ac37030 by @tabatkins, which was introduced after discussion in #172, in which @fantasai wrote:

We ended up collapsing gutters by specifying that they coincide, because the location of the gutters and the lines can be detected by abspos, so we can't just drop them. If at some point we add explicitly collapsing columns as a feature (e.g. via visibility: collapse), this behavior would be the correct one to have for that as well.

Meanwhile, Gaps leaves the definition of where gutters exist to other specifications. That's intentional, so that gap decorations can be defined the same way regardless of container type. So from the perspective of Gaps, if the gaps overlap, then the decorations would overlap as well.

With those points in mind, I was tempted to look for a solution in Grid, where we'd somehow still collapse grid line positions but consolidate down to a single gap. But that got me worried about introducing weird discontinuities in cases where gaps cross the threshold from being exactly-overlapping to almost-overlapping (animation perhaps?).

I guess my take depends on whether such discontinuities could be a thing. If they could, then overlapping decorations seems like not-great-but-least-surprising behavior. If that's not a situation we need to worry about, then my preference would be to solve this with some sort of change to Grid that makes sense both for gap decorations and for abspos per #10813.

@fantasai
Copy link
Collaborator

fantasai commented Apr 3, 2025

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [css-gaps] Gap decorations with collapsed gutters, and agreed to the following:

  • RESOLVED: Suppress all but one decoration if gaps are coincident due to track collapsing, and use the same rules as border collapsing
The full IRC log of that discussion <fantasai> s/Topic/Subtopic/
<emeyer> kbabbitt: Oriol pointed out the way collapse tracks work in grid, when a track get collapsed, the gutters to either side overlap
<emeyer> …That’s fine if they’re empty, but will cause decorations to overlap
<emeyer> …I want to leave the definition of where gaps are to other specifications
<emeyer> …There are reasons to have overlapping gutters
<TabAtkins> q+
<emeyer> …But there could be an animation of a gutter collapsing down could cause weird discontiunities
<emeyer> …I’m leaning to leaving the behavior as is, since it seems to cause the fewest surprises
<astearns> ack TabAtkins
<emeyer> …But wanted to open the floor
<emeyer> TabAtkins: I don’t recall the reasons to have only a single gutter; can you restate?
<emeyer> kbabbitt: The PR that landed the change was that gutters can be detected by abspos elements within the grid
<emeyer> TabAtkins: Ah. I think we should suppress the display of one of the gutters when they overlap
<emeyer> …We could do it by making all but one of the gutters transparent
<emeyer> …I don’t think people would like overlapping multiple decorations
<emeyer> …We could say that if gutters overlap, all but one are transparent in some way, and could say that if they’re animated together, the transparent ones could be faded out
<emeyer> kbabbitt: Your proposal is to define this in gaps to say if two gutters are exactly coincdental, draw only one decoration
<emeyer> TabAtkins: Yes
<astearns> ack fantasai
<emeyer> …When a track collapses, and gutters are coincident, only one paint
<emeyer> fantasai: Collapsing a gap is binary right now; you’re either collapsed or you’re not
<emeyer> …I don’t know how we would even define otherwise
<emeyer> …I agree with Tab that we should paint only one
<emeyer> …We should do something similar to border-collapse rules, where you use whichever is most prominent
<emeyer> astearns: I did not know we had those rules!
<florian> q+
<emeyer> fantasai: I’m pretty cranky about the border-collapse code
<emeyer> …The rules about which border wins prioritize which style looks weirder
<emeyer> …Here, we don’t have a hierarchy for resolving conflicts
<emeyer> …If we ever have a region concept, we probably want the outermost border to win
<emeyer> …The boundary is most prominent, usually
<emeyer> astearns: Could there be decorations on the outside of subgrids that we should consider?
<oriol> BTW, rules for border collapsing conflicts are in https://drafts.csswg.org/css-tables/#border-specificity
<emeyer> fantasai: Yeah, if you have gap decorations that are more outside, they should get priority
<emeyer> kbabbitt: The conflicts rules in the context of tables are in the tables spec?
<emeyer> fantasai: They’re in CSS 2.1
<astearns> ack florian
<fantasai> https://www.w3.org/TR/CSS2/tables.html#border-conflict-resolution
<emeyer> kbabbitt: We’d just point to those
<emeyer> florian: I agree that tables got it wrong, because an edge is a specific thing
<emeyer> …I think saying the edges of a subgrid should win; parts that are special shoudl win ver parts that are generic
<emeyer> s/ver/over/
<emeyer> astearns: Any other comments or questions?
<emeyer> (silence)
<emeyer> Proposed resolution is that we’ll suppress all but one decoration if gaps are coincident due to collapsing
<emeyer> kbabbitt: I’d say for any reason
<emeyer> fantasai: If we end up with negatively sized tracks and decorations overlap, both should be painted
<emeyer> kbabbitt: Fair
<emeyer> astearns: And amend the resolution to say we’ll use the same rules as border collapsing
<emeyer> Objections?
<emeyer> (silence)
<oriol> In fact in flexbox you can have overlapping gaps with items with negative margins, right? So better restrict to collapsed gaps.
<emeyer> RESOLVED: Suppress all but one decoration if gaps are coincident due to track collapsing, and use the same rules as border collapsing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Thursday Morning
Development

No branches or pull requests

4 participants