Intent to Prototype: CSS Masonry
Ethan Jimenez
Contact emails
eth...@microsoft.com, alm...@microsoft.com
Explainer
https://developer.chrome.com/blog/masonry
A formal explainer is in the works, waiting for further discussion over CSSWG issues.
Specification
https://tabatkins.github.io/specs/css-masonry
Summary
CSS Masonry is a layout module where items of varying heights are arranged in columns, filling gaps to create a seamless grid, similar to a brick wall, perfect for accommodating elements with varying aspect ratios.
Unlike CSS Grid, Masonry is better suited for one-dimensional flow layouts, like image galleries, where the focus is on filling the space efficiently rather than aligning items along both axes.
Masonry provides greater design freedom, enabling the creation of dynamic, responsive layouts that adapt to content variations without the need for manual adjustments or a non-standard JavaScript implementation.
Blink component
Motivation
Without native support for Masonry, developers need to rely on non-standard implementations that might not be interoperable across browsers and require extra effort to maintain.
In Blink, we want to specifically prototype the alternative approach of making CSS Masonry its own display type, looking to showcase that this approach is on par with developer's expectations without introducing unnecessary complexity to an already overloaded CSS Grid spec.
Initial public proposal
https://github.com/w3c/csswg-drafts/issues/9041
Search tags
TAG review
We're planning on starting the TAG specification review once several issues over the CSS Masonry standard are discussed and clarified.
TAG review status
Pending
Risks
Interoperability and Compatibility
Masonry is highly anticipated by web developers and support for other browser vendors is already in experimental status. However, the CSSWG has not reached consensus on whether the feature should live under the established CSS Grid spec or on its own display type.
If the working group decides that Masonry shouldn't be its own display type, then several of its properties would require to be merged with Grid properties and our prototype will need to undergo heavy refactoring.
Gecko: Under consideration (https://github.com/w3c/csswg-drafts/issues/9041#issuecomment-2075386656)
Firefox has Masonry support under a flag for the current spec under CSS Grid, but they're potentially open to implement it as its own display type given performance concerns raised with the current spec.
WebKit: In development
Safari already supports https://drafts.csswg.org/css-grid-3/ at some capacity, but their implementation follows the principle of extending the Grid Module instead of implementing it as
a separate display type.
Web developers: Strongly positive
Developers are excited about native CSS Masonry support.
However, opinions are divided between whether the module should be an extension of the Grid Module or a display type on its own. Discussion around this issue can be found in the following CSSWG issues:
Other signals:
WebView application risks
Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?
None
Debuggability
Similar to other CSS display types, Masonry will expose computed values for its new properties and a layout overlay via DevTools.
Is this feature fully tested by web-platform-tests?
Yes
https://wpt.fyi/results/css/css-grid/masonry
Current WPT suite is based off Masonry being under CSS Grid. However, these tests can be easily adapted to the properties introduced by our approach, with new tests expanding the coverage for its specific behavior.
Flag name on chrome://flags
None
Finch feature name
None
Non-finch justification
None
Requires code in //chrome?
False
Tracking bug
https://issues.chromium.org/issues/343257585
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5149560434589696?gate=5139890382831616
This intent message was generated by Chrome Platform Status.