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

*Disclaimer*: I read the webkit blog post. I'm coming in with a clean set of eyes, but limited expertise in this specific proposal. My background is developing full stack applications (some major, like Open edX, and many little ones), as well as a lot of teaching experience, again, full stack, spanning elementary schools through corporate PD through MIT EECS students. Take this as a 1000-foot-view. 

*Feedback*: I like the concept, but I don't like the proposal [as presented here](https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/) or where the discussion is headed (keeping in mind there are other proposals as well, and a blog post is an imperfect presentation). 

I think the key issues are:

1. CSS and HTML have been growing in complexity -- almost exponentially -- since the HTML 2.0 days when it could be taught to elementary school students to where it's inordinately complex.
2. There has been a battle of semantics versus directing pixel-perfection for many years. Pixel-perfection keeps winning.
3. Related to that, there has been a battle of semantic elements versus everything-is-a-div
4. All of that also makes things like one-off browsers, bots, scrapers, test cases, etc. increasingly complex. This was a major use-case in the nineties. 
5. Even today, with most of the creative client-side stuff dead, and where even Microsoft can't afford to maintain its own browser engine, there are critical audiences hurt by the growth in complexity and decline in semantics (e.g. a11y)

This discussion feels like it is far too far on the complexity / pixel-perfection / everything-is-a-div side. As with many of these discussions, it's dominated by front-end developers who are comfortable with language like `main:nth-child(100n) { grid-template-rows:masonry(1)}`, let alone `--_total-gap-width: calc(var(--_gap-count) * var(--_gap-column, 0px));`. That's a very small portion of people who would be using this. 

It's also -- to be frank -- not very important. Big web sites will look a little bit prettier, which will make web devs happy, but I don't think the world improved when it went from Hacker News or Craigslist-style layouts. People are famously okay with simple layouts. Having a nicer one gives a competitive edge, but if everyone has a nicer one, the competitive edge goes away, and we're just treading water. Making ugly layouts easy and nice layouts hard -- which is what happens when HTML / CSS become more complex -- just gives an edge to big corporations who can afford big front-end teams. 

What I'd love to see here is HTML and CSS which is simple enough that I mere mortals can read and write layouts without digging through reams of documentation. 

I think the trick would be to do user studies with e.g. high school students. Can (like HTML 2.0) be taught and interesting in a short session? If so, bring it in. Until not, leave it out. 

I suspect where a proposal might land might be:

1. Define and document clear use-cases.
2. Extend CSS, _and HTML_, to handle those which works out-of-the-box to good results. Something as simple as `<gallery><img><img><img></gallery>`.
3. Provide a few easy-to-understand high-level options (e.g. should order be kept, or can the browser rearrange the order per some optimization? should a particular box be made big?). 
4. Since we can't get away from it, provide a set of further properties which allow pixel-perfection for the front end developers, and perhaps some validation (remember ACID, back in the day?). 

Publish those, and ask for feedback. See how understandable they are to ordinary individuals -- ideally at the level of high-school students, but at the very least, non-front-end developers. You can even walk into the grumpy sysadmin's office at your own company and see what they think. 

FWIW, major use cases I've seen are (1) an image gallery (2) a newspaper-style navigation page, of boxes with text. Those sorts of things might want semantic HTML elements. Using those elements, CSS should be strictly optional. 

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


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

Received on Wednesday, 24 April 2024 11:15:36 UTC