- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 14:59:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-1][masonry] Replaced content items should stretch by default.`, and agreed to the following: * `RESOLVED: keep it consistent with grid` <details><summary>The full IRC log of that discussion</summary> <andreubotella> fantasai: we should do whatever grid does, in terms of the default alignment<br> <andreubotella> alisonmaher: for masonry, you'll often be coming across images, and more often than not you want it to stretch<br> <andreubotella> .. there's questions about flexbox<br> <andreubotella> TabAtkins: I think it's a good behavior to stretch by defualt, but I also value consistency<br> <andreubotella> fantasai: if we designed grid today, we'd make it stretch<br> <andreubotella> .. but we designed it when images were not as regularly stretchy<br> <andreubotella> TabAtkins: we did not have aspect-ratio<br> <andreubotella> fantasai: since grid does not stretch by default, we should follow grid<br> <andreubotella> astearns: counterargument, I'm not sure I've ever seen a masonry layout with ragged placement<br> <andreubotella> .. it is changing the default in order to have images stretch, which all authors will have to do<br> <andreubotella> fantasai: can we change grid? :)<br> <andreubotella> astearns: likely we can't<br> <andreubotella> TabAtkins: if you volunteer to do the compat analysis, yes<br> <andreubotella> leaverou: if we don't try, the answer's no<br> <andreubotella> astearns: I think stretching by default in masonry, the fact people will almost always want it, is sufficient for divergence<br> <andreubotella> fantasai: in most cases, people will have a wrapper over the image, and this won't apply<br> <andreubotella> TabAtkins: most will have a link wrapping it<br> <andreubotella> fantasai: so the number of cases where this matters is pretty low<br> <andreubotella> .. and then you'll need to set width; 100%<br> <andreubotella> .. the stretch will happen on the wrapper<br> <andreubotella> .. we should be consistent with grid here<br> <andreubotella> .. won't buy us a whole lot<br> <andreubotella> astearns: I'll agree with that<br> <andreubotella> .. if it's not the case that authors need to change the behavior for most masonry layouts, I'm okay<br> <andreubotella> .. this is something we could change in the future if our assumption of wrapper elements is unfounded<br> <andreubotella> florian: or if compat analysis show we can change this for grid<br> <andreubotella> PROPOSED RESOLUTION: keep it consistent wiht grid<br> <andreubotella> astearns: if we figure out that it's something authors do need in masonry, or that it's something we can change for both, we can do it in the future<br> <andreubotella> fantasai: changing it for both is consistent with our resolution<br> <andreubotella> astearns: any objection<br> <andreubotella> RESOLVED: keep it consistent with grid<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9327#issuecomment-3201115625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 14:59:44 UTC