Contact emails etha...@microsoft.com<mailto:etha...@microsoft.com>, alma...@microsoft.com<mailto:alma...@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 Blink>Layout<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout> 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 grid<https://chromestatus.com/features#tags:grid>, layout<https://chromestatus.com/features#tags:layout>, masonry<https://chromestatus.com/features#tags:masonry> 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: * https://github.com/w3c/csswg-drafts/issues/9041 * https://github.com/w3c/csswg-drafts/issues/10233 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<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>? 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<https://chromestatus.com/>. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH0PR00MB1349C8CC6167E8A11FB17489BCF82%40PH0PR00MB1349.namprd00.prod.outlook.com.
