Skip to content
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

[css-grid-3][masonry] Enabling repeat(auto-fill, auto) #10915

Open
fantasai opened this issue Sep 18, 2024 · 3 comments
Open

[css-grid-3][masonry] Enabling repeat(auto-fill, auto) #10915

fantasai opened this issue Sep 18, 2024 · 3 comments

Comments

@fantasai
Copy link
Collaborator

fantasai commented Sep 18, 2024

Google's earlier Alternate Masonry Proposal—which didn't allow for mixed track sizing and constrained all content-sized tracks to be the same size—allowed repeat(auto-fill, auto) as a track listing, computing auto as the largest [item size]/[span size].

This definition doesn't work with mixed track sizes, because the amount that an item contributes to each track can differ based on what it's spanning. Filing this issue to ask if we can still add this value, and if so, what does it mean? Does it also work in grid layout?

Note: There's a separate, but related, issue about what the initial track listing should be, and whether it should be this.

@fantasai
Copy link
Collaborator Author

Copying over the key part of Tab's comment:

I've set down what I think is a reasonable definition (basically just restoring the old behavior from my draft) in https://drafts.csswg.org/css-grid-3/#masonry-intrinsic-repeat, along with an explanation of why the definition is the way it is.

@fantasai
Copy link
Collaborator Author

See also earlier discussion in #9321

@tabatkins
Copy link
Member

Yeah, my original draft's constraints meant that auto-sized repeats could be done completely correctly; there was no chance of spans covering different types of tracks. (You still had to ignore placement, of course, but it had less of an effect.)

Adapting that into this draft means that I can at best be heuristic. If you've only got span-1 items, it works correctly; if you do have all the tracks identical (which is what the initial value gives), it works correctly. It's only when you have a mixture of track sizes and spanning items that the heuristics have to kick in, and I think they still give a reasonable result.

@fantasai fantasai moved this to Thurs afternoon in CSSWG Agenda TPAC 2024 Sep 20, 2024
@astearns astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025
@astearns astearns moved this from FTF agenda items to Thursday afternoon in CSSWG January 2025 meeting Jan 28, 2025
@astearns astearns moved this from Thursday afternoon to Friday morning in CSSWG January 2025 meeting Jan 31, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Thurs afternoon
Status: Friday morning
Development

No branches or pull requests

3 participants