Re: [csswg-drafts] [css-grid-3] Designer/developer feedback on masonry layout (#10233)

Honestly?... I think these details are trivial.

### 1. Is there *any* use case in which the names of CSS properties impacts the end user experience?

No.

This isn't like HTML5 where proper elements / aria's are required for screen readers to function properly. These "semantics" are only relevant for the developer experience.

Consequently in [this article](https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/#inventing-masonry), the following argument holds *zero* weight in my mind.

> Another argument made by advocates of display: masonry is that that masonry is conceptually a fundamentally different layout type from CSS Grid, and therefore should have its own display type. They often describe CSS Grid as inherently being about “lining things up in two-dimensions”, and since masonry only lines things up in one dimension, “it’s not a grid”. (In fact, some have advocated that Masonry is more like Flexbox, since “both line things up in one direction”.)

Ok sure let's go with the "Akshually it's a different concept"... so what? If we're going to argue about things being be conceptually reasoned, we have bigger problems...

Coercion is still a part of JS 😑

Try explaining how some of the following examples are consistent from the simplest lexical concepts to a new coder, or even a seasoned coder who has never seen JS:

https://github.com/denysdovhan/wtfjs

The point is conceptuality can serve as a good guidepost but as demonstrated it is not necessarily binding, and once whatever the thing in question is learned, it just becomes semantic anyway.

### 2. Is there any use case in which the semantics of this CSS impacts the dev experience?

Given both options are being presented (`masonry as part of grid`, `display: masonry`), I have to assume either can be implemented without any performance hit?

That being true, we already know that no matter how ratchet a bit of code looks, if it gets the job done with great performance and no side effects, of course we're gonna use it.

In fact there's also an argument to be made, the more "hacky" a solution seems, provided it's not too verbose, the more enjoyable it is to learn/use as a dev. To the point where we fondly give them their own names: clearfix, OneDiv, IIFE's, Fast Inverse Squirt (Quake 3), etc.

### 3. Is there any use case in which the semantics of this CSS impacts the browser vendors?

Possibly? The article has the following:

> 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.

If i'm understanding correctly it means tying the details together in the spec necessarily ties the implementation together in browser engines, thus ensuring feature parity between both types of grid.

Also i find it curious it's prefaced with this:

> And yes, while making CSS Grid more complex will make it harder to extend in the future

Extend... to what? Unless we're adding a Z dimension of depth for augmented reality or something? And in such a case those changes *would* necessitate the change of display type property for things other then masonry and grid anyway?

### Direct answers

> Should “masonry”/“waterfall” be part of CSS Grid?

Unanswerable by anyone not familiar CSS layout engines. My general view is, whatever's better for performance, if they're equivalent then whatever's easier to implement / maintain.

Throwing the question out to the internet, i'm reminded of the following quote (that was perverted by managers):

The customer is always right... *in matters of taste*.

Every dev is going to have their own take on the matter. Sure you might get some consensus islands happening, but ultimately it's going to be impossible to please everyone.

> Do you want the capabilities to define a columnar grid with CSS Grid — to use subgrid, spanning, explicit placement, and all the many options for track sizing? Or do you only want the ability to define a classic masonry layout with equal-sized columns?

If there's no other "penalties", more flexibility is much more betterer.

> Will you use this? What might you create with it?

I think this question is a little obvious 😑 Just think of where you've seen masonry layouts. Image gallery's (pinterest), traditional newspaper column layouts, etc.

Though there is one possibility i'd like to consider. Rendering a masonry grid takes quite a bit of calculation, it could be interesting if some of those internal functions were exposed via `calc()` or something.

-- 
GitHub Notification of comment by marblewraith
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10233#issuecomment-2086025174 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 30 April 2024 17:06:41 UTC