Live data from Hacker News

CSS Grid Lanes

webkit.org

61–70 of 237 posts

Re: CSS Grid Lanes

#61
post #37

Maybe this will be an unpopular opinion, but I really dislike the lane layout, because it is not possible to efficiently take a glance at all elements in the list, one by one. If you try to go left-to-right, you will quickly realize that at the end of each "line" it is really difficult to know where the next line starts. It is easy to accidentally start again on the same line (and inspect the same elements), or skip…

Thankfully the feature is just in time for it to fall out of fashion! It really is an awful layout, UX wise. But at least it looks pretty at a glance!

Re: CSS Grid Lanes

#62
post #58

I always thought that the masonry layout looked good but made it harder to get a good overview of the images.

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.

Re: CSS Grid Lanes

#63
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

This seems like a bit of a trend with Safari. Around big releases Apple will announce how Safari is the best at X, but other times of the year it gets a lot of flack. I assume this is due to Safari’s more traditional release schedule vs other browsers continuously shipping feature updates.

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 schedule, users be damned".

It's an own-goal for no reason.

Re: CSS Grid Lanes

#64
how does it work with animations? like if i transition:all and then remove a middle img does the other elements get animated?

Re: CSS Grid Lanes

#65

Earlier quoted context omitted.

11 years ago we had Python 2.7.8 and 3.4.0 so no type hints, no async await, no match syntax, no formatted string literals, large number couldn’t be written like this 13_370_000_000, etc. Developers deserve nice things.

> Developers deserve nice things. I agree they do. But Python is a bad counterexample. You can upgrade your Python on your server and no one has to know about it. But if you want to use new CSS features, then every browser has to implement that feature and every user has to upgrade their browser. The intent of my comment was to express a desire to stabilize the web API in particular, not to freeze all software develo…

But people ship python software, just like they ship CSS software, and python is bundled in many operating systems. When somebody ships e.g. a CLI tool to manipulate subtitle files, and it uses a language feature from python 3.9, that somebody is excluding you from running it on your 11 year old system.

People get new browser versions for free, there are more important things to thing about than users that for some reason don‘t want to upgrade. Like I would rather have my layout done quickly with nice elegant code (and no hacks) and spend my extra time developing an excellent UX for my users that rely on assistive technology.

Note that your wish for stabilization was delivered by the CSSWG with the @supports rule. Now developers can use new features without breaking things for users on older browser. So if a developer wants to use `display: grid-lanes` they can put it in an @supports clause. However if you are running firefox 45 (released in May 2016; used by 0.09% of the global users) @supports will not work and my site will not work on your browser. I—and most developers—usually don’t put things in an @support clause that passes "last 2 version, not dead, > 0.2%"

Re: CSS Grid Lanes

#66
post #58

I always thought that the masonry layout looked good but made it harder to get a good overview of the images.

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.

Re: CSS Grid Lanes

#67

Earlier quoted context omitted.

I don't know about "most". For various reasons, I use a 2-year-old browser on a daily basis (alongside an up-to-date browser), and I routinely run into websites that are completely broken on the 2-year-old browser. Unrelated to outdatedness, I recently ran into a local government website that e-mailed me my password in plaintext upon account creation. I have no way of accurately quantifying whether "most" web develop…

I think a very common browserlist target is "last 2 version, not dead, > 0.2%". So if you have a 2-year old browser you are probably dozens of versions behind and are very likely in that 2% of users which developers simply ignore.

Going back 2 versions, only ~50% of Chrome users are on v140 or newer. If you go back another 2 versions, that number increases to around ~66%. Going back another 2 versions only increases that to 68%, with no huge gains from each further 2 step jump. That you think your target gives you 98% coverage is concerning for the state of web developers, to say the least.

After checking further, almost 20% of Chrome users are on a 2+ year old version. If you handle that gracefully by polyfilling etc., fine. If you "simply ignore" and shut out 20% of users (or 50% of users per your own admission of support target), as I have encountered in the wild countless times, you are actively detrimental to your business and would probably be fired if the people in charge of your salary knew what you were doing, especially since these new browser features are very rarely mission-critical.

Re: CSS Grid Lanes

#68

I don't understand all the busywork goes behind new browser updates, just to retain their market share (since they can afford more engineers, than say Ladybird). Is this needed? It's not rocket science, folks.

All these CSS upgrades have been meant to reduce the need for Javascript for all the things web devs do out there in the real world. It's a good thing.

You should tune out more of the ambient cynicism because it's ignorant and unhinged. People who don't follow any standards discussions, don't talk to web devs, don't read anything except headlines and who are only imitating the attitudes of whatever cynical, depressed social media bubble they fell into.

Re: CSS Grid Lanes

#69
post #37

Maybe this will be an unpopular opinion, but I really dislike the lane layout, because it is not possible to efficiently take a glance at all elements in the list, one by one. If you try to go left-to-right, you will quickly realize that at the end of each "line" it is really difficult to know where the next line starts. It is easy to accidentally start again on the same line (and inspect the same elements), or skip…

But if you don't need to systematically examine every element one-by-one, lane layouts are pretty good. Sites like Pintrest use lane layouts because their content isn't meant to by systematically examined, but rather absorbed at a glance. If your content is meant to be systematically examined, using a lane layout would be a bad UX choice. But just because lane layouts can be misused doesn't mean they're a bad layout.
Post reply on HN