Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Grid Lanes

webkit.org

Post reply on HN
Print view View original

111–120 of 237 posts

Re: CSS Grid Lanes

#111

Post by notpushkin »

karlshea wrote: post #78
dylan604 wrote: post #34

Earlier quoted context omitted.

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.

Not quite – “bricks” would have a jagged edge on the right side, while “justified gallery” libraries produce even rows of the same length (but slightly different height), e.g. https://justifiedgallery.com/ or https://miromannino.github.io/Justified-Gallery/

Re: CSS Grid Lanes

#112

Post by anonymous908213 »

ethmarks wrote: post #80
Sharlin wrote: post #76

Earlier quoted context omitted.

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 m…

Danbooru[1] and Danbooru-derived image boards handle this perfectly, and are a genuine pleasure to browse relative to the awful experience that is pinterest. There is empty space between images, and that is fine. You don't need to occupy every pixel in the screen to begin with, that's why we have these magical things called "margins", elements need room to breathe in the first place.

[1]https://safebooru.donmai.us/ (note: this is a "safe" subset of danbooru for reference, but it is still not safe for work)

Re: CSS Grid Lanes

#113

Post by kyle-rb »

simondotau wrote: post #81
concinds wrote: post #63

Earlier quoted context omitted.

Cool stuff they're working on tends to take a very long time to reach customers' hands compared to other browsers. Just compare the "stable" and "experimental" graphs on wpt.fyi for Safari. I can't think of a single good reason why they don't adopt an "evergreen" 4/6-week update model except Not Invented Here syndrome or "it's not Apple-like, we prefer the OS team (and therefore Marketing) dictating our release sched…

The web platform doesn’t need to move this fast. Google is, often unilaterally, pushing new features and declaring them standards. In my opinion, the web should not be changing so fast that a truly open source community project couldn’t keep up. I don’t like how the web has become reliant on the largesse of billion dollar corporations. I recognise that this is a controversial take, but in my opinion what Google is do…

The web platform on your device needs to be locked to a specific version because the OS stopped being updated. Once the OS stops being updated, you're supposed to buy a new device.

You shouldn't be allowed to use an old device with an updated browser, especially not a browser from a 3rd party, because that doesn't help Apple sell more iPads.

Re: CSS Grid Lanes

#114

Post by BowBun »

ray_v wrote: post #82

If I ever encounter, and need to read a webpage with arbitrarily sized and placed grids of text, please somebody just shoot me. https://webkit.org/wp-content/uploads/Grid-Lanes-newspaper-d...

I agree, this seems to violate some of the most fundamental concepts of design like least-surprise and using grouping + alignment to give context to readers.

Re: CSS Grid Lanes

#115

Post by [deleted] »

concinds wrote: post #90
simondotau wrote: post #81

Earlier quoted context omitted.

The web platform doesn’t need to move this fast. Google is, often unilaterally, pushing new features and declaring them standards. In my opinion, the web should not be changing so fast that a truly open source community project couldn’t keep up. I don’t like how the web has become reliant on the largesse of billion dollar corporations. I recognise that this is a controversial take, but in my opinion what Google is do…

I know it's fashionable to forcefully shove the same pet peeves about Chromium into any topic even loosely related, but here I'm talking about Safari webcompat fixes, bug fixes, and improvements having very long delays between being written and landing in customers' hands. I would make the same argument if Chrome never existed. Thank you for presenting the 10,001st reissue of this "controversial take".

[deleted]

Re: CSS Grid Lanes

#116

Post by GaryBluto »

To quote the wise Karl Pilkington: "Do we need 'em?"

HTML has become more and more bloated. How many methods do we need to do something that was possible back in the 90s?

Re: CSS Grid Lanes

#117

Post by nicoburns »

hoten wrote: post #102
culi wrote: 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 wonder if Ladybird has explored running these interop tests yet. Or maybe these are just a subset of WPT?

They are indeed just a subset of WPT. Although the way subtests are weighted in the score calcustion is slightly different for the "interop" score.

Re: CSS Grid Lanes

#118

Post by powersnail »

Sharlin wrote: post #77
SahAssar wrote: post #62

Earlier quoted context omitted.

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.

Just curious, what algorithm is good for laying out images of arbitrary orientations, sizes, and aspect ratios? That seems like a pretty difficult problem. Some sort of variation of knapsack problem maybe?

Re: CSS Grid Lanes

#119

Post by notpushkin »

tom1337 wrote: post #43
nitwit005 wrote: post #30

How would you query the location where you need to load more data when scrolling down (the highest empty spot)?

I guess you can just start loading a first batch, add an intersection observer to the last 3 elements (if you have 3 lanes) and then when one of those intersects you simply start fetching the next.

Hmm, I think we only need to observe the `elements.at(-numberOfLanes)`, as it should be the first to enter the screen anyway.

Re: CSS Grid Lanes

#120

Post by willio58 »

GaryBluto wrote: post #116

To quote the wise Karl Pilkington: "Do we need 'em?" HTML has become more and more bloated. How many methods do we need to do something that was possible back in the 90s?

While I like a Karl Pilkington quote as much as the next guy, I really do want this. I have one specific use case for this layout that's always felt a little bit painful to reach into js for. I can't wait for the day I can simplify that further into native CSS.
Post reply on HN