Live data from Hacker News

CSS Grid Lanes

webkit.org

71–80 of 237 posts

Re: CSS Grid Lanes

#71
Is anyone working on actual css problems instead of this sugar syntax?

Hypermedia suffers because these marketing companies waste time on making sure they can build Pinterest in 10 LoC instead of fixing actual long running hypermedia domains.

Re: CSS Grid Lanes

#72
post #39

Earlier quoted context omitted.

You just append new elements to the in the example and it will automatically put them in the appropriate column.

Your answer doesn't appear to relate to what I asked. You need to know when to query the backend for more data if it's an infinite scrolling setup.

Aahh. The way you phrased your question was pretty ambiguous.

The other posters have good answers. One thing to consider for a smooth interaction would be to eagerly load the next x elements before they scroll into view.

Re: CSS Grid Lanes

#73
post #27

Props to the Safari team. They surprised us all when they suddenly shot to the top of interop-2025 this October https://wpt.fyi/interop-2025

I hope they add WebTransport support soon.

Re: CSS Grid Lanes

#74

Is anyone working on actual css problems instead of this sugar syntax? Hypermedia suffers because these marketing companies waste time on making sure they can build Pinterest in 10 LoC instead of fixing actual long running hypermedia domains.

Moving this sort of stuff out of JavaScript and arcane hacks allows the browser rendering engines to optimize these common patterns. This is sorta the opposite of syntactic sugar. The syntactic sugar is the libraries that implemented these patterns without rendering support.

Shall we call it syntactic umami perhaps? Or syntactic lipids?

Re: CSS Grid Lanes

#75
post #72

Earlier quoted context omitted.

Your answer doesn't appear to relate to what I asked. You need to know when to query the backend for more data if it's an infinite scrolling setup.

Aahh. The way you phrased your question was pretty ambiguous. The other posters have good answers. One thing to consider for a smooth interaction would be to eagerly load the next x elements before they scroll into view.

Yeah I’d assume you’d eagerly load enough to make sure everything gets at least partially into the viewport, and maybe a fee more to optimize for network latency. And then perhaps track elements whose trailing ends are not in the viewport, and load more once those become fully visible?

Re: CSS Grid Lanes

#76
post #58

Earlier quoted context omitted.

The biggest problem is that it's good if your images are all landscape or all portrait, but not when mixed.

What? The defining feature of masonry is that it supports mixed aspect ratios. That's its whole thing. If you aren't mixing landscape and portrait images, you shouldn't be using masonry layout.

Masonry layout fixes one of the dimensions. That means either portrait or landscape images will look visibly smaller (less detailed, more ignorable, etc) than those of the inverse aspect ratio, because their longer side must be the same length as the latter’s shorter side. This has real UX consequences. What masonry works best with is images of different aspect ratios but the same orientation.

Re: CSS Grid Lanes

#77
post #58

Earlier quoted context omitted.

The biggest problem is that it's good if your images are all landscape or all portrait, but not when mixed.

The whole point of a masonry layout is if you have different aspect ratios. Otherwise a masonry layout is just a normal grid.

Masonry layout fixes one of the dimensions. That means either portrait or landscape images will look visibly smaller than those of the inverse aspect ratio, because their longer side must be the same length as the latter’s shorter side.

Masonry works well if you have different aspect ratios of the same orientation.

Re: CSS Grid Lanes

#78

I've run the masonry layout (for my personal bookmark website) ever since I've found it in the browser settings. grid-template-rows: masonry; is going to be outdated then?

I still prefer the layout look from something like justifiedGallery.js where the heights of each row are the same. Actual masonry with stacking stones would never stack directly on top of each other like this. Calling it masonry just feels unnatural as anything stacked like that would easily be knocked over. "Lanes" is definitely more appropriately named than "masonry". The layout look of a justifiedGallery would be…

What you’re looking for is described in the article as “bricks” (vs “waterfall”) and is also supported.

Re: CSS Grid Lanes

#79
post #7

Earlier quoted context omitted.

Not updating your browser will net you tons of exploitable vulnerabilities. How do you expect things to ever change if no one ever updates? Certainly even if you decide to lean towards maximum support it’s still a positive these features are being introduced so you can use them in 10 years.

> How do you expect things to ever change if no one ever updates? Maybe things should stop changing. We don't really need ten new CSS attributes every year. Things work. The elegant solution is to announce the project is done. That would bring some much-needed stability. Then we can focus on keeping things working.

> Maybe things should stop changing.

There are two kinds of technologies: those that change to meet user needs, and those that have decided to start dying and being replaced by technologies that change to meet user needs.

Re: CSS Grid Lanes

#80
post #76

Earlier quoted context omitted.

What? The defining feature of masonry is that it supports mixed aspect ratios. That's its whole thing. If you aren't mixing landscape and portrait images, you shouldn't be using masonry layout.

Masonry layout fixes one of the dimensions. That means either portrait or landscape images will look visibly smaller (less detailed, more ignorable, etc) than those of the inverse aspect ratio, because their longer side must be the same length as the latter’s shorter side. This has real UX consequences. What masonry works best with is images of different aspect ratios but the same orientation.

Pointing out that masonry isn't as good with mixed-orientation content as it is with uniform-orientation content is all well and good, but we still need a way to display mixed orientation content. What alternatives to masonry do you propose?

- If you stretch all images into a uniform aspect ratio, they get all squashed and look terrible.

- If you crop all images into a uniform aspect ratio, you lose potentially the majority of the content in some images.

- If you display all images at their natural aspect ratio and their full size, there will be huge swathes of empty space in between them because they don't pack tightly.

Masonry layouts allow you to preserve aspect ratio without wasting a massive portion of your user's screen space. It's not perfect, but it's the best layout mixed-orientation content that I know of.

If you know of a better method to handle mixed orientations, I'd love to hear it and would gladly rescind by remarks.

Post reply on HN