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

51–60 of 237 posts

Re: CSS Grid Lanes

#51

Post by aidenn0 »

uniq7 wrote: 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…

I think it's one of those things that looks good, but is annoying to use non-superficially.

Re: CSS Grid Lanes

#52

Post by alwillis »

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

> They surprised us all when they suddenly shot to the top of interop-2025 this October

Not all of us were surprised; some of us have been watching the Safari team shipping the latest HTML and CSS features for a few years now.

Re: CSS Grid Lanes

#53

Post by al_borland »

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

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.

Re: CSS Grid Lanes

#54

Post by hansvm »

jbritton wrote: post #38

I have often thought layouts should be done by a constraint solver. Then there could be libraries that help simplify specifying a layout, which feed constraints to the solver.

I've done that for desktop apps before. You have to be careful with the effects of sub-pixel rendering and whatnot if your math is continuous, but it's a viable path that I quite like.

Re: CSS Grid Lanes

#55

Post by madeofpalk »

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

This is not all that surprising. While the Chrome team is out there evangelising things like WebPCIe or whatever, Safari's been shipping features clients actually want, like blurred backgrounds for years before anyone else.

Re: CSS Grid Lanes

#57

Post by TheCoreh »

neo_doom wrote: post #49
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

Fascinating tracker. So we started 2025 with nearly every browser under 80% and ending the year with every browser with >98% interop? That's a lot of amazing work done by a lot of teams. Incredible!

Just to clarify the meaning of the measurement, it doesn't mean they're 98% interoperable across everything, it's across the specific set of goals for 2025. (Which is still really good!)

I think they realized that shipping the features out of sync meant nobody could use them until all browsers adopted them, which took years, so now they coordinate

Re: CSS Grid Lanes

#58

Post by Sharlin »

emilbratt wrote: post #56

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.

Re: CSS Grid Lanes

#59

Post by oefrha »

I've been using Chromium's display: masonry in some internal apps since they introduced it behind a flag in Chromium 140. Looks like they just have to rename it now?

Re: CSS Grid Lanes

#60

Post by runarberg »

anonymous908213 wrote: post #28
runarberg wrote: post #23

Earlier quoted context omitted.

Most web devs get screemed at (by their peer reviewers or [preferably] static analysis tools) if they use a feature which has less then like 98% support without gracefully denigrating it, and rightfully so. But your GP is in a massive minority, if every developer would cater to 11 year old browsers we would be wasting a lot of developer time to inferior designs, with more hacks which brake the web for even more users…

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.
Post reply on HN