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

171–180 of 237 posts

Re: CSS Grid Lanes

#171

Post by pbowyer »

interstice wrote: post #157

Kinda odd they didn't call it masonry given it's already been called that forever. At least grid-lanes is reasonably self explanatory.

I'm pleased they rename it because grid-lanes opens up more than masonry layouts.

I've been waiting to be able to have a fully responsive layout (where interleave sidebar content in with the page content on small screens, but have it in a sidebar on larger screens) without using any JavaScript, and this finally makes it possible.

Demo: https://codepen.io/pbowyer/pen/raLBVaV

Previous comment: https://news.ycombinator.com/item?id=46228993

Re: CSS Grid Lanes

#172

Post by simondotau »

hu3 wrote: post #164
simondotau wrote: post #108

Earlier quoted context omitted.

The behaviour of entities that WebKit is ostensibly told to be compatible with isn't a "loosely related" topic, it's precisely on-point. It's certainly no less on-point than nebulous criticisms of Apple for assumed NIH syndrome or marketing priorities. You criticise Apple for not having a rapid release schedule; I am criticising the very notion of rapid release schedules (other than security patches). The web platfor…

How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing? The ever current adage of distortion field applies here. Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature. Apple can do no wrong to some. Whatever they do is a feature. And if they don't do, it's a feature too.

I agree that numerous companies inspire occasional weird reflexive defences from their most enthusiastic supporters. Thankfully, bad arguments have no transitive value.

Implying otherwise is itself a bad argument.

It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are instances where Safari had incomplete or broken feature implementations. But many claims of “broken sites” are really just evidence of lazy developers failing to test beyond Chrome or to implement graceful fallback. Relying on bleeding-edge Chromium features before they've been broadly adopted by browsers is, IMHO, a infatuation with novelty over durability. It's also, IMHO, a callous disregard for the open web platform in favour of The Chrome Platform. Web developers are free to do whatever they like, but it's misleading to blame browsers for the bad choices and/or laziness of some web developers.

Re: CSS Grid Lanes

#173

Post by simondotau »

troupo wrote: post #152
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…

"Google learned from Microsoft’s mistakes and follows a novel embrace, extend, and extinguish strategy by breaking the web and stomping on the bits. Who cares if it breaks as long as we go forward." https://www.quirksmode.org/blog/archives/2021/08/breaking_th...

That's a good article. Thanks for surfacing.

Re: CSS Grid Lanes

#174

Post by saagarjha »

simondotau wrote: post #172
hu3 wrote: post #164

Earlier quoted context omitted.

How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing? The ever current adage of distortion field applies here. Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature. Apple can do no wrong to some. Whatever they do is a feature. And if they don't do, it's a feature too.

I agree that numerous companies inspire occasional weird reflexive defences from their most enthusiastic supporters. Thankfully, bad arguments have no transitive value. Implying otherwise is itself a bad argument. It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are instances where Safari had incomplete or broken feature implementations. But many claims of “broken sites”…

Why do you keep conflating bug fixes with new platform features?

Re: CSS Grid Lanes

#175

Post by jrgd »

Sharlin wrote: post #76
ethmarks wrote: post #66

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.

With Masonry and using the bin packing algorithm/layout, according to your visual requirements, you can (should?) use a system for sizes for the sizing element and get different widths for the underlying columns of the ‘grid’; ie: if the sizing element is a quarter of base width, you scale down some of the widest image to bring more homogeneity-or on the contrary balance it with some enlarged elements that brings some rythm.

Edit: doc has this first example https://masonry.desandro.com/layout that you could use but have to imagine images to be twice the size, similar to a Müller Brockmann grid

Re: CSS Grid Lanes

#176

Post by simondotau »

saagarjha wrote: post #174
simondotau wrote: post #172

Earlier quoted context omitted.

I agree that numerous companies inspire occasional weird reflexive defences from their most enthusiastic supporters. Thankfully, bad arguments have no transitive value. Implying otherwise is itself a bad argument. It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are instances where Safari had incomplete or broken feature implementations. But many claims of “broken sites”…

Why do you keep conflating bug fixes with new platform features?

Because such bugs were predominantly associated with then-new platform features.

As a web developer myself, I appreciate the frustration with Safari's flexbox bugs of a decade ago and viewport bugs more recently. I also remember being endlessly frustrated by Chrome bugs too, like maddening scroll anchoring behaviours, subpixel rounding inconsistencies, and position:fixed bugs which were broken for so long than the bugs became the de-facto standard which other browsers had to implement. All browsers have bugs. To suggest that Safari was uniquely bad is to view history with Chrome-tinted glasses.

Re: CSS Grid Lanes

#177

Post by zozbot234 »

snackbroken wrote: post #121
jlaternman wrote: post #94

Earlier quoted context omitted.

I think this looks great too. Finally replicating the efficiency of newspaper layouts. No enforced symmetry, just content in an optimal space. I want.

It looks pretty, but fails at basic usability. After reading the top-left block of text titled "Optimizing Webkit & Safari for Spedometer 3.0", what the fuck am I supposed to read next? Am I meant to go recursively column by column, or try to scrutinize pixels to determine which of the blocks are further up than the others, skipping haphazardly left and right across the page? A visual aid: https://imgur.com/a/0wHMmBG…

> Columnar layout is FUNDAMENTALLY BROKEN on media that doesn't have two fixed-size axes.

You can use plain old CSS columns (which don't have the automated "masonry" packing behavior of this new Grid layout, they just display content sequentially) and scroll them horizontally. But horizontal scrolling is cumbersome with most input devices, so this new "packed" columnar layout is a good way of coping with the awkwardness of vertical scrolled fixed-width lanes.

Re: CSS Grid Lanes

#178

Post by nextaccountic »

culi wrote: post #144
hoten wrote: post #102

Earlier quoted context omitted.

I wonder if Ladybird has explored running these interop tests yet. Or maybe these are just a subset of WPT?

Here's a comparison including the big 3, ladybird, servo, and flow https://wpt.fyi/results/?label=master&product=chrome&product... To answer your question, yes. Apple requires 80% test passage of all the tests on web-platforms-test in order to be considered as a valid browser for iOS so they specifically targeted this suite to reach that milestone It's a pretty silly requirement because wpt is not really meant to be…

I thought that no other browser engine could be provided on iOS. so no ladybird's engine, no servo, no gecko, no blink, only webkit

Re: CSS Grid Lanes

#179

Post by crazygringo »

anonymous908213 wrote: post #67
runarberg wrote: post #60

Earlier quoted context omitted.

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

Can you link to the source for your stats?

I'm not finding anything to corroborate that -- I'm seeing stats suggesting things like 90% of Chrome users are on the newest version after two weeks:

https://timotijhof.net/posts/2023/browser-adoption/

And Stat Counter shows that the current version of Chrome utterly dominates in any given month:

https://gs.statcounter.com/browser-version-market-share/desk...

The glacial adoption you're describing doesn't make much sense when you consider how aggressively Chrome auto-updates, so I'm quite confused.

Re: CSS Grid Lanes

#180

Post by concinds »

simondotau wrote: post #172
hu3 wrote: post #164

Earlier quoted context omitted.

How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing? The ever current adage of distortion field applies here. Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature. Apple can do no wrong to some. Whatever they do is a feature. And if they don't do, it's a feature too.

I agree that numerous companies inspire occasional weird reflexive defences from their most enthusiastic supporters. Thankfully, bad arguments have no transitive value. Implying otherwise is itself a bad argument. It is true that Safari sometimes lagged in ways that are legitimately open to criticism. There are instances where Safari had incomplete or broken feature implementations. But many claims of “broken sites”…

> But many claims of “broken sites” are really just evidence of lazy developers failing to test beyond Chrome or to implement graceful fallback.

Correct. People test Chrome first and often only. That'll never change because people are lazy and you have a humongously long tail of websites with varying levels of giving a shit and no central authority that can enforce any standards. Even if another browser takes other, they'll only test that one.

The solution is formal tests and the wpt.fyi project. It gives a path to perfectly compatible implementations of agreed-upon standards, and a future where *the only* differences between browsers will be deliberate (e.g. WebMIDI). Brilliant.

That's why I wish the gap between Safari TP's wpt.fyi score and Safari stable's score was shorter. Simple!

Post reply on HN