I didn't realize it was tracked like this, but I have noticed that as of iOS 26, Safari has gotten a huge number of great web features. It has WebGPU of course, but many small things like fixing up missing parts of the OPFS API that make it actually usable now. Now they even have the field-sizing CSS property [0], fixing imo the most glaring ommission from CSS: the inability to make text input boxes grow to fit the input text!
`contenteditable` is an HTML attribute but it depends on JavaScript to do anything useful. This problem is one of layout, CSS's domain, so `field-sizing` solves it while leaving HTML form elements to do the actual job of taking input.
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".
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 doing is a variant of “embrace and extend”. Traditionally, this meant proprietary extensions (e.g. VBScript) but I think this a subtle variant with similar consequences.
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).
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.
> 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!
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.
You are assuming that Safari didn’t fix bugs for a long time because it “ships slowly.” Maybe some bugs are just complicated and take time to fix. It took Google years to fix the bugs I mentioned earlier (and many others) despite having the largest budget of any browser project and a VERY rapid release cadence.
No a lot of them are pretty straightforward, this is why I’m upset. I’m talking about, like, “SVGs with this feature don’t render correctly due to an oversight in size calculation” not “can you please implement WebGPU in the next release cycle”.
> How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing?
That hasn't been true for a few years now.
Even now, when a site breaks in Safari, more often than not, it's because that particular site is using a Chrome-only feature that hasn't shipped in Safari or Firefox yet. These developers need to be reminded that progressive enhancement is a thing.
There are web developers who only test their sites on Chrome, which makes no sense, given mobile Safari has around 50% marketshare in the US [1] and about 21% globally [2].
> Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature.
I must have missed this one, but anyone paying attention would have noticed WebGPU had been available in Safari (behind a flag) long before it became official; it was always on track to becoming a real feature.
"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...
VBScript is a word I hadn't heard in quite a while! Brings back memories of editing 5k line .asp files to find an if statement and then a 1000 lines of html and such. Sadly, I dont' think web development is actual better 20+ years later, just different...
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.
> 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, and visionOS. This has been the schedule for several years. Since Safari 26 shipped on September 15, 2025, there have been two updates for these platforms:
Safari 26.1 on November 3rd and 26.2 on December 12th.
The Safari team shipped 7 releases this year, averaging 7½ weeks between releases; not a significant difference from 4–6 weeks. Each major release of Safari for macOS runs on the current macOS version (Tahoe) and the two preceding ones—Sequoia and Sonoma.
BTW, there were 9 Safari releases in 2024, averaging 5.8 weeks apart.
It's not the first time Safari shipped a significant new feature before other browsers; :has(), Display P3 color support, JPEG-XL come to mind.
At the end of the day, there's no NIH or Marketing team dictating the release schedule.
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.
> Having to wait for macOS updates holds back the browser, unnecessarily.
Safari is an operating system component, which lots of people don't seem to understand; hundreds of thousands of 3rd party apps rely on Safari's WebKit engine.
I've never heard a normie Safari user complain that Safari updates aren't being released quickly enough; that's something web and app developers care about… which is why Safari Technical Preview is released every two weeks.
Even the release versions of Safari on iOS, iPadOS and macOS allow you to enable web features that are still in development.
Safari has been releasing a lot more often than it used to. My personal gripe with Safari is how they decided to deal with extensions, forcing every developer through their hellish App Store submission experience.
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.
Imagine if the literal army of Chromium/Blink engineers threw their entire weight into making the fundamental building blocks that everybody uses better instead of niche things that only a tiny fraction sites and web apps will ever need.
Hm, I know that Safari doesn't support 64bit wasm, which is a very important feature that Chrome and Firefox both have, but this seems to say they have "100% webassembly support".
interop is a subset of tests chosen beforehand (nowadays, mostly by devs voting in the github issues). This says Safari has reached 100% on the subset of tests agreed upon for interop-25. Those specific tests can be expanded by clicking it in the menu. It'll take you here:
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
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.
it's also not possible for Safari to be the new IE because they don't have 95% marketshare. And IE's unique problem was that they pushed features that only they supported. Safari's problem is it doesn't support certain features
Also the thing is that there are plenty of features supported by Safari and Firefox that Chrome is slacking on. Nobody every complains about those features though because nobody would try to use a feature not supported by Chrome in the first place
> The only people who think Safari is the new IE are people who weren’t around for IE.
Absolutely true! I've said the same thing many times myself.
Stating that Safari is the new IE is one of the answers to:
"Tell me you didn't do web development in '90s and have no idea what you're talking about without telling me you didn't do web development in '90s and have no idea what you're talking about."
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 representative of all web platform standards. It includes tests for non-standard features and the majority of tests are simple unicode glyph rendering tests.
that was true until a few months ago due to a ruling in the EU. It's still currently the case that only WebKit can run on iOS but they're gearing up to change that
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?
> It is funny how we keep asking more and more and more even though we already have it so much better than before.
I've been developing web stuff for 15 years now and sometimes I can't believe comments like these. We didn't have it "so much better before". CSS sucked hard and getting things right for three devices was an incredible pain in the ass.
Tables have semantic meaning. They don't support fractional units. Reflowing for mobile is impossible and you need JS hacks like splitting tables. You can't reorder natively.
I have been developing web stuff for 20 years now and I also can’t believe comments like these.
Flex and grid enable layouts that are far beyond anything we could do with table layouts. Anyone who claims otherwise has obviously not done any amount of serious, production FE UI design and development.
Are there bits of DX ergonomics I’d like in flex and grid? Of course. Does the syntax sometimes feel a bit arcane? Yeah. But the raw power is there, and anyone who claims the contrary is either a gormless backend developer, or some troll who is trying to design things in MS Word.
Borders can be applied to table cells independent of the content inside cells.
Gap decorations allow you to add borders between flex/grid items, but without the woes of dealing with table quirks and behavior.
Common use cases would include mimicking design patterns found in print layouts, particularly newspapers and menus, to help divide groups of items or info.
This is exciting to see! I just used Masonry for a project this past week. While it works quite well and is pretty performant, it is pretty hacky using absolute positioning, wanting to know the aspect ratios of objects beforehand for smoother layout, and having to recalculate everything on resize. I'm looking forward to having a generally available native option one of these days.
Me, too. I like masonry layout too much to wait for CSS to solve the problem, so I've been waiting to remove the last 1.3KB of Javascript from my home page since 2019.
Adding a new element still need dimension of the element and a bit JavaScript.(The whole page use < 100loc unobfuscated JavaScript) But resizing can be handled by css naturally.
I think the issue here is most people don't really have a good way to specify how masonry should work. And thus don't have a good implementation either.
There is ways of create a basic masonery layouts using only pure CSS grid. But dependes on the use case.
Take this example where are mixed cards without images, only text, and with images plus text.
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.
I know one of my clients complained something didnt work on their few year old iPad. So.. I don't know what the cutoff is but clearly not everything updates regularly. He did try updating it manually too but couldn't.
A lot of web "design" is about how it looks rather than how usable it is. At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl". Never mind the text that is at 50% opacity until you scroll to the exact intended point, because nobody actually attempted to read it.
> At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl".
Actually that's exactly what they do. They like the animations while some people, especially devs, do not. But they don't use it multiple times, because they would be able to see how it gets annoying after the first time.
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?
I dont know what would be the best way, but I personally want each image to be represented correctly in relation to all other image. This means that the way images are laid out will looked jagged. However, as a consequence of that, it is easy to find back to a specific image. Its like when you are coding, you look at the "shape" of the code when scrolling to find that specific function definition etc..
Here is an example of the layout of a photostream that I was satisfied with.
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.
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 majority of the content in some images.
- If you display all images at their natural aspect ratio and their full size, there will be huge swathes of empty space in between them because they don't pack tightly.
Masonry layouts allow you to preserve aspect ratio without wasting a massive portion of your user's screen space. It's not perfect, but it's the best layout mixed-orientation content that I know of.
If you know of a better method to handle mixed orientations, I'd love to hear it and would gladly rescind by remarks.
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)
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.
What is it with commenters in this thread and wanting to "reliably scan one line at a time?" When users use image galleries, they generally do jump around because they're looking at all the options on screen all at once. The eyes absorb everything and then they pinpoint what looks good. I've never seen or heard anyone go line by line in an image gallery or a newspaper layout and doing so I'd find to be highly abnormal to average users.
I suspect if data from eye-tracking tests were available, there would be an extremely clear revealed preference from users. I read image galleries the exact same way I skim text, in an ordered fashion that allows me to "read" every image without reading an image twice, stopping if my attention is caught by something in particular. Splotting garbage over the screen haphazardly makes it blend together annoyingly and results in my eyes traversing the same areas multiple times both to try to pick out details and to try to keep my place in what I have/haven't skimmed yet. It is a layout that itself demands my attention, rather than letting my attention be absorbed naturally by the actual images.
From actual eye tracking data via Hotjar and similar, people do skip around the page. Those that scan linearly are in the minority but probably are more highly represented on HN, just as a matter of course.
Well I think this is a great step forward but it would be great if we could mix aspect ratios even better...
Consider a similar layout to OP but the landscape images will span multiple columns as well as everything it already does.
The thing about masonry is that it adapts to the size of the images. You could already do masonry using flexbox if you know the image sizes (https://github.com/hannasm/masonflexjs). Doing it as a true mosaic layout would be a step above current capabilities. At that point it's probably pretty easy to create configurations that don't fit perfectly/ require lots of empty space to layout nicely though.
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
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 one accidentally. Then navigating through the elements one by one requires a considerable amount of cognitive effort, your eyes bounce up and down constantly, and you end up inspecting the same elements multiple times.
If you try to go top-to-bottom, lane by lane, you will then realize that the page also has infinite scroll and you will never go past the first lane.
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.
IMO it's annoying to use at all. It just looks "good" (subjective).
Larger images dominate and flashy images become more important to get attention (if bringing focus to an image is the idea). An extremely poor way to present information.
It's not meant to be "efficient," it's meant to allow your eyes to look at the entire page at once to find what you're looking for. A newspaper or photo gallery comes to mind.
(Not GP poster.) I don't really have a problem with masonry layouts, but a newspaper is limited by the paper size and they have incentive to squeeze everything in there (to maximize the spread of "information"). The screen is theoretically infinite (although not for kiosks).
I do have a website with a lot of images, and at the moment everything is in a 3-across grid layout...
The screen is infinite but information should still be prioritized, that is why newspapers use different sizes of headings. If they truly wanted to jam everything in there, they'd use the same small font size and save on paper, but that's not what people like because they want to see at a glance what is important and what's not, and that's done by the font size initially. This is no different on an infinite screen, the design principle of information prioritization still holds.
TLDR: in the user's eyes, a newspaper and this sort of layout are not very different, if the average user can navigate the former for hundreds of years, they can navigate the latter.
Ok, but the fact of the matter is that a digital display rendering a webpage and a physical format of a newspaper are fundamentally different media and should be treated as such. A wall of text isn't fundamentally a bad thing, but on a display monitor (or god help you, a cellphone or tablet) that's a terrible user experience.
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.
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. Web layouts leave one axis free to expand as far as necessary to fit the content, so there is no sane algorithm for laying out arbitrary content this way. Either you end up with items ordered confusingly, or you end up having to scroll up and down repeatedly across the whole damn page, which can be arbitrarily long. Either option is terrible. Don't even get me started on how poorly this interacts with "infinite scroll".
Well not all content is meant to be read in order. A layout like this is good for content where you want to incentivise users to read in whichever order you like. So if the order is confusing you, chances are there wasn't meant to be any order at all. E.g. if you search google images google guesses some relevant order for you, but it is layed out in a dense way so you can scan with your eyes and decide which thing is most relevant for you. Whether you scan the screen left-right, top-down, randomly, bottom up, or ehatever is totally your choice.
Using such a layout for a novel or something like this would be really bad UX. But using it for an image gallery? Or a series of random articles that aren't priorized? Why not?
> 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.
What a weird comment. You read whatever you want next, ever read a newspaper? You scan it all and pick the article you are interested in, then read that. I don't understand these comments, they work perfectly well in real life (and fixed size is arbitrary, I can make a super wide or super long newspaper too, the axis size does not affect this sort of layout, see infinite scroll for example, as there is only a fixed amount of content on the screen at any given time).
> You scan it all and pick the article you are interested in
Okay. What order am I supposed to scan in so I don't lose my place and accidentally skip a block? Scanning column by column gets me cut off partial boxes that I'll have to remember to check again later, while scanning side to side forces me to keep track of each individual block I've already looked at, as opposed to a single pointer to "this is how far I've scanned". Alternatively, I can scan roughly left to right, top to bottom and just live with missing some blocks. That's not ideal either, because hopefully if you didn't think I'd like to look at all of them you wouldn't have included them on the page.
You're right that you can make a newspaper that's really inconvenient to read, but you wouldn't, because the failure case you'd end up with is CSS Grid Lanes.
This is so funny that I'm not even sure what to say. You can ask your exact questions about a newspaper but somehow 99% of people manage to read them just fine. I think it's just a you problem that you are looking for an exact algorithm on how to scan a page with multiple sizes of content; in reality, people just look over it all and keep track of what they have or haven't looked at all in their heads.
In a newspaper the answer is simple. You linearly scan the leftmost column to the bottom of the page, then the next column, then the next, and so on until you get to the end of the page. At no point do you ever need to keep track of anything other than "this is how far I've gotten" to make sure you haven't missed anything. Columnar layout make sense in newspapers because both axes are fixed in size, so all you ever do is one long linear scan with wraparound.
If one axis is fixed, and it is in the case of grid lanes (it's not a fully pannable infinite canvas like Figma after all), you just keep reading the content that's on the current screen, then you scroll. I really don't see how it's any different to, for example as I mentioned previously, a long newspaper with many pages; each "page" is one "screen" worth, analogously. It's like infinite scroll, either vertically or horizontally, where instead of just one item in the list, you have a few. And if we're being really pedantic, Figma users do perfectly fine keeping the context of the content in their minds even in an infinitely pannable canvas. And also, generally newspaper readers do not do what you say, scanning column by column, they instead glance their eyes over all of the headlines then pick which one looks good then they read the article attached to that, it is a free form process.
So again, I will contend that this is not a problem for the average reader. I really cannot see where the difficulty you seem to say lies.
Yeah, there was a years long debate that effectively ended with: “We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.”
> We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.
I think that’s an exceptionally uncharitable description of what happened. This is a decision the WebKit team has been repeatedly publicly asking people to participate in for over 18 months.
> Help us invent CSS Grid Level 3, aka “Masonry” layout
> P.S. About the name
> It’s likely masonry is not the best name for this new value. […] The CSSWG is debating this name in [this issue]. If you have ideas or preferences for a name, please join that discussion.
> Help us choose the final syntax for Masonry in CSS
> We also believe that the value masonry should be renamed.
> As described in our previous article, “masonry” is not an ideal name, since it represents a metaphor, and not a direct description of its purpose. It’s also not a universally used name for this kind of layout. Many developers call it “waterfall layout” instead, which is also a metaphor.
> Many of you have made suggestions for a better name. Two have stood out, collapse and pack as in — grid-template-rows: collapse or grid-template-rows: pack. Which do you like better? Or do you have another suggestion? Comment on [this issue] specifically about a new value name (for the Just Use grid option).
The debates went on for years and following it closely became a poor use of time. Even the subgrid conversation seemed completely stalled. I think a lot of people tuned out long before any vote was discussed. I did.
But if you were the one who tuned out, then isn’t it uncharitable to describe it as their failing to make you aware of the vote? Isn’t it on you to stay in the loop?
Surely they can’t start just pinging everyone who might have cared at some point during the time to get involved.
I get what you're saying but making interminable arguments and keeping the "debate" going is a tactic. There's that CIA sabotage manual with the section about meetings and conferences, it can feel like that. The duration of these debates aren't usually measured in hours, days, or weeks, but years. And the people who dragging them on and staying in the fights are employed full-time to do exactly that.
It got to the point where I believed that subgrid was dead. FF implemented it but absolutely no one else did, for years.
Is it our fault for tuning out of the debate? Yep. But tactics were employed to achieve that exact outcome. I'm fine admitting that I tuned out. But it was a battle of attrition waged by people who were fine holding up progress indefinitely.
Is that how you want decisions to be made?
Ultimately I'm not too concerned what you call the masonry feature. However the debate over what to call it was an extreme case of bikeshedding. I would have rather given up the fight over semantics to resolve the non-issues and ship the feature years ago. As it stands we're still years away from actually being able to use the feature in production.
I've stopped waiting for companies, committees, or projects to change course. I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist. Why bother? I have an incentive to spend my time building features that users will use.
There’s no incentive to the companies or the employees to draw out the discussion, especially over something so trivial. It’s much more preferable to try and speed through things to get things done in a time frame that can be adopted.
And regardless, if you don’t feel it’s worth your time, then why cast aspersions that it was something clandestine and intentionally hidden? You could have shown up and kept up with it, just like everyone else involved presumably did.
I didn’t ascribe a motive to anyone. Their reasons are their own and it only makes sense that the people who stay in these fights do it because it’s part of their jobs.
There are people who, for whatever reason, keep debates going over small points of disagreement and prevent issues from being settled. Sometimes for years. Right?
The older I get, the more likely I am to recognize and route around or ignore interminable debates. Especially if it’s not for a company, project, or initiative under my direct control.
Remember, the question at the top of this thread was essentially “What happened to ‘masonry’?” Well, there were quibbles over the descriptors.
I don’t care about quibbles. “masonry”, “grid-lanes”, “grid-masonry”, pick one, they’re equivalent. I don’t like it when quibbles block progress.
Sometimes people and companies do want to block things. You’d have to ask them why. Like I said earlier:
> I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist.
Pick your battles… Actually, no, it’s usually better to ignore the fights and just get what you need to get done so you can move on.
Masonry was never “in”, no? Mozilla proposed it and were the only ones to implement it, behind a feature flag. Then WebKit proposed an alternative that was discussed at length:
People have been dragging their feet on subgrid, masonry, etc for almost a decade. I followed it pretty closely for years but stopped when it started turning into a Christopher Guest mockumentary.
Masonry or grid-lanes, who cares? I’m just glad masonry (the feature, Baseline 20XX) and subgrid (Baseline 2023) are finally here.
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 more masonry than the grid-template-rows:masonry setting. yeah yeah, raw css vs js library blah blah
One hack to almost get a justified gallery like that with no javascript is to lay them out with flexbox, setting their width to a percentage or vw value which your backend calculates based on image aspect ratio and desired image height, use flex-grow to stretch them to fill remaining space, and then using background-position: cover to make the images fit the slightly wrong aspect ratio containers.
This will of course slightly crop all your images to make it fit, but in practice as long as you keep your image aspect ratios reasonable and the images small enough on the page it's really quite subtle.
I had hoped that this feature would provide for masonry like that, but one has to make do.
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.
Don't use continuous math in either a design system nor a constraint solver that you expect random developers to use. Either case will only lead to problems.
I largely agree, but there's a little nuance insofar as "interior-point" methods are very powerful. You can go a long way by encoding your goals as error functions and letting a gradient-based optimizer do the rest.
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
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.
The naming was half the discussion on implementing this. There were a lot of people smarter and more knowledgeable than me that had a lot of opinions on the name that I hadn't thought about. I remember one of the reasons was that the word "masonry" wasn't as obvious a concept for non-English speakers.
Masonry grid layout was one of a few interviewing pair programming tests I would give to frontend engineers. I need to see how this works under the hood!
I have to ask, like with all the other browser specific trial implementations: how is cross platform support? If we wanted to make a grid layout that only worked in one browser engine, grid-template-rows: masonry was there for a while now.
Chromium still seems to be working on support it seems based on https://cr-status.appspot.com/feature/5149560434589696 so maybe it'll be useful soon? That page indicates that they're still discussing certain parts of the spec.
It's been on-and-off in all three browsers behind flags etc, but it's been in a constant state of flux over the last three years. One of the most gnarly new CSS features to get right. Lots of great arguments about how to implement it.
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?
I have too. And the Safari version that was in the betas/tech previews.
One of the biggest arguments over the last couple of years was what to call it. A lot, lot of ideas put forth as alternatives to "masonry" which wasn't thought to be great for non-English speakers. I'm glad they finally nailed a name for it!
The other big argument was over how to activate it. Is it a grid? Is it a flexbox? Is it a brand new animal?
Now I just need to figure out the best way to implement this semantically with a polyfill for the next 30 months until it's baseline.
I actually started using Safari's `grid-template-rows: masonry` when it came out, but unfortunately Safari TP crashed a lot on me when using that for some reason. Chromium's never had a problem.
I guess wire up a codepen demo and try it out. I know the guys writing this were well aware of all the edge cases like that and these are some of the absolute smartest CSS people you can think of who had to write the very detailed spec for this.
I don't think the smooth reflow made it into the current spec, so I guess watch this space?
I like Josh W Comeau's content, he has a lot of free articles, but his paid CSS course goes through step by step why CSS is the way that it is, worked great for me for understanding it all. My work paid for it though, that's why it's priced so high, but I'm sure he has discounts for individuals.
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.
Aahh. The way you phrased your question was pretty ambiguous.
The other posters have good answers. One thing to consider for a smooth interaction would be to eagerly load the next x elements before they scroll into view.
Yeah I’d assume you’d eagerly load enough to make sure everything gets at least partially into the viewport, and maybe a fee more to optimize for network latency. And then perhaps track elements whose trailing ends are not in the viewport, and load more once those become fully visible?
It’s always nice to see native implementations of functionality pioneered by third-party libraries. Bootstrap, for example, has made this kind layout (somewhat) possible but there is also a Masonry plugin that simplifies it.
It seems that support tracking websites don't know what this is yet. MDN briefly notes it as an option for `display` but there is no other mention of it.
They mentioned tabbing and screen readers quite a few times.
I found the "jumping" ordering quite concerning but further down in the article they mention "tolerance" that seems to be a way to allow the layout to be more consistent in terms of ordering.
Is anyone working on actual css problems instead of this sugar syntax?
Hypermedia suffers because these marketing companies waste time on making sure they can build Pinterest in 10 LoC instead of fixing actual long running hypermedia domains.
Moving this sort of stuff out of JavaScript and arcane hacks allows the browser rendering engines to optimize these common patterns. This is sorta the opposite of syntactic sugar. The syntactic sugar is the libraries that implemented these patterns without rendering support.
Shall we call it syntactic umami perhaps? Or syntactic lipids?
There is no winning, is there? Half of HN wants browsers to revert to document readers and the other half wants HTML and CSS to do what JS can. A small minority then insists that we should get rid of HTML and CSS entirely and start from scratch. The louder the ideas the further away the person is from actually using the tech. I personally would not have the patience for community management.
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.
> HTML has become more and more bloated. How many methods do we need to do something that was possible back in the 90s?
This is incorrect. Lots of old stuff was removed or deprecated from the HTML5 specification; elements like `s`, `u` were repurposed from being presentational to semantic:
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.
Psh, rocket science only has to contend with physics, which generally doesn't change much, if at all. The equations used to get humans to the moon didn't change because someone discovered you can send a specially crafted packet and escape the sandbox and steal money from everybody on the Internet.
Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).
Personally, I use an 11-year-old machine and have had to add userscript hacks to certain major Web sites to work around bugs in CSS grid (not the "lanes" described here).
At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too? But they seem not to.
For example, the demo page linked in the article fails pretty unusably for me. All the images take up nearly the full viewport width.
What OS are you running that can't run modern versions of browsers, and on what hardware?
Current Chrome runs on Windows 10, which came out 9.5 years ago but was intended to run on older computers, and macOS Monterey, which runs on Macs from ~2014-2015 depending on the model. But even Big Sur before that, the most recent version of Chrome which runs on that is Chrome 138 from just 6 months ago, and that doesn't seem old enough that you need to build userscript hacks.
I'm really curious what you're actually running. Generally speaking, an 11-year-old desktop should be able to run the current browser, and if not, a very recent one.
> Personally, I use an 11-year-old machine and have had to add userscript hacks to certain major Web sites to work around bugs in CSS grid (not the "lanes" described here).
The version of CSS Grid we're using today didn't ship until 2017; a browser from 11 years ago would be using one of the non-standard versions of Grid. For example, Internet Explorer 11 was the first browser to ship a grid implementation.
> At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too?
First, not every site needs to look exactly the same in every browser; that's why progressive enhancement is a thing.
Second, there are multiple ways to create masonry-style layouts that don't require masonry support in the browser using multi-column layout or flexbox.
Third, masonry can be polyfilled using JavaScript [1].
When the web came out it itself was new technology that excluded some older machines. Lynx kind of worked (I used it!) but it was a poor substitute, especially once `<img>` showed up.
You want to platform to be able to make progress and not be frozen in amber by what we had at some "magical" year when things were in some Golidlocks powerful enough but not too complex state. Especially since a lot of progress lately has been fixing long-standing inconsistencies and obvious gaps.
The cost of that is that yes, neither my Apple IIe or my Micro Pentium 90 run the modern web... one day my MBP M1 won't either.
Not updating your browser will net you tons of exploitable vulnerabilities.
How do you expect things to ever change if no one ever updates? Certainly even if you decide to lean towards maximum support it’s still a positive these features are being introduced so you can use them in 10 years.
> How do you expect things to ever change if no one ever updates?
Maybe things should stop changing.
We don't really need ten new CSS attributes every year. Things work. The elegant solution is to announce the project is done. That would bring some much-needed stability. Then we can focus on keeping things working.
The issue with this is that the browser is the cross-playing operating system, the VM that runs webapps. But we treat the platform like an evolving document format. If we want to declare it complete, we need to make it extensible so we can have a stable core without freezing capabilities. I foresee all of this CSS/HTML stuff as eventually being declared a sort of legacy format and adding a standard way to ship pluggable rendering engines/language runtimes. WASM is one step in that direction. There are custom rendering/layout engines now, but they basically have to render to canvas and lose a lot of performance and platform integration. Proper official support for such engines with hooks into accessibility features and the like could close that gap. Of course, then you have every website shipping a while OS userland for every pageload, kinda like containers on servers, but that overhead could probably be mitigated with some caching of tagged dependencies. Then you have unscrupulous types who might use load timings to detect cache state for user profiling... I'm sure there's a better solution for that than just disabling cross-site caching...
> I foresee all of this CSS/HTML stuff as eventually being declared a sort of legacy format and adding a standard way to ship pluggable rendering engines/language runtimes.
I doubt this is going to happen as long as backwards compatibility continues to be W3C's north star. That's why all current browsers can still render the first website created by TBL in 1989.
Sure, official support for certain extensions should happen but HTML/CSS will always be at the core.
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.
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 development in its tracks.
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%"
There are two kinds of technologies: those that change to meet user needs, and those that have decided to start dying and being replaced by technologies that change to meet user needs.
> Is this increasing complexity in the Web layout world worth it?
Yes. I held off learning about CSS Grid for a very long time and as soon as I did I was converted. Sometimes I think the web doesn’t get enough credit for its ambition: mobile viewports, desktop viewports, touch interaction, pointer interaction, complex documents, webapps… it’s a lot. But you get some complexity as a side effect. The complexity we do see these days isn’t invented out of whole cloth, it’s standardising and improving layouts people are implementing with JavaScript, often badly.
> Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).
If you’ve been at this for a while, it’s important to remember that browsers update a lot faster than they used to. Anchor positioning came out last year, for example, and all of the major browsers support it by now. Very old devices are a problem but security is purging those out faster than used to be the case.
We also have better tools for progressive adoption since you can easily query for things like CSS feature support. In this demo, they didn’t implement fallbacks but in most real sites you’d have something like a basic grid layout which is perfectly serviceable for the fraction of users on old Firefox releases.
Sooner or later, the age of your machine will affect browser compatibility.
It doesn't even take many things to do this — the knock-on support of a bug in a driver that no-one wants to fix, a package that you like that prevents you from upgrading your host OS, web browser developers abandoning something about your GUI (how long before they drop X?) etc.
In the Linux world, the age of your machine is a limit with a blurry edge, but it's still there.
Yes it is. Developers write bad code when they try to work around the lack of features with ill thought out hacks, this results in a bad website for everybody, even those of us that keep our software up to date, and just so happen to have a different screen resolution and a different browser then what the developer tested on.
If enough consumers aren't able to use the website, then business wouldn't use it. The reality is new computers aren't that expensive (I see used M1s for under 1k) and consumers are upgrading.
You mentioned a used model that is over 5 years old as an example of "a new computer", and "1k" as "not expensive for consumers". It is honestly impressive how well you undermined your own point.
> If enough consumers aren't able to use the website, then business wouldn't use it.
I sincerely doubt any business owner would approve of losing even 10% of their potential users/customers if they knew that was the trade-off for their web developer choosing to use this feature, but there are disconnects in communication about these kinds of things -- if the web developer even knows about compatibility issues themselves, which you would expect from any competent web developer, but there are a whole lot of incompetent web developers in the wild who won't even think about things like this.
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 developers fall into the competent or incompetent bucket, but regardless of which there are more of, there are a significant enough number of incompetent ones.
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.
Note that the comma in browserlist queries are OR. So if any given browser version still has > 0.2% usage, it is included. This would include Chrome 109 which is three year old. Meaning developers with this browswerlist target would fail their static analysis / peer review (actually even a more reasonable > 0.5% still fails on Chrome 109) if they used a feature which Chrome 109 doesn’t support without graceful degradation or polyfill.
Furthermore the "baseline widely available" target (which IMO is a much better target and will probably become the recommendation pretty soon) includes versions of the popular browsers going back 30 months, meaning a competent team of web devs with a qualified QA process should not deliver software which won‘t work on your 2 year old browser.
I can‘t speak for the developers of the websites which break on your 2 year old browser... Maybe they don‘t have a good QA process. Or maybe you were visiting somebodies hobby project (personally I only target "baseline newly available" in my own hobby projects; as I am coding mostly for my own amusement). But I think it is a reasonable assumption that user tend to update their browsers every 30 months, and you won‘t loose too many customers if you occasionally brake things for the users which don’t.
I was specifically referencing desktop Chrome, not including Chrome for Android, but other than that, if there are discrepancies, I'm not sure what the cause is.
The Timo Tijhof data is based on Wikipedia visits, and shouldn't be affected by adblockers.
Meanwhile, StatCounter is based on sites that use its analytics, and on users not using adblockers that might block it. The CanIUse table makes clear there's a long tail of outdated Chrome versions that each individually have tiny usage, but they seem to add up.
It's fascinating they're so wildly different. I'm inclined to think Wikipedia, being the #9 site on the web [1], is going to produce a more accurate distribution of users overall. I can't help but wonder if StatCounter is used by a ton of relatively low-traffic sites, and the long tail of outdated Chrome is actually headless Chrome crawlers, and so they make up a large proportion relative to actual user traffic? Since they're not pushed to update, the way consumers are. And especially with ad-blocking real users excluded too?
Anecdotally, in web development I just haven't seen users complain about sites not working in Chrome, where it turns out the culprit is outdated Chrome. In contrast to complaints about e.g. not working in Firefox, which happen all the time. Or where it breaks in Chrome but it turns out it's an extension interfering.
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 didn't realize it was tracked like this, but I have noticed that as of iOS 26, Safari has gotten a huge number of great web features. It has WebGPU of course, but many small things like fixing up missing parts of the OPFS API that make it actually usable now. Now they even have the field-sizing CSS property [0], fixing imo the most glaring ommission from CSS: the inability to make text input boxes grow to fit the input text!
[0]: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/P...
I thought that was supposed to be fixed by contenteditable plaintext-only. Why was field sizing still necessary?
`contenteditable` is an HTML attribute but it depends on JavaScript to do anything useful. This problem is one of layout, CSS's domain, so `field-sizing` solves it while leaving HTML form elements to do the actual job of taking input.
At least recreate their demo for us to showcase the fix. But I feel like it would be a let down that answers your question.
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.
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 doing is a variant of “embrace and extend”. Traditionally, this meant proprietary extensions (e.g. VBScript) but I think this a subtle variant with similar consequences.
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 platform doesn't need to move so fast.
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.
> 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!
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.
I'm not saying that other browsers don't have bugs. This thread is about how Safari doesn't fix them for a long time because it ships slowly.
You are assuming that Safari didn’t fix bugs for a long time because it “ships slowly.” Maybe some bugs are just complicated and take time to fix. It took Google years to fix the bugs I mentioned earlier (and many others) despite having the largest budget of any browser project and a VERY rapid release cadence.
No a lot of them are pretty straightforward, this is why I’m upset. I’m talking about, like, “SVGs with this feature don’t render correctly due to an oversight in size calculation” not “can you please implement WebGPU in the next release cycle”.
> How can you defend Safari rendering broken sites for long periods due to lack of frequent updates as a good thing?
That hasn't been true for a few years now.
Even now, when a site breaks in Safari, more often than not, it's because that particular site is using a Chrome-only feature that hasn't shipped in Safari or Firefox yet. These developers need to be reminded that progressive enhancement is a thing.
There are web developers who only test their sites on Chrome, which makes no sense, given mobile Safari has around 50% marketshare in the US [1] and about 21% globally [2].
> Just like Safari not having webgpu was touted as a feature and now that it has support, webgpu suddenly turned into a feature.
I must have missed this one, but anyone paying attention would have noticed WebGPU had been available in Safari (behind a flag) long before it became official; it was always on track to becoming a real feature.
[1]: https://gs.statcounter.com/browser-market-share/mobile/unite...
[2]: https://gs.statcounter.com/browser-market-share/mobile/world...
"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.
VBScript is a word I hadn't heard in quite a while! Brings back memories of editing 5k line .asp files to find an if statement and then a 1000 lines of html and such. Sadly, I dont' think web development is actual better 20+ years later, just different...
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.
> 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, and visionOS. This has been the schedule for several years. Since Safari 26 shipped on September 15, 2025, there have been two updates for these platforms:
Safari 26.1 on November 3rd and 26.2 on December 12th.
The Safari team shipped 7 releases this year, averaging 7½ weeks between releases; not a significant difference from 4–6 weeks. Each major release of Safari for macOS runs on the current macOS version (Tahoe) and the two preceding ones—Sequoia and Sonoma.
BTW, there were 9 Safari releases in 2024, averaging 5.8 weeks apart.
It's not the first time Safari shipped a significant new feature before other browsers; :has(), Display P3 color support, JPEG-XL come to mind. At the end of the day, there's no NIH or Marketing team dictating the release schedule.
[1]: https://webkit.org/downloads/
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.
> Having to wait for macOS updates holds back the browser, unnecessarily.
Safari is an operating system component, which lots of people don't seem to understand; hundreds of thousands of 3rd party apps rely on Safari's WebKit engine.
I've never heard a normie Safari user complain that Safari updates aren't being released quickly enough; that's something web and app developers care about… which is why Safari Technical Preview is released every two weeks.
Even the release versions of Safari on iOS, iPadOS and macOS allow you to enable web features that are still in development.
The bugs aren’t necessarily the browsers fault.
Safari has been releasing a lot more often than it used to. My personal gripe with Safari is how they decided to deal with extensions, forcing every developer through their hellish App Store submission experience.
> 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.
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.
Imagine if the literal army of Chromium/Blink engineers threw their entire weight into making the fundamental building blocks that everybody uses better instead of niche things that only a tiny fraction sites and web apps will ever need.
Hm, I know that Safari doesn't support 64bit wasm, which is a very important feature that Chrome and Firefox both have, but this seems to say they have "100% webassembly support".
https://webassembly.org/features/
interop is a subset of tests chosen beforehand (nowadays, mostly by devs voting in the github issues). This says Safari has reached 100% on the subset of tests agreed upon for interop-25. Those specific tests can be expanded by clicking it in the menu. It'll take you here:
https://wpt.fyi/results/wasm/jsapi?label=experimental&label=...
The full test-suite of wasm tests are here:
https://wpt.fyi/results/wasm
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
All of the above and even more so to have those features behave identically across the member browsers.
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.
The only people who think Safari is the new IE are people who weren’t around for IE.
it's also not possible for Safari to be the new IE because they don't have 95% marketshare. And IE's unique problem was that they pushed features that only they supported. Safari's problem is it doesn't support certain features
Also the thing is that there are plenty of features supported by Safari and Firefox that Chrome is slacking on. Nobody every complains about those features though because nobody would try to use a feature not supported by Chrome in the first place
> The only people who think Safari is the new IE are people who weren’t around for IE.
Absolutely true! I've said the same thing many times myself.
Stating that Safari is the new IE is one of the answers to:
"Tell me you didn't do web development in '90s and have no idea what you're talking about without telling me you didn't do web development in '90s and have no idea what you're talking about."
I hope they add WebTransport support soon.
voting for interop 2026 is active now. I see somebody has already submitted a proposal for it
https://github.com/web-platform-tests/interop/issues/1121
My favorite is finally supporting `arbitrary-subdomain.localhost`. Been a real pain in the neck to add Safari-specific fallbacks for my usage of that.
Oh, that's nice for sure! Has it been announced anywhere?
Does it still expand an svg to full size if u omit width and height attributes because u control the size in a parent container? Fuck safari
interop-2025. It does not mean Safari supports all the latest stuff. It means, "for some small subset of stuff here's the percent that's supported".
Of course Safari pushes to have anything they don't want to support not in that subset.
I wonder if Ladybird has explored running these interop tests yet. Or maybe these are just a subset of WPT?
You can edit the "products" represented in the table and add "Ladybird" to the list. [1]
Their result is: 1974740 / 2152733 (91%)
They also have their own dashboards tracking this [2]
[1] https://wpt.fyi/results/?product=ladybird
[2] https://grafana.app.ladybird.org/public-dashboards/2365098a1...
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 representative of all web platform standards. It includes tests for non-standard features and the majority of tests are simple unicode glyph rendering tests.
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
Some geographic regions have declared that not allowing other OS engines on iOS is anticompetitive so they're requiring Apple to allow them.
Apple is fighting it tooth and nail and coming up with requirements for other engines is a small way of doing that.
that was true until a few months ago due to a ruling in the EU. It's still currently the case that only WebKit can run on iOS but they're gearing up to change that
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.
I 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?
> It is funny how we keep asking more and more and more even though we already have it so much better than before.
I've been developing web stuff for 15 years now and sometimes I can't believe comments like these. We didn't have it "so much better before". CSS sucked hard and getting things right for three devices was an incredible pain in the ass.
Tables have semantic meaning. They don't support fractional units. Reflowing for mobile is impossible and you need JS hacks like splitting tables. You can't reorder natively.
I have been developing web stuff for 20 years now and I also can’t believe comments like these.
Flex and grid enable layouts that are far beyond anything we could do with table layouts. Anyone who claims otherwise has obviously not done any amount of serious, production FE UI design and development.
Are there bits of DX ergonomics I’d like in flex and grid? Of course. Does the syntax sometimes feel a bit arcane? Yeah. But the raw power is there, and anyone who claims the contrary is either a gormless backend developer, or some troll who is trying to design things in MS Word.
Tbf it said “we have it so much better Than before” I think they agree with you
I saw a similar comment on HN recently that CSS was "better" back in the day and what we have today is either unnecessary or too hard.
I reminded that person we had to use floats and positioning hacks and abuse HTML tables for page layout before flexbox and CSS Grid were created.
There was no way simple method to center a div!
> we already have it so much better than before
They meant now. "we have it so much better than how it used to be."
How would tables solve the issue they're talking about?
Borders can be applied to table cells independent of the content inside cells.
Gap decorations allow you to add borders between flex/grid items, but without the woes of dealing with table quirks and behavior.
Common use cases would include mimicking design patterns found in print layouts, particularly newspapers and menus, to help divide groups of items or info.
Examples: https://developer.chrome.com/blog/gap-decorations
This is exciting to see! I just used Masonry for a project this past week. While it works quite well and is pretty performant, it is pretty hacky using absolute positioning, wanting to know the aspect ratios of objects beforehand for smoother layout, and having to recalculate everything on resize. I'm looking forward to having a generally available native option one of these days.
Me, too. I like masonry layout too much to wait for CSS to solve the problem, so I've been waiting to remove the last 1.3KB of Javascript from my home page since 2019.
Thank you to everyone who is making this happen.
There is way to create masonry without specifying x,y position of every element though. https://codepen.io/mmis1000/pen/gOyZJqE
Adding a new element still need dimension of the element and a bit JavaScript.(The whole page use < 100loc unobfuscated JavaScript) But resizing can be handled by css naturally.
I think the issue here is most people don't really have a good way to specify how masonry should work. And thus don't have a good implementation either.
There is ways of create a basic masonery layouts using only pure CSS grid. But dependes on the use case. Take this example where are mixed cards without images, only text, and with images plus text.
https://codepen.io/zardoz89/pen/KKVEGbw
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.
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".
I know one of my clients complained something didnt work on their few year old iPad. So.. I don't know what the cutoff is but clearly not everything updates regularly. He did try updating it manually too but couldn't.
Safari got a big update last week.
Safari in general got an update, or Safari on only the devices Apple deems worthy? Usually Apple limits Safari updates to new phones.
Do you consider six-year-old phones new? What about seven-year-old Macs?
I think the iPhone X is the newest model that is no longer receiving iOS updates. That came out in 2017. So 8 years ago
I always thought that the masonry layout looked good but made it harder to get a good overview of the images.
A lot of web "design" is about how it looks rather than how usable it is. At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl". Never mind the text that is at 50% opacity until you scroll to the exact intended point, because nobody actually attempted to read it.
> At no point any stakeholder stops and actually uses the product, they scroll up and down, enjoy the pointless "scroll in" animations and say "kewl".
Actually that's exactly what they do. They like the animations while some people, especially devs, do not. But they don't use it multiple times, because they would be able to see how it gets annoying after the first time.
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.
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?
You can exploit flexbox for this type of layout: https://bfgeek.com/flexbox-image-gallery/
I dont know what would be the best way, but I personally want each image to be represented correctly in relation to all other image. This means that the way images are laid out will looked jagged. However, as a consequence of that, it is easy to find back to a specific image. Its like when you are coding, you look at the "shape" of the code when scrolling to find that specific function definition etc..
Here is an example of the layout of a photostream that I was satisfied with.
https://frifoto.emilbratt.no/?view_mode=photo-stream&tag=All...
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.
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 majority of the content in some images.
- If you display all images at their natural aspect ratio and their full size, there will be huge swathes of empty space in between them because they don't pack tightly.
Masonry layouts allow you to preserve aspect ratio without wasting a massive portion of your user's screen space. It's not perfect, but it's the best layout mixed-orientation content that I know of.
If you know of a better method to handle mixed orientations, I'd love to hear it and would gladly rescind by remarks.
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)
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.
What is it with commenters in this thread and wanting to "reliably scan one line at a time?" When users use image galleries, they generally do jump around because they're looking at all the options on screen all at once. The eyes absorb everything and then they pinpoint what looks good. I've never seen or heard anyone go line by line in an image gallery or a newspaper layout and doing so I'd find to be highly abnormal to average users.
I suspect if data from eye-tracking tests were available, there would be an extremely clear revealed preference from users. I read image galleries the exact same way I skim text, in an ordered fashion that allows me to "read" every image without reading an image twice, stopping if my attention is caught by something in particular. Splotting garbage over the screen haphazardly makes it blend together annoyingly and results in my eyes traversing the same areas multiple times both to try to pick out details and to try to keep my place in what I have/haven't skimmed yet. It is a layout that itself demands my attention, rather than letting my attention be absorbed naturally by the actual images.
From actual eye tracking data via Hotjar and similar, people do skip around the page. Those that scan linearly are in the minority but probably are more highly represented on HN, just as a matter of course.
Well I think this is a great step forward but it would be great if we could mix aspect ratios even better...
Consider a similar layout to OP but the landscape images will span multiple columns as well as everything it already does.
The thing about masonry is that it adapts to the size of the images. You could already do masonry using flexbox if you know the image sizes (https://github.com/hannasm/masonflexjs). Doing it as a true mosaic layout would be a step above current capabilities. At that point it's probably pretty easy to create configurations that don't fit perfectly/ require lots of empty space to layout nicely though.
Kind of random but why, in the linked repo, are you using dotnet core for minifying a Javascript file? I'm just curious. It seems like overkill to me.
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
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 one accidentally. Then navigating through the elements one by one requires a considerable amount of cognitive effort, your eyes bounce up and down constantly, and you end up inspecting the same elements multiple times.
If you try to go top-to-bottom, lane by lane, you will then realize that the page also has infinite scroll and you will never go past the first lane.
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.
I think it's one of those things that looks good, but is annoying to use non-superficially.
IMO it's annoying to use at all. It just looks "good" (subjective).
Larger images dominate and flashy images become more important to get attention (if bringing focus to an image is the idea). An extremely poor way to present information.
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!
It's not meant to be "efficient," it's meant to allow your eyes to look at the entire page at once to find what you're looking for. A newspaper or photo gallery comes to mind.
Feels very "right-brain". I'm a brain-hemisphere equality advocate. Good for sites like Pinterest. But also Home Assistant.
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...
Never read a newspaper?
(Not GP poster.) I don't really have a problem with masonry layouts, but a newspaper is limited by the paper size and they have incentive to squeeze everything in there (to maximize the spread of "information"). The screen is theoretically infinite (although not for kiosks).
I do have a website with a lot of images, and at the moment everything is in a 3-across grid layout...
The screen is infinite but information should still be prioritized, that is why newspapers use different sizes of headings. If they truly wanted to jam everything in there, they'd use the same small font size and save on paper, but that's not what people like because they want to see at a glance what is important and what's not, and that's done by the font size initially. This is no different on an infinite screen, the design principle of information prioritization still holds.
Yes, I have. Printed, which is fundamentally, and literally a different media type with different properties
Someone else said the same thing which I addressed here: https://news.ycombinator.com/item?id=46331586#46334242
TLDR: in the user's eyes, a newspaper and this sort of layout are not very different, if the average user can navigate the former for hundreds of years, they can navigate the latter.
Ok, but the fact of the matter is that a digital display rendering a webpage and a physical format of a newspaper are fundamentally different media and should be treated as such. A wall of text isn't fundamentally a bad thing, but on a display monitor (or god help you, a cellphone or tablet) that's a terrible user experience.
Sure, you can treat them differently, but for certain use cases and layouts, you can treat them the same. It all depends on what you're trying to do.
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.
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. Web layouts leave one axis free to expand as far as necessary to fit the content, so there is no sane algorithm for laying out arbitrary content this way. Either you end up with items ordered confusingly, or you end up having to scroll up and down repeatedly across the whole damn page, which can be arbitrarily long. Either option is terrible. Don't even get me started on how poorly this interacts with "infinite scroll".
Well not all content is meant to be read in order. A layout like this is good for content where you want to incentivise users to read in whichever order you like. So if the order is confusing you, chances are there wasn't meant to be any order at all. E.g. if you search google images google guesses some relevant order for you, but it is layed out in a dense way so you can scan with your eyes and decide which thing is most relevant for you. Whether you scan the screen left-right, top-down, randomly, bottom up, or ehatever is totally your choice.
Using such a layout for a novel or something like this would be really bad UX. But using it for an image gallery? Or a series of random articles that aren't priorized? Why not?
> 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.
> what the fuck am I supposed to read next?
What a weird comment. You read whatever you want next, ever read a newspaper? You scan it all and pick the article you are interested in, then read that. I don't understand these comments, they work perfectly well in real life (and fixed size is arbitrary, I can make a super wide or super long newspaper too, the axis size does not affect this sort of layout, see infinite scroll for example, as there is only a fixed amount of content on the screen at any given time).
> You scan it all and pick the article you are interested in
Okay. What order am I supposed to scan in so I don't lose my place and accidentally skip a block? Scanning column by column gets me cut off partial boxes that I'll have to remember to check again later, while scanning side to side forces me to keep track of each individual block I've already looked at, as opposed to a single pointer to "this is how far I've scanned". Alternatively, I can scan roughly left to right, top to bottom and just live with missing some blocks. That's not ideal either, because hopefully if you didn't think I'd like to look at all of them you wouldn't have included them on the page.
You're right that you can make a newspaper that's really inconvenient to read, but you wouldn't, because the failure case you'd end up with is CSS Grid Lanes.
This is so funny that I'm not even sure what to say. You can ask your exact questions about a newspaper but somehow 99% of people manage to read them just fine. I think it's just a you problem that you are looking for an exact algorithm on how to scan a page with multiple sizes of content; in reality, people just look over it all and keep track of what they have or haven't looked at all in their heads.
In a newspaper the answer is simple. You linearly scan the leftmost column to the bottom of the page, then the next column, then the next, and so on until you get to the end of the page. At no point do you ever need to keep track of anything other than "this is how far I've gotten" to make sure you haven't missed anything. Columnar layout make sense in newspapers because both axes are fixed in size, so all you ever do is one long linear scan with wraparound.
If one axis is fixed, and it is in the case of grid lanes (it's not a fully pannable infinite canvas like Figma after all), you just keep reading the content that's on the current screen, then you scroll. I really don't see how it's any different to, for example as I mentioned previously, a long newspaper with many pages; each "page" is one "screen" worth, analogously. It's like infinite scroll, either vertically or horizontally, where instead of just one item in the list, you have a few. And if we're being really pedantic, Figma users do perfectly fine keeping the context of the content in their minds even in an infinitely pannable canvas. And also, generally newspaper readers do not do what you say, scanning column by column, they instead glance their eyes over all of the headlines then pick which one looks good then they read the article attached to that, it is a free form process.
So again, I will contend that this is not a problem for the average reader. I really cannot see where the difficulty you seem to say lies.
Funny, I think that looks gorgeous!
NYTimes.com comes to mind...
what's your problem?
I've run the masonry layout (for my personal bookmark website) ever since I've found it in the browser settings.
grid-template-rows: masonry;
is going to be outdated then?
Yeah, there was a years long debate that effectively ended with: “We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.”
https://m.youtube.com/watch?v=yikbSQ6tvlE
> We held a vote that you weren’t aware of and decided that masonry was out. If you cared, you should have participated in the vote that you were not aware was happening. It’s too late to change it.
I think that’s an exceptionally uncharitable description of what happened. This is a decision the WebKit team has been repeatedly publicly asking people to participate in for over 18 months.
> Help us invent CSS Grid Level 3, aka “Masonry” layout
> P.S. About the name
> It’s likely masonry is not the best name for this new value. […] The CSSWG is debating this name in [this issue]. If you have ideas or preferences for a name, please join that discussion.
— https://webkit.org/blog/15269/help-us-invent-masonry-layouts...
> Help us choose the final syntax for Masonry in CSS
> We also believe that the value masonry should be renamed.
> As described in our previous article, “masonry” is not an ideal name, since it represents a metaphor, and not a direct description of its purpose. It’s also not a universally used name for this kind of layout. Many developers call it “waterfall layout” instead, which is also a metaphor.
> Many of you have made suggestions for a better name. Two have stood out, collapse and pack as in — grid-template-rows: collapse or grid-template-rows: pack. Which do you like better? Or do you have another suggestion? Comment on [this issue] specifically about a new value name (for the Just Use grid option).
— https://webkit.org/blog/16026/css-masonry-syntax/#footnote-1
> [css-grid-3] Renaming masonry keyword
— https://github.com/w3c/csswg-drafts/issues/9733
The debates went on for years and following it closely became a poor use of time. Even the subgrid conversation seemed completely stalled. I think a lot of people tuned out long before any vote was discussed. I did.
But if you were the one who tuned out, then isn’t it uncharitable to describe it as their failing to make you aware of the vote? Isn’t it on you to stay in the loop?
Surely they can’t start just pinging everyone who might have cared at some point during the time to get involved.
I get what you're saying but making interminable arguments and keeping the "debate" going is a tactic. There's that CIA sabotage manual with the section about meetings and conferences, it can feel like that. The duration of these debates aren't usually measured in hours, days, or weeks, but years. And the people who dragging them on and staying in the fights are employed full-time to do exactly that.
It got to the point where I believed that subgrid was dead. FF implemented it but absolutely no one else did, for years.
Is it our fault for tuning out of the debate? Yep. But tactics were employed to achieve that exact outcome. I'm fine admitting that I tuned out. But it was a battle of attrition waged by people who were fine holding up progress indefinitely.
Is that how you want decisions to be made?
Ultimately I'm not too concerned what you call the masonry feature. However the debate over what to call it was an extreme case of bikeshedding. I would have rather given up the fight over semantics to resolve the non-issues and ship the feature years ago. As it stands we're still years away from actually being able to use the feature in production.
I've stopped waiting for companies, committees, or projects to change course. I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist. Why bother? I have an incentive to spend my time building features that users will use.
This feels very much tinfoil.
There’s no incentive to the companies or the employees to draw out the discussion, especially over something so trivial. It’s much more preferable to try and speed through things to get things done in a time frame that can be adopted.
And regardless, if you don’t feel it’s worth your time, then why cast aspersions that it was something clandestine and intentionally hidden? You could have shown up and kept up with it, just like everyone else involved presumably did.
Eh, you’re trying to put words in my mouth.
I didn’t ascribe a motive to anyone. Their reasons are their own and it only makes sense that the people who stay in these fights do it because it’s part of their jobs.
There are people who, for whatever reason, keep debates going over small points of disagreement and prevent issues from being settled. Sometimes for years. Right?
The older I get, the more likely I am to recognize and route around or ignore interminable debates. Especially if it’s not for a company, project, or initiative under my direct control.
Remember, the question at the top of this thread was essentially “What happened to ‘masonry’?” Well, there were quibbles over the descriptors.
I don’t care about quibbles. “masonry”, “grid-lanes”, “grid-masonry”, pick one, they’re equivalent. I don’t like it when quibbles block progress.
Sometimes people and companies do want to block things. You’d have to ask them why. Like I said earlier:
> I don't have an incentive to build consensus within a group of people who fundamentally disagree that the thing I need should exist.
Pick your battles… Actually, no, it’s usually better to ignore the fights and just get what you need to get done so you can move on.
Wasn't Firefox the only browser that actually implemented `grid-template-rows: masonry` anyways?
It sucks whenever browsers backtrack on a W3C standard that reached "Working Draft" status but it doesn't seem like it's gonna impact many people
Besides, it's not being "deprecated". It will continue to work as it does. We just have a better alternative that the big 3 all agreed on.
Masonry was never “in”, no? Mozilla proposed it and were the only ones to implement it, behind a feature flag. Then WebKit proposed an alternative that was discussed at length:
https://github.com/w3c/csswg-drafts/issues/10233
People have been dragging their feet on subgrid, masonry, etc for almost a decade. I followed it pretty closely for years but stopped when it started turning into a Christopher Guest mockumentary.
Masonry or grid-lanes, who cares? I’m just glad masonry (the feature, Baseline 20XX) and subgrid (Baseline 2023) are finally here.
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 more masonry than the grid-template-rows:masonry setting. yeah yeah, raw css vs js library blah blah
One hack to almost get a justified gallery like that with no javascript is to lay them out with flexbox, setting their width to a percentage or vw value which your backend calculates based on image aspect ratio and desired image height, use flex-grow to stretch them to fill remaining space, and then using background-position: cover to make the images fit the slightly wrong aspect ratio containers.
This will of course slightly crop all your images to make it fit, but in practice as long as you keep your image aspect ratios reasonable and the images small enough on the page it's really quite subtle.
I had hoped that this feature would provide for masonry like that, but one has to make do.
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/
The following should be compatible with both approaches:
Firefox and browsers supporting the old syntax will ignore the `display: grid-lanes` as it doesn't recognize it and fall back to the grid+masonry.Browsers supporting the new syntax will override the `display: grid` with `display: grid-lanes` and ignore the `grid-template-rows: masonry` syntax.
Very cool! I wonder, will it be easy to build interactive interfaces on this primitive, like animations and drag-and-drop?
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.
Recently discussed on HN: https://news.ycombinator.com/item?id=46144039
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.
Don't use continuous math in either a design system nor a constraint solver that you expect random developers to use. Either case will only lead to problems.
I largely agree, but there's a little nuance insofar as "interior-point" methods are very powerful. You can go a long way by encoding your goals as error functions and letting a gradient-based optimizer do the rest.
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
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
The naming was half the discussion on implementing this. There were a lot of people smarter and more knowledgeable than me that had a lot of opinions on the name that I hadn't thought about. I remember one of the reasons was that the word "masonry" wasn't as obvious a concept for non-English speakers.
Masonry grid layout was one of a few interviewing pair programming tests I would give to frontend engineers. I need to see how this works under the hood!
I wonder how long it takes LLMs to correctly ingest fresh CSS notation like this.
I have to ask, like with all the other browser specific trial implementations: how is cross platform support? If we wanted to make a grid layout that only worked in one browser engine, grid-template-rows: masonry was there for a while now.
Chromium still seems to be working on support it seems based on https://cr-status.appspot.com/feature/5149560434589696 so maybe it'll be useful soon? That page indicates that they're still discussing certain parts of the spec.
It's been on-and-off in all three browsers behind flags etc, but it's been in a constant state of flux over the last three years. One of the most gnarly new CSS features to get right. Lots of great arguments about how to implement it.
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?
I have too. And the Safari version that was in the betas/tech previews.
One of the biggest arguments over the last couple of years was what to call it. A lot, lot of ideas put forth as alternatives to "masonry" which wasn't thought to be great for non-English speakers. I'm glad they finally nailed a name for it!
The other big argument was over how to activate it. Is it a grid? Is it a flexbox? Is it a brand new animal?
Now I just need to figure out the best way to implement this semantically with a polyfill for the next 30 months until it's baseline.
I actually started using Safari's `grid-template-rows: masonry` when it came out, but unfortunately Safari TP crashed a lot on me when using that for some reason. Chromium's never had a problem.
how does it work with animations? like if i transition:all and then remove a middle img does the other elements get animated?
I guess wire up a codepen demo and try it out. I know the guys writing this were well aware of all the edge cases like that and these are some of the absolute smartest CSS people you can think of who had to write the very detailed spec for this.
I don't think the smooth reflow made it into the current spec, so I guess watch this space?
https://www.w3.org/TR/css-grid-3/
What’s the best resource for getting a handle on all modern CSS for someone who hasn’t paid attention since flex box
I like Josh W Comeau's content, he has a lot of free articles, but his paid CSS course goes through step by step why CSS is the way that it is, worked great for me for understanding it all. My work paid for it though, that's why it's priced so high, but I'm sure he has discounts for individuals.
This should be a good start: https://nerdy.dev/cascading-secret-sauce
There are a lot of resources.
I am a fan of: https://www.youtube.com/@KevinPowell
Kevin is a no-nonsense no-hype educator. He will keep you up to date without a lot of engagement hacking.
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.
I suppose just checking scroll height of the container? Once you're x pixels above the bottom, fetch more. Not the smoothest, but doable
You just append new <figure> elements to the <main> in the example and it will automatically put them in the appropriate column.
Your answer doesn't appear to relate to what I asked. You need to know when to query the backend for more data if it's an infinite scrolling setup.
Aahh. The way you phrased your question was pretty ambiguous.
The other posters have good answers. One thing to consider for a smooth interaction would be to eagerly load the next x elements before they scroll into view.
Yeah I’d assume you’d eagerly load enough to make sure everything gets at least partially into the viewport, and maybe a fee more to optimize for network latency. And then perhaps track elements whose trailing ends are not in the viewport, and load more once those become fully visible?
It’s always nice to see native implementations of functionality pioneered by third-party libraries. Bootstrap, for example, has made this kind layout (somewhat) possible but there is also a Masonry plugin that simplifies it.
I think Apple should make Safari stable downloadable option for all platforms.
I’m old enough to have installed Safari on Windows XP. I’m not sure it has been enough years since this Apple failed product.
experiencing how text renders differently, slowly, with my potato battleship
There are WebKit-based browsers for Linux: https://webkit.org/downloads/
This might actually happen indirectly. Kagi’s new browser uses WebKit. macOS only now, but eventually it’ll come to windows
I have been using Kagi Orion on macOS and iPhone, so far so good.
That makes sense. Safari is so smooth now in iOS. Moved from Firefox.
Any ideas how I can track support for this in firefox?
It seems that support tracking websites don't know what this is yet. MDN briefly notes it as an option for `display` but there is no other mention of it.
Is there anything to be said about accessibility? Found the word only once in the comments.
They mentioned tabbing and screen readers quite a few times.
I found the "jumping" ordering quite concerning but further down in the article they mention "tolerance" that seems to be a way to allow the layout to be more consistent in terms of ordering.
sweeeeeeeeeeeet
[dead]
Is anyone working on actual css problems instead of this sugar syntax?
Hypermedia suffers because these marketing companies waste time on making sure they can build Pinterest in 10 LoC instead of fixing actual long running hypermedia domains.
Moving this sort of stuff out of JavaScript and arcane hacks allows the browser rendering engines to optimize these common patterns. This is sorta the opposite of syntactic sugar. The syntactic sugar is the libraries that implemented these patterns without rendering support.
Shall we call it syntactic umami perhaps? Or syntactic lipids?
Oh, how cool! Another barrier to a new browser gaining user base!
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?
There is no winning, is there? Half of HN wants browsers to revert to document readers and the other half wants HTML and CSS to do what JS can. A small minority then insists that we should get rid of HTML and CSS entirely and start from scratch. The louder the ideas the further away the person is from actually using the tech. I personally would not have the patience for community management.
That said, CSS masonry looks solid.
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.
How was this masonry layout possible back in the 90s?
Tables.
> HTML has become more and more bloated. How many methods do we need to do something that was possible back in the 90s?
This is incorrect. Lots of old stuff was removed or deprecated from the HTML5 specification; elements like `s`, `u` were repurposed from being presentational to semantic:
- acronym
- applet
- basefont
- big
- center
- dir
- font
- frame
- frameset
- isindex
- noframes
- s
- strike
- tt
- u
- xmp
- noembed
- plaintext
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.
Psh, rocket science only has to contend with physics, which generally doesn't change much, if at all. The equations used to get humans to the moon didn't change because someone discovered you can send a specially crafted packet and escape the sandbox and steal money from everybody on the Internet.
Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).
Personally, I use an 11-year-old machine and have had to add userscript hacks to certain major Web sites to work around bugs in CSS grid (not the "lanes" described here).
At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too? But they seem not to.
For example, the demo page linked in the article fails pretty unusably for me. All the images take up nearly the full viewport width.
> I use an 11-year-old machine
What OS are you running that can't run modern versions of browsers, and on what hardware?
Current Chrome runs on Windows 10, which came out 9.5 years ago but was intended to run on older computers, and macOS Monterey, which runs on Macs from ~2014-2015 depending on the model. But even Big Sur before that, the most recent version of Chrome which runs on that is Chrome 138 from just 6 months ago, and that doesn't seem old enough that you need to build userscript hacks.
I'm really curious what you're actually running. Generally speaking, an 11-year-old desktop should be able to run the current browser, and if not, a very recent one.
I am using a machine older than eleven years old and can still run the newest version of Firefox and Chrome.
I don't think the world needs to cater to people that refuse even basic internet hygiene.
I routinely use an 11 year old computer too. I can not see why "userscript hacks" would be needed.
> Personally, I use an 11-year-old machine and have had to add userscript hacks to certain major Web sites to work around bugs in CSS grid (not the "lanes" described here).
The version of CSS Grid we're using today didn't ship until 2017; a browser from 11 years ago would be using one of the non-standard versions of Grid. For example, Internet Explorer 11 was the first browser to ship a grid implementation.
> At least new JavaScript features can be "polyfilled" or whatever. Maybe sites could check for CSS feature support too?
First, not every site needs to look exactly the same in every browser; that's why progressive enhancement is a thing.
Second, there are multiple ways to create masonry-style layouts that don't require masonry support in the browser using multi-column layout or flexbox.
Third, masonry can be polyfilled using JavaScript [1].
[1]: https://masonry.desandro.com/
When the web came out it itself was new technology that excluded some older machines. Lynx kind of worked (I used it!) but it was a poor substitute, especially once `<img>` showed up.
You want to platform to be able to make progress and not be frozen in amber by what we had at some "magical" year when things were in some Golidlocks powerful enough but not too complex state. Especially since a lot of progress lately has been fixing long-standing inconsistencies and obvious gaps.
The cost of that is that yes, neither my Apple IIe or my Micro Pentium 90 run the modern web... one day my MBP M1 won't either.
[dead]
Not updating your browser will net you tons of exploitable vulnerabilities.
How do you expect things to ever change if no one ever updates? Certainly even if you decide to lean towards maximum support it’s still a positive these features are being introduced so you can use them in 10 years.
> How do you expect things to ever change if no one ever updates?
Maybe things should stop changing.
We don't really need ten new CSS attributes every year. Things work. The elegant solution is to announce the project is done. That would bring some much-needed stability. Then we can focus on keeping things working.
The issue with this is that the browser is the cross-playing operating system, the VM that runs webapps. But we treat the platform like an evolving document format. If we want to declare it complete, we need to make it extensible so we can have a stable core without freezing capabilities. I foresee all of this CSS/HTML stuff as eventually being declared a sort of legacy format and adding a standard way to ship pluggable rendering engines/language runtimes. WASM is one step in that direction. There are custom rendering/layout engines now, but they basically have to render to canvas and lose a lot of performance and platform integration. Proper official support for such engines with hooks into accessibility features and the like could close that gap. Of course, then you have every website shipping a while OS userland for every pageload, kinda like containers on servers, but that overhead could probably be mitigated with some caching of tagged dependencies. Then you have unscrupulous types who might use load timings to detect cache state for user profiling... I'm sure there's a better solution for that than just disabling cross-site caching...
I digress.
> I foresee all of this CSS/HTML stuff as eventually being declared a sort of legacy format and adding a standard way to ship pluggable rendering engines/language runtimes.
I doubt this is going to happen as long as backwards compatibility continues to be W3C's north star. That's why all current browsers can still render the first website created by TBL in 1989.
Sure, official support for certain extensions should happen but HTML/CSS will always be at the core.
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 development in its tracks.
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%"
> Maybe things should stop changing.
There are two kinds of technologies: those that change to meet user needs, and those that have decided to start dying and being replaced by technologies that change to meet user needs.
> Is this increasing complexity in the Web layout world worth it?
Yes. I held off learning about CSS Grid for a very long time and as soon as I did I was converted. Sometimes I think the web doesn’t get enough credit for its ambition: mobile viewports, desktop viewports, touch interaction, pointer interaction, complex documents, webapps… it’s a lot. But you get some complexity as a side effect. The complexity we do see these days isn’t invented out of whole cloth, it’s standardising and improving layouts people are implementing with JavaScript, often badly.
> Is this increasing complexity in the Web layout world worth it? Anyone who wants to use this is going to drop support for older browsers (and, in so doing, older machines that can't run newer OSes and newer browsers).
If you’ve been at this for a while, it’s important to remember that browsers update a lot faster than they used to. Anchor positioning came out last year, for example, and all of the major browsers support it by now. Very old devices are a problem but security is purging those out faster than used to be the case.
We also have better tools for progressive adoption since you can easily query for things like CSS feature support. In this demo, they didn’t implement fallbacks but in most real sites you’d have something like a basic grid layout which is perfectly serviceable for the fraction of users on old Firefox releases.
> Maybe sites could check for CSS feature support too? But they seem not to.
Certainly can: https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/A...
What does the age of your machine have to do with browser compatibility issues? Are you running a stale OS and a stale browser on that OS?
Sooner or later, the age of your machine will affect browser compatibility.
It doesn't even take many things to do this — the knock-on support of a bug in a driver that no-one wants to fix, a package that you like that prevents you from upgrading your host OS, web browser developers abandoning something about your GUI (how long before they drop X?) etc.
In the Linux world, the age of your machine is a limit with a blurry edge, but it's still there.
Yes it is. Developers write bad code when they try to work around the lack of features with ill thought out hacks, this results in a bad website for everybody, even those of us that keep our software up to date, and just so happen to have a different screen resolution and a different browser then what the developer tested on.
If enough consumers aren't able to use the website, then business wouldn't use it. The reality is new computers aren't that expensive (I see used M1s for under 1k) and consumers are upgrading.
You mentioned a used model that is over 5 years old as an example of "a new computer", and "1k" as "not expensive for consumers". It is honestly impressive how well you undermined your own point.
> If enough consumers aren't able to use the website, then business wouldn't use it.
I sincerely doubt any business owner would approve of losing even 10% of their potential users/customers if they knew that was the trade-off for their web developer choosing to use this feature, but there are disconnects in communication about these kinds of things -- if the web developer even knows about compatibility issues themselves, which you would expect from any competent web developer, but there are a whole lot of incompetent web developers in the wild who won't even think about things like this.
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 developers fall into the competent or incompetent bucket, but regardless of which there are more of, there are a significant enough number of incompetent ones.
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.
Note that the comma in browserlist queries are OR. So if any given browser version still has > 0.2% usage, it is included. This would include Chrome 109 which is three year old. Meaning developers with this browswerlist target would fail their static analysis / peer review (actually even a more reasonable > 0.5% still fails on Chrome 109) if they used a feature which Chrome 109 doesn’t support without graceful degradation or polyfill.
Furthermore the "baseline widely available" target (which IMO is a much better target and will probably become the recommendation pretty soon) includes versions of the popular browsers going back 30 months, meaning a competent team of web devs with a qualified QA process should not deliver software which won‘t work on your 2 year old browser.
I can‘t speak for the developers of the websites which break on your 2 year old browser... Maybe they don‘t have a good QA process. Or maybe you were visiting somebodies hobby project (personally I only target "baseline newly available" in my own hobby projects; as I am coding mostly for my own amusement). But I think it is a reasonable assumption that user tend to update their browsers every 30 months, and you won‘t loose too many customers if you occasionally brake things for the users which don’t.
A couple of examples of the kinds of hobby projects that break on my 2-year-old Chrome installation: ChatGPT.com, Claude.ai, Substack.com
Your position sounds reasonable upon elaboration, I only wish more web developers had the same consideration.
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.
My go-to reference is this, which itself cites statcounter: https://caniuse.com/usage-table
I was specifically referencing desktop Chrome, not including Chrome for Android, but other than that, if there are discrepancies, I'm not sure what the cause is.
Very interesting.
The Timo Tijhof data is based on Wikipedia visits, and shouldn't be affected by adblockers.
Meanwhile, StatCounter is based on sites that use its analytics, and on users not using adblockers that might block it. The CanIUse table makes clear there's a long tail of outdated Chrome versions that each individually have tiny usage, but they seem to add up.
It's fascinating they're so wildly different. I'm inclined to think Wikipedia, being the #9 site on the web [1], is going to produce a more accurate distribution of users overall. I can't help but wonder if StatCounter is used by a ton of relatively low-traffic sites, and the long tail of outdated Chrome is actually headless Chrome crawlers, and so they make up a large proportion relative to actual user traffic? Since they're not pushed to update, the way consumers are. And especially with ad-blocking real users excluded too?
Anecdotally, in web development I just haven't seen users complain about sites not working in Chrome, where it turns out the culprit is outdated Chrome. In contrast to complaints about e.g. not working in Firefox, which happen all the time. Or where it breaks in Chrome but it turns out it's an extension interfering.
[1] https://en.wikipedia.org/wiki/List_of_most-visited_websites