-
Notifications
You must be signed in to change notification settings - Fork 56
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 Masonry Layout #1003
Comments
This comment is just from me, without having consulted the rest of the TAG yet. I see that we have a compelling description of the use case (Yay for solving this problem!) and a pair of documents advocating for the alternative syntaxes. It's not clear whether both sides agree with the claims in each document and just weigh them differently, or also disagree about some of the factual claims. I'm not confident that the TAG will know enough about the design space to figure out what facts are true, although we may be able to help weigh tradeoffs. Would it be possible for the two sides to get together and produce a consensus document that describes the disagreement and points out the different values that the TAG should be weighing? |
As the author of the two Chrome posts on the subject, I'd be happy to help create a consensus document. I also have collected developer feedback on the issue. |
こんにちは TAG-さん!
I'm requesting an early TAG design review of masonry layout in CSS.
Masonry layout creates grid-based tracks in a single axis, and stacks items tightly in the other, creating rows or columns but not both. It is currently drafted into https://www.w3.org/TR/css-grid-3/ with two possible syntax options: a grid-based syntax that uses a keyword to relax alignment in the stacking axis, and an independent syntax that uses a blend of flex and grid concepts with a new set of properties. The arguments in the debate center over a) which is easier to learn for authors and b) how might this decision impact possible future developments in one or both models (or CSS in general).
I'm opening this issue to ask the TAG to schedule a review of the spec in general and of the syntax question specifically. We are currently collecting feedback, and are hoping to have a CSSWG discussion on this question in late October / early November. We will update this issue as input comes in.
Further details:
You should also know that...
The text was updated successfully, but these errors were encountered: