There is an element of tragic comedy to those announcement. While remarkable on their own, everybody knows that one cannot use any new browser feature reliably any time soon due to Apple not shipping continuous updates to the browsers they force upon their users.
CSS Grid Lanes
161–170 of 237 posts
Re: CSS Grid Lanes
#162I 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.
iOS used to do this using the Cassowary constraint solver pre-SwiftUI. It’s the worst thing to work with. So much code turning on and off constraints, dynamically adding constraints when you have new views. And that’s before you get into conflicts
Re: CSS Grid Lanes
#163Props 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
Safari became the new IE for a while, the amount of problems I've had with Safari CSS animations and SVGs is endless. It's good they're trying to not make Safari suck as much.
Safari is still the new IE. Well, not really "new", it has been IE all along. It's the only non-evergreen browser that remains, and I don't get why this isn't mentioned every time Safari is brought up. All of their spec implementations are meaningless when the only version that matters is the one forever stuck in whichever oldest iPhone n% of people still use.
Caniuse is pointless, their new "baseline" score is pointless; as long as enough people keep using their (perfectly fine and working) iPhones after official support stops and as long as they are not allowed to install a different browser (engine), that's the only data point you need to look at when choosing which browser features to use.
Re: CSS Grid Lanes
#164Earlier quoted context omitted.
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".
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.
Re: CSS Grid Lanes
#165That makes sense.
Safari is so smooth now in iOS. Moved from Firefox.
Re: CSS Grid Lanes
#166There is an element of tragic comedy to those announcement. While remarkable on their own, everybody knows that one cannot use any new browser feature reliably any time soon due to Apple not shipping continuous updates to the browsers they force upon their users.
iOS from 2 versions prior don't get latest Safari?
I can't check because my wife's iPhone is, regrettably according to her, "updated to the latest glAss version".
Re: CSS Grid Lanes
#167Earlier 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…
[deleted]
Re: CSS Grid Lanes
#168I wish they'd release CSS Gap Decorations: https://developer.chrome.com/blog/gap-decorations I'm tired of having to use stupid hacks to get nice-looking borders between flex/grid items.
Have you considered using tables? It is funny how we keep asking more and more and more even though we already have it so much better than before. Can we never be happy with what we have?
How would tables solve the issue they're talking about?
Re: CSS Grid Lanes
#169Earlier quoted context omitted.
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/…
How is that better? It's still a grid of images that seem to be constrained to a more or less rectangular grid. I'm thinking more of a dynamic grid where there is a mix of sizes of horizontal and vertical images.
The point being raised is that dynamic image grids don't actually make for a good UX. They might look more visually interesting at a superficial glance, but when you're actually using the interface to browse images, predictability wins out. Even having mixed-orientation images, where there is some degree of extra whitespace between images, does not change this. It is way easier to digest the content when your eyes can reliably scan one line at a time without having to bounce around everywhere to track the flow of the dynamic grid.
Re: CSS Grid Lanes
#170Earlier 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…
> 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". There's a new version of Safari Technology Preview [1] for macOS every two weeks. There's a new version of Safari released every September for macOS, iOS, iPadOS, an…
The Safari/WebKit people are doing good work, yes.
I use Safari as my default, and like every Firefox/Safari user I still get some bugs that don't occur in Chrome (not talking about WebMIDI obviously), so watching that 30 point gap between stable Safari and bleeding-edge WebKit (longer than 7½ weeks) on wpt.fyi was quite frustrating. The average Safari user would have a better browsing experience with a shorter fix delay, that's just the truth. Having to wait for macOS updates holds back the browser, unnecessarily.