Skip to content
New issue

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

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

Already on GitHub? # to your account

[css-grid-3] masonry-auto-flow has suprising default #9988

Closed
bfgeek opened this issue Feb 21, 2024 · 5 comments
Closed

[css-grid-3] masonry-auto-flow has suprising default #9988

bfgeek opened this issue Feb 21, 2024 · 5 comments
Labels
Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-grid-3 Masonry Layout

Comments

@bfgeek
Copy link

bfgeek commented Feb 21, 2024

https://drafts.csswg.org/css-grid-3/#masonry-auto-flow

masonry-auto-flow has the pack default which will explicitly pull items out of order via definite-first (I believe). This is suprising! (Also definite-first isn't really defined).

At the very least this should be ordered by default, but likely without good justification the definite-first concept should be removed.

Additionally use-cases for masonry-auto-flow: next would be good, I personally haven't seen web developers ask for this behaviour - likely next could be dropped as well.

@bfgeek bfgeek added the css-grid-3 Masonry Layout label Feb 21, 2024
@Loirooriol
Copy link
Contributor

Additionally use-cases for masonry-auto-flow: next would be good

Having a stable layout that isn't completely rearranged when some item changes size. Seems useful to me.

@bfgeek
Copy link
Author

bfgeek commented Feb 29, 2024

Having a stable layout that isn't completely rearranged when some item changes size.

Its bad for accessibility however - as it pulls things into a weird ordering. If things are mostly the same size grid should suffice, or if its about small reordering errors, then the reorder-threshold property should suffice.

@Loirooriol
Copy link
Contributor

It doesn't seem a weird ordering to me. It obviously has the gotcha that it can fill the columns at very different paces, but this doesn't make it weird, and it isn't a big deal if e.g. you have gazillions of contents available to lazy load whenever the user reaches the end of the shortest column.

In fact, even though pack has some clear advantages, I would say that it produces a weirder ordering. And precisely reorder-threshold tries to mitigate that. But reorder-threshold doesn't bring stability: there is still a threshold that will produce one result when the size is of item is below it, and a completely different one when it's above it.

@tabatkins
Copy link
Member

Re: next vs pack - yeah, Oriol's argument makes sense. If you have some <details> in your masonry, and you don't want the layout to jiggle when you open one, next will keep things nice and stable. Your layout will be worse, but it'll be stable, and I think that's a tradeoff that's reasonable for authors to make sometimes.

(On the other hand, as noted elsewhere, using masonry-threshold: calc(infinity) is identical to pack, so we might be able to get away with just using that, perhaps with a note to authors about it. But I'm not opposed to keeping the keyword if it's a more straightforward/learnable way to express this, and then having a note that it makes masonry-threshold powerless.)

@fantasai
Copy link
Collaborator

fantasai commented Sep 6, 2024

We updated the default and dropped masonry-auto-flow per https://www.w3.org/mid/CADhPm3s2EftVNQpRWmw3gyCEFB_JYdW5F=Gku2ccd4ADBO60EA@mail.gmail.com

@fantasai fantasai closed this as completed Sep 6, 2024
@fantasai fantasai added Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. labels Sep 6, 2024
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Closed Accepted by CSSWG Resolution Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-grid-3 Masonry Layout
Projects
None yet
Development

No branches or pull requests

4 participants