3 ms·

So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when

So, the background story is that CSSWG DevRels from browser vendors are debating how to formally include the Masonry layout into CSS, at least since 2020, when Firefox first proposed it. The news here is that people at WebKit decided to push the debate to the public, inviting designers and developers to take some action (“post to social media, write blog posts”), in order to get past this. While it may look just like a formality, I think this will make an important precedent. The real underling debate here is either to treat every layout option as a part of the CSS Grid, or keeping adding new CSS Display proprieties as necessary. The first option will make even more complex the (already convulsed, IMHO) CSS Grid specs, the latter will bloat the CSS specs with a load of new proprieties (and related sub-proprieties). Either way, it's not as easy as it looks.

pier25 2y ago
I don't know about the implementation but it makes zero sense that masonry should be part of grid. It's not a grid!
eternityforest 2y ago
I've yet to ever find a use case for grid.... I'd prefer this be a flex box feature so I can continue ignoring grid. But it seems like they have good reasons for including it, so I suppose I'll have to actually practice with grid more!
niutech 2y ago
Masonry is easy and has already been solved using CSS Multiple Columns: .masonry { column-count: 6; column-gap: 10px; }
mvonballmo 2y ago
A "row-less" grid fits very well in the current CSS Grid specification, in that it can reuse the very powerful column-definition property as well as sub-grids. Their examples very convincingly show how orthogonal these features are. Mostly, you just write grid-row-template: masonry and everything else just works with it. This is nice. It doesn't become harder to use the grid layout than it already is IMHO. The drawback is mostly for browser-engine authors, for whom the bar for "fully supports CSS Grid" will be set even higher. They also mention that it might avoid "performance traps" where an implementation that needs to support all features of grid might be slower at some parts of grid layout than it would be if the specification were simpler. If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.
- nightpool 2y ago
  > If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame. Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?
  - afiori 2y ago
    > And yes, while making CSS Grid more complex will make it harder to extend in the future, we believe there’s an advantage to having these two types of grid layouts intertwined. This way the CSS Working Group will always define all new additions for both modular and columnar grids. There won’t be something added to display: grid that will be left out of display: masonry, or vice versa. For example, many developers want CSS Grid Level 4 to provide a mechanism for styling grid areas and grid lines — perhaps a way to add a background color to a track, or create a rule line in a gap. It’d be great to ensure that will work for both modular and columnar grids from Day 1. > By using subgrid, we can put the year and catalog number on the right of each card — and line up this data for one painting with the same data for the other paintings. The downside is that all the parts of grid that might be useful in masonry would have to be duplicated in slightly different ways. This together with the fact the the only two current implementations use display: grid If it is possible to make them perfectly compatible then the main negative side
  - krsdcbl 2y ago
    my thoughts exactly - i think this points to a possible naming issue, since "masonry" is a relatively vague alias that does not really describe the underlying layouting logic, it just became ubiquitous enough for people building webstuff to understand because of that one jQuery plugin back in the days. A better approach might be to lean on the "grid" naming, but still silo it off via an own display directive (a bit like "block" and "inline-block" have shared properties, but also mutually exclusive behaviours) So maybe an own `display: flex-grid;` could be an interesting solution? This separate layout mode would avoid "result-specific" nomenclature like "masonry", and could lean on both flexbox & grid to achieve that look: - using `grid-auto-flow` to set a "masonry axis" & distribution logic - using _either_ `grid-template-columns` or `grid-template-rows` to specify the "lanes" - and to make my frankensteinian display-mashup even worse (or genius! for you to decide), the grid items could in turn abuse `flex-grow, flex-shrink, flex-basis` to control their height/width within the main "masonry" axis
eyelidlessness 2y ago
> Either way, it's not as easy as it looks. And exploring the tradeoffs might lead those exploring to reconsider their preferences going in. Not directly related to the topic, but I recently did some prototyping on a second iteration of an interface with a similar tension—proliferation of similar but distinct types in a data model, or expanding the set of nuances within each existing type to support refinement within it. Going into that prototyping session, I had a very strong bias in favor of the latter. But after exploring the options, I found it vastly simpler to consume the “bloated” interface, and to reason about the resulting application code consuming it. I don’t have strong feelings on the topic as it applies to CSS masonry, but I suspect there could be similar surprises in how people think about this tension intuitively versus in practice. And while I think CSS in particular will have a hard time justifying “bloat” (proliferation of use case specific semantics), I think it’s possible that users do tend to find more difficulty using CSS’s denser APIs (like grid).
qingcharles 2y ago
It's great they're doing this. I've been nudging everyone involved with this since last year. The Chrome guys are the furthest behind (no support). FF has flag support. I've been testing it since last year on FF and Safari and have no complaints about their implementations. I know some people are sniffling about the placement and naming of the properties. You have to be pragmatic about it, though, and realize there probably isn't a perfect solution and just implement it. I refuse to use JavaScript for the fallback, so the fallback is a lot of ugly CSS that doesn't order things in the right way, but it doesn't make a big deal of trouble for the project I'm working on. Most people will fallback to JavaScript right now, though, and when JavaScript is your solution to layout then you're already on a loser.
doctorpangloss 2y ago
Is there a JavaScript polyfill today that can read the CSS properties in any of the proposed / implemented specifications that Just Works in Chrome?
aidog 2y ago
look at the examples they made why it should be in CSS grid. I totally agree it should be in that. It's a form of grid. It should be part of CSS grid. This is one of the layouts that were just impossible in CSS and we really need it soon. I also needed the feature they talk about with the background colors for css grid tracks in 2012. I solved that with DIVs, but it was hard to make it responsive.
reactordev 2y ago
CSS Grid is a mistake. Baking in a design philosophy when we had really creative pages without it. I like grids for pages with content and documentation and such. I don’t like grids for pages of media or other creative content. Cards, flex box, grids, these are all design framework choices and shouldn’t be in CSS spec. We were totally fine with position relative and media-query centric widths and heights. I get that it’s easier to standardize if grids are part of the standard but I miss the days of pages having some creativity in their design. Every site looks the same nowadays. And before I get downvoted. I have a degree in graphic design. I love CSS and I love the web. Bring back the fun.
- rhdunn 2y ago
  CSS grid makes it possible to implement wrapped content that is uniformally aligned with the last row keeping the same number of columns as the others, and have that scale correctly to different page widths. This is useful in things like book layouts. You can get close with flex, but the last row doesn't fully work.
  - reactordev 2y ago
    Does it require a ::last-child hack to get working? I’m a fan of grids when it comes to heavy writing content like I mentioned but I still don’t think it should all be packed in the spec.
    - rhdunn 2y ago
      No, just: main.books { display: grid; grid-template-columns: repeat(auto-fill, 180px); grid-gap: 1rem; justify-content: space-between; } That will make the child items 180px wide, repeat as many children in a row as needed to fill the width with a gap of atleast 1rem extended so that the items are justified to the left and right and are spread evenly. The last row has however many children are left with those children positioned to match the rows above. See https://stackoverflow.com/a/46099319 https://stackoverflow.com/a/46099319.
bfgeek 2y ago
Part of the tension with building masonry on top of grid is that they work in fundamentally different ways. Grid you place everything in the grid first (e.g. an item goes in col:2,row:3), then size the grid. Masonry ideally you want to size the tracks first, then place items in those tracks. The first Firefox implementation (and the spec at that stage) basically said you don't consider any masonry items for sizing tracks (except for the first row, and some other rules - its complex). This meant that it is trivial to create items that overflow their tracks. The specification at the moment asks to place every item in every possible track. This has quadratic performance O(N_tracks * N_items) in the worst (and somewhat common case). Quadratic performance is bad[1] and we don't really have this in other layout algorithms. With nesting introduced the performance goes (sub-)exponential, which is really poor, even if you have a fast CPU. One may argue that these cases aren't common, but folks always test the boundaries with layout modes in CSS - so things need to be fast by default. Note: In grid items size themselves differently depending on what tracks you place them in, which is why you need to place in every possible position. Masonry potentially needs a different algorithm for sizing tracks to mitigate these problems, (the blog post doesn't go into these issues in sufficient detail). There may have been a version of grid sizing which didn't have item positional dependence but that ship has sailed. [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-in-wmi/ https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...
- afiori 2y ago
  Grid has a rich functionality for autoplacement of items and one of the arguments for masonry being part of grid is that you can easily mix the two positioning approaches https://webkit.org/wp-content/uploads/video3-museum-dark.m4v https://webkit.org/wp-content/uploads/video3-museum-dark.m4v
- fantasai 2y ago
  Quadratic performance is a bit of an exaggeration. It's not O(N_items^2). It's N_tracks x N_items, and basically nobody has N_tracks ≈ N_items. Practically speaking, the upper limit is closer to (N_items^1.5) because N_tracks is unlikely to go over sqrt(N_items) in cases where N is large. And almost all of those layouts will have repetitive track sizing patterns, so they can be optimized to a much smaller N_tracks that approaches O(N_items).
matsemann 2y ago
I think one additional point to consider when adding it as a new display mode vs re-using grid, is that currently these demo's fallback quite nicely now when it's re-using grid. Instead of showing it as masonry (since my browser doesn't support it), it at least behaves as a grid. If it's a new display: X property, it will fallback to div behavior with the content all over the place in unsupported browsers.
- laszlokorte 2y ago
  you could simply do: "display: grid; display: masonry;" and all not-supporting browsers would skip the second declaration.
  - yurishimo 2y ago
    This is assuming there isn’t any cross pollution of shared properties either.
    - danielheath 2y ago
      `@supports masonry { shared-property: 1; }`
jjcm 2y ago
> I think this will make an important precedent It's worth noting this is not the first time things like this have gone to the community for feedback. They did the same for nested CSS selectors, which ended up working quite well feedback-wise: https://webkit.org/blog/13607/help-choose-from-options-for-css-nesting-syntax/ https://webkit.org/blog/13607/help-choose-from-options-for-c...
Izkata 2y ago
> new proprieties I'm guessing this was going to be "properties"? It kinda looks like "proprietary" instead, so let's double down on that - I propose "display: tetris;"
- falcor84 2y ago
  I would suggest that `display: tetris;` is implemented such that each row SHOULD have whitespace, and if at any point a row becomes fully occupied, a conforming rendering agent MUST remove the entire row.
flakiness 2y ago
If there is a debate, who is pushing back? Or is it more about details while every vendor is supportive at high-level?
madeofpalk 2y ago
It seems like the precursor to this was the whole "Help choose the syntax for CSS Nesting" thing that happened a while back. Browser vendors couldn't figure out the syntax, so they asked the 'wider public' which they preferred https://webkit.org/blog/13607/help-choose-from-options-for-css-nesting-syntax/ https://webkit.org/blog/13607/help-choose-from-options-for-c...

pier25 2y ago

I don't know about the implementation but it makes zero sense that masonry should be part of grid. It's not a grid!

eternityforest 2y ago

I've yet to ever find a use case for grid.... I'd prefer this be a flex box feature so I can continue ignoring grid. But it seems like they have good reasons for including it, so I suppose I'll have to actually practice with grid more!

niutech 2y ago

Masonry is easy and has already been solved using CSS Multiple Columns: .masonry { column-count: 6; column-gap: 10px; }

mvonballmo 2y ago

A "row-less" grid fits very well in the current CSS Grid specification, in that it can reuse the very powerful column-definition property as well as sub-grids. Their examples very convincingly show how orthogonal these features are. Mostly, you just write grid-row-template: masonry and everything else just works with it. This is nice. It doesn't become harder to use the grid layout than it already is IMHO. The drawback is mostly for browser-engine authors, for whom the bar for "fully supports CSS Grid" will be set even higher. They also mention that it might avoid "performance traps" where an implementation that needs to support all features of grid might be slower at some parts of grid layout than it would be if the specification were simpler. If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame.

nightpool 2y ago
> If there were a separate display mode, then you'd have to repeat the grid-column specification for the masonry layout, which seems a shame. Why? What's the downside to reusing grid-column-template or whatever for the CSS Masonry spec?
- afiori 2y ago
  > And yes, while making CSS Grid more complex will make it harder to extend in the future, we believe there’s an advantage to having these two types of grid layouts intertwined. This way the CSS Working Group will always define all new additions for both modular and columnar grids. There won’t be something added to display: grid that will be left out of display: masonry, or vice versa. For example, many developers want CSS Grid Level 4 to provide a mechanism for styling grid areas and grid lines — perhaps a way to add a background color to a track, or create a rule line in a gap. It’d be great to ensure that will work for both modular and columnar grids from Day 1. > By using subgrid, we can put the year and catalog number on the right of each card — and line up this data for one painting with the same data for the other paintings. The downside is that all the parts of grid that might be useful in masonry would have to be duplicated in slightly different ways. This together with the fact the the only two current implementations use display: grid If it is possible to make them perfectly compatible then the main negative side
- krsdcbl 2y ago
  my thoughts exactly - i think this points to a possible naming issue, since "masonry" is a relatively vague alias that does not really describe the underlying layouting logic, it just became ubiquitous enough for people building webstuff to understand because of that one jQuery plugin back in the days. A better approach might be to lean on the "grid" naming, but still silo it off via an own display directive (a bit like "block" and "inline-block" have shared properties, but also mutually exclusive behaviours) So maybe an own `display: flex-grid;` could be an interesting solution? This separate layout mode would avoid "result-specific" nomenclature like "masonry", and could lean on both flexbox & grid to achieve that look: - using `grid-auto-flow` to set a "masonry axis" & distribution logic - using _either_ `grid-template-columns` or `grid-template-rows` to specify the "lanes" - and to make my frankensteinian display-mashup even worse (or genius! for you to decide), the grid items could in turn abuse `flex-grow, flex-shrink, flex-basis` to control their height/width within the main "masonry" axis

eyelidlessness 2y ago

> Either way, it's not as easy as it looks. And exploring the tradeoffs might lead those exploring to reconsider their preferences going in. Not directly related to the topic, but I recently did some prototyping on a second iteration of an interface with a similar tension—proliferation of similar but distinct types in a data model, or expanding the set of nuances within each existing type to support refinement within it. Going into that prototyping session, I had a very strong bias in favor of the latter. But after exploring the options, I found it vastly simpler to consume the “bloated” interface, and to reason about the resulting application code consuming it. I don’t have strong feelings on the topic as it applies to CSS masonry, but I suspect there could be similar surprises in how people think about this tension intuitively versus in practice. And while I think CSS in particular will have a hard time justifying “bloat” (proliferation of use case specific semantics), I think it’s possible that users do tend to find more difficulty using CSS’s denser APIs (like grid).

qingcharles 2y ago

It's great they're doing this. I've been nudging everyone involved with this since last year. The Chrome guys are the furthest behind (no support). FF has flag support. I've been testing it since last year on FF and Safari and have no complaints about their implementations. I know some people are sniffling about the placement and naming of the properties. You have to be pragmatic about it, though, and realize there probably isn't a perfect solution and just implement it. I refuse to use JavaScript for the fallback, so the fallback is a lot of ugly CSS that doesn't order things in the right way, but it doesn't make a big deal of trouble for the project I'm working on. Most people will fallback to JavaScript right now, though, and when JavaScript is your solution to layout then you're already on a loser.

doctorpangloss 2y ago

Is there a JavaScript polyfill today that can read the CSS properties in any of the proposed / implemented specifications that Just Works in Chrome?

aidog 2y ago

look at the examples they made why it should be in CSS grid. I totally agree it should be in that. It's a form of grid. It should be part of CSS grid. This is one of the layouts that were just impossible in CSS and we really need it soon. I also needed the feature they talk about with the background colors for css grid tracks in 2012. I solved that with DIVs, but it was hard to make it responsive.

reactordev 2y ago

CSS Grid is a mistake. Baking in a design philosophy when we had really creative pages without it. I like grids for pages with content and documentation and such. I don’t like grids for pages of media or other creative content. Cards, flex box, grids, these are all design framework choices and shouldn’t be in CSS spec. We were totally fine with position relative and media-query centric widths and heights. I get that it’s easier to standardize if grids are part of the standard but I miss the days of pages having some creativity in their design. Every site looks the same nowadays. And before I get downvoted. I have a degree in graphic design. I love CSS and I love the web. Bring back the fun.

rhdunn 2y ago
CSS grid makes it possible to implement wrapped content that is uniformally aligned with the last row keeping the same number of columns as the others, and have that scale correctly to different page widths. This is useful in things like book layouts. You can get close with flex, but the last row doesn't fully work.
- reactordev 2y ago
  Does it require a ::last-child hack to get working? I’m a fan of grids when it comes to heavy writing content like I mentioned but I still don’t think it should all be packed in the spec.
  - rhdunn 2y ago
    No, just: main.books { display: grid; grid-template-columns: repeat(auto-fill, 180px); grid-gap: 1rem; justify-content: space-between; } That will make the child items 180px wide, repeat as many children in a row as needed to fill the width with a gap of atleast 1rem extended so that the items are justified to the left and right and are spread evenly. The last row has however many children are left with those children positioned to match the rows above. See https://stackoverflow.com/a/46099319 https://stackoverflow.com/a/46099319.

bfgeek 2y ago

Part of the tension with building masonry on top of grid is that they work in fundamentally different ways. Grid you place everything in the grid first (e.g. an item goes in col:2,row:3), then size the grid. Masonry ideally you want to size the tracks first, then place items in those tracks. The first Firefox implementation (and the spec at that stage) basically said you don't consider any masonry items for sizing tracks (except for the first row, and some other rules - its complex). This meant that it is trivial to create items that overflow their tracks. The specification at the moment asks to place every item in every possible track. This has quadratic performance O(N_tracks * N_items) in the worst (and somewhat common case). Quadratic performance is bad[1] and we don't really have this in other layout algorithms. With nesting introduced the performance goes (sub-)exponential, which is really poor, even if you have a fast CPU. One may argue that these cases aren't common, but folks always test the boundaries with layout modes in CSS - so things need to be fast by default. Note: In grid items size themselves differently depending on what tracks you place them in, which is why you need to place in every possible position. Masonry potentially needs a different algorithm for sizing tracks to mitigate these problems, (the blog post doesn't go into these issues in sufficient detail). There may have been a version of grid sizing which didn't have item positional dependence but that ship has sailed. [1] https://randomascii.wordpress.com/2019/12/08/on2-again-now-in-wmi/ https://randomascii.wordpress.com/2019/12/08/on2-again-now-i...

afiori 2y ago
Grid has a rich functionality for autoplacement of items and one of the arguments for masonry being part of grid is that you can easily mix the two positioning approaches https://webkit.org/wp-content/uploads/video3-museum-dark.m4v https://webkit.org/wp-content/uploads/video3-museum-dark.m4v
fantasai 2y ago
Quadratic performance is a bit of an exaggeration. It's not O(N_items^2). It's N_tracks x N_items, and basically nobody has N_tracks ≈ N_items. Practically speaking, the upper limit is closer to (N_items^1.5) because N_tracks is unlikely to go over sqrt(N_items) in cases where N is large. And almost all of those layouts will have repetitive track sizing patterns, so they can be optimized to a much smaller N_tracks that approaches O(N_items).

matsemann 2y ago

I think one additional point to consider when adding it as a new display mode vs re-using grid, is that currently these demo's fallback quite nicely now when it's re-using grid. Instead of showing it as masonry (since my browser doesn't support it), it at least behaves as a grid. If it's a new display: X property, it will fallback to div behavior with the content all over the place in unsupported browsers.

laszlokorte 2y ago
you could simply do: "display: grid; display: masonry;" and all not-supporting browsers would skip the second declaration.
- yurishimo 2y ago
  This is assuming there isn’t any cross pollution of shared properties either.
  - danielheath 2y ago
    `@supports masonry { shared-property: 1; }`

jjcm 2y ago

> I think this will make an important precedent It's worth noting this is not the first time things like this have gone to the community for feedback. They did the same for nested CSS selectors, which ended up working quite well feedback-wise: https://webkit.org/blog/13607/help-choose-from-options-for-css-nesting-syntax/ https://webkit.org/blog/13607/help-choose-from-options-for-c...

Izkata 2y ago

> new proprieties I'm guessing this was going to be "properties"? It kinda looks like "proprietary" instead, so let's double down on that - I propose "display: tetris;"

falcor84 2y ago
I would suggest that `display: tetris;` is implemented such that each row SHOULD have whitespace, and if at any point a row becomes fully occupied, a conforming rendering agent MUST remove the entire row.

flakiness 2y ago

If there is a debate, who is pushing back? Or is it more about details while every vendor is supportive at high-level?

madeofpalk 2y ago

It seems like the precursor to this was the whole "Help choose the syntax for CSS Nesting" thing that happened a while back. Browser vendors couldn't figure out the syntax, so they asked the 'wider public' which they preferred https://webkit.org/blog/13607/help-choose-from-options-for-css-nesting-syntax/ https://webkit.org/blog/13607/help-choose-from-options-for-c...