[flagged]
Why would breakpoints be an issue? They’d just work the same as any other CSS feature wrapped in a media query.
Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
191–200 of 359 posts
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#192Can you add drag and drop to this? Currently you need libraries like https://gridstackjs.com/, especially for nested cases.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#193Suppose we could create a backwards-incompatible system to replace CSS. How would we do it?
Are there any books or papers on how to create a coherent layout system?
What about alternatives like Qt, Tk, SwiftUI, etc.? I've never used anything besides CSS. Are any of the actually-implemented systems in the wild better? If so, what makes them better?
I want a system that provides a better interface for developers, but how? If we could start over, what are the design principles?
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#194Earlier quoted context omitted.
That's just a random demo. It's not particularly relevant for the concept they're trying to gather feedback on
The demos should be motivating the feature. A bad demo is destructive to that effort. This is a very bad demo.
If you open the demos in a browser like Safari that doesn't support the feature, the demos remain as normal grid-aligned cells.
There I realize that masonry mainly works when your cells have such different heights that to grid-align them creates a lot of vertical dead space. Images and news blocks with images make sense for masonry for this reason and it feels good.
But text-only cells where the cell heights don't differ much, they seem better without masonry. The megamenu demo also works much better as a normal grid because they start with a header so grid alignment lets you scan the headers left to right easily.
A text-only newspaper could make sense with masonry because you aren't trying to navigate relationships between the items, and presumably the content can vary the cell height a lot.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#195Earlier quoted context omitted.
Surely questioning the real world usefulness is not "toxic"? CSS is already very complicated. Adding more options needs proportionally strong justification.
No, but basing capabilities solely on what they imagine "well-known websites" might want is .
And how would you do it sans imagination?
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#196So, 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…
> 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).
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#197Reposting as a top comment for more visibility:
I have a website with my photos, which doesn’t use any JS for layout. When I was making it, I considered using JS masonry libraries, but I wasn’t satisfied with the results. Proper masonry layouts which fill all available space in practice actually crop some images. Leaving space around photos is required when you don’t want cropping and want to preserve aspect ratio. The only way not to do that is to have infinite scroll, which I guess is what corporate addiction machines want, but that’s not what I want on my own website. Here is what I did:
https://yakubin.com/photography/albumless/
https://yakubin.com/photography/album/kenya-2023/
I used display:inline-block to achieve this result, effectively treating photos as text that needs to reflow into new lines. I’m very satisfied with the result and prefer it over what the masonry libraries do.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#198Webkit team snorting cocaine? look at this, how intuitive, how readable: grid-template-columns: 14ch repeat(auto-fill, minmax(28ch, 1fr)) 14ch; just throw the whole grid thing out of the window and get on board someone who can create syntax that wouldn't send you to jump off a cliff and feels like it was made by a fellow human being, not an AI controlled robot.
Well, at least show us your ideal replacement for that logic that's more intuitive.
Until then, these complaints usually cash out into unfamiliarity + assuming it's very hard to understand if you were you trying to understand it.
Declarative UI is a very hard problem, so it's not always going to be `text-decoration: underline`.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#199Suppose we could create a backwards-incompatible system to replace CSS. How would we do it? Are there any books or papers on how to create a coherent layout system? What about alternatives like Qt, Tk, SwiftUI, etc.? I've never used anything besides CSS. Are any of the actually-implemented systems in the wild better? If so, what makes them better? I want a system that provides a better interface for developers, but h…
One thing to be cautious about when selecting prior art for reference is that CSS sets a high bar for declarative control. I can’t speak to any you mention in detail, but my sense is that more comparable prior art would likely be found in print use cases.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#200Neat. I like it.
Out of curiousity, why don't browsers have pluggable layout managers? Like Java's AWT/Swing LayoutManager. [1]
Fussing with CSS and Java's stock layout managers (gridbag, table) always fills me with frustration and anxiety. In my experience, for the fussy work, it's easier to explicitly code what I want.
Ages ago, inspired by Designing Visual Interfaces [2], I made a layout manager [3] for canonical design grids [4].
It was pretty neat. Fluent API. Always visually correct. All the baselines aligned just so. Predictable results. Perfect for banging out CRUD forms. [5]
1/ https://docs.oracle.com/en/java/javase/21/docs/api/java.desk...
2/ https://www.amazon.com/Designing-Visual-Interfaces-Communica...
3/ https://web.archive.org/web/20110302212909/http://java.net/p...
4/ https://web.archive.org/web/20110308034949/http://designgrid...
5/ https://web.archive.org/web/20110515182322/http://wiki.java....