Caveat: I know nothing about this, but have some experience with grid and flexbox.
To my mind flexbox could be a basis for masonry way better than grid with less overhead.
I also think mosaic would be a better name.
Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
311–320 of 359 posts
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#312Earlier quoted context omitted.
JS DOM API is still abysmal and jQuery API is still great. No worshipping needed.
Really? Genuine question, which part? If there are too many to name, how about just one? It seems pretty good to me.
jQuery has a fluent interface and often shorter/smaller/more convenient APIs on top of that.
DOM APIs are quite literally 90s era Java-style APIs.
While DOM APIs have pulled in a few niceties over the years, some of them are really anemic (e.g. querySelectorAll does not return a proper Array-like object). Worse is combining them. Almost every API is a single-shot tedious step-by-step chore.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#313So, 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…
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-c...
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#314I strongly dislike the megamenu demo https://webkit.org/demos/grid3/megamenu/ >, and feel masonry is completely inappropriate there. It makes a complete mess of flow direction, badly breaking expectations. The reading order you’d expect : https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-2.... . What the demo actually gives you: https://temp.chrismorgan.info/2024-04-23-masonry-megamenu-1.... . This affects co…
Focusing solely on sighted users, I think the current ordering makes sense. What you propose would require often scrolling up and down to view the items in order, and would have large layout shifts if more items are added.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#315Earlier quoted context omitted.
Why does this require checking every item in every column? It looks like the layout algorithm greedily picks the column with the least total height so far, every time it adds an item.
The requires it for sizing the columns (the step before placing the items into the columns).
The examples in the article seem to have CSS that directly sizes the columns, albeit with some flexibility such as being able to change the number of columns to better fit the width. It seems like the item widths depend on the column widths, rather than the other way around (which seems like it'd be circular). What's an example where the column widths depend on the items?
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#316Earlier quoted context omitted.
So you're saying the a11y tree and tab ordering is bypassing the actual ordering of content and instead traversing the columns one by one? I'd call that a bug. In a masonry layout the expectation of a sighted user is that there is no continuity from column to column, but instead through the visual line. And the "unexpected" (disagree) ordering you show does that. I think the issue would be that tab ordering is ignori…
Maybe it's just me, but as a sighted user I have no idea how to read this kind of layout. My expectation would be that any sane designer wouldn't use this kind of layout in the first place. What's the "visual line" in the first example? It goes 1, 2, 3, 4; then down to 5; then a sudden break in the line as it jumps over 3 to the left to reach 6? Are we supposed to mentally sort the boxes by the top edge coordinates b…
Well, the idea with this layout is that there isn't really an inherit order to the children. You would use it where it doesn't matter which order you 'read' the items.
If the order was important, you would use a 1D or 2D layout.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#317Suppose 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…
This would be such an interesting write up comparing many styling/layout systems! Unfortunately I reckon not many people have experience with multiple styling languages, so not many people can create such a write-up. I think flutter and XAML might be other interesting ones to look at
XAML poorly reimplements half of CSS layout, and then gives up and tells you to write your own manually positioned layout with terrible performance.
Things which are 3 lines in CSS are hundreds of lines of a combination XAML/.NET only to get janky window resizing behaviour.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#318Earlier quoted context omitted.
The requires it for sizing the columns (the step before placing the items into the columns).
The examples in the article seem to have CSS that directly sizes the columns, albeit with some flexibility such as being able to change the number of columns to better fit the width. It seems like the item widths depend on the column widths, rather than the other way around (which seems like it'd be circular). What's an example where the column widths depend on the items?
If you have something like:
columns: 1fr auto max-content
1
somethingsuperlong
something else
Depending on the non-fixed column type (there are different rules for each type) you want to ensure their constraints are satified (typeically they are big enough to encompass the items).
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#319CSS is such a failure. Grid is the 3rd or 4th iteration of layout methods and still you need to think this much about how to code a layout? This is the most basic thing in UI and we've been doing it for 3 decades.
Re: Help us invent CSS Grid Level 3, a.k.a. "Masonry" layout
#320I am wondering whether it makes sense to keep adding more "layout" options to CSS, given that we have the legacy floats and then the modern flexbox and grid layout. If there are still cases that are not covered, perhaps a better solution to to have one final constraints-based system that covers all layout cases, even if it comes at the cost of complexity. The CSS frameworks and utility libraries will then be built on…
I'm dubious that a constraints system would ever be considered, CSS has so far had some strong goals around it's predictably on layout cost.. that said, Houdini layout proposal is the closest to your comment, offloading layout to an isolated js context https://github.com/w3c/css-houdini-drafts/blob/main/css-layo... .. but honestly flex and grid, plus other things like containment have solved so many things for folks…
Oh man - I remember attending a CSS meetup in like 2014 at the Google offices in Sydney where someone from the CSS WG presented Houdini Layout. I would be surprised if that ever ships.