[HN Gopher] CSS Grid Lanes
___________________________________________________________________
CSS Grid Lanes
Author : frizlab
Score : 696 points
Date : 2025-12-19 22:13 UTC (1 days ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| jonah wrote:
| 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.
| aag wrote:
| 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.
| mmis1000 wrote:
| 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.
| memonkey wrote:
| 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!
| valleyer wrote:
| 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.
| jimvdv wrote:
| 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.
| hackyhacky wrote:
| > 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.
| runarberg wrote:
| 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.
| hackyhacky wrote:
| > 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.
| runarberg wrote:
| 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%"
| idle_zealot wrote:
| 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.
| alwillis wrote:
| > 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.
| JoshTriplett wrote:
| > 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.
| OsrsNeedsf2P wrote:
| 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.
| anonymous908213 wrote:
| 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.
| runarberg wrote:
| 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.
| anonymous908213 wrote:
| 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.
| runarberg wrote:
| 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.
| anonymous908213 wrote:
| 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.
| crazygringo wrote:
| 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.
| anonymous908213 wrote:
| 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.
| crazygringo wrote:
| 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
| runarberg wrote:
| 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.
| anonymous908213 wrote:
| 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.
| spankalee wrote:
| 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.
| runarberg wrote:
| 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.
| mikae1 wrote:
| _> 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...
| SeanAnderson wrote:
| 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?
| exasperaited wrote:
| 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.
| acdha wrote:
| > 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.
| throwaway613745 wrote:
| 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.
| mikae1 wrote:
| I routinely use an 11 year old computer too. I can not see
| why "userscript hacks" would be needed.
| afavour wrote:
| > 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.
| crazygringo wrote:
| > _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.
| alwillis wrote:
| > 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/
| phoronixrly wrote:
| Oh, how cool! Another barrier to a new browser gaining user base!
| ThatMedicIsASpy wrote:
| 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?
| miiiiiike wrote:
| 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
| culi wrote:
| 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.
| afavour wrote:
| 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
| miiiiiike wrote:
| 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.
| JimDabell wrote:
| > 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
| miiiiiike wrote:
| 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.
| dagmx wrote:
| 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.
| miiiiiike wrote:
| 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.
| dagmx wrote:
| 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.
| dylan604 wrote:
| 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
| karlshea wrote:
| What you're looking for is described in the article as
| "bricks" (vs "waterfall") and is also supported.
| notpushkin wrote:
| 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/
| brcmthrowaway wrote:
| 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.
| fragmede wrote:
| 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.
| concinds wrote:
| 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.
| culi wrote:
| 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
| ChadNauseam wrote:
| 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...
| rendaw wrote:
| I thought that was supposed to be fixed by contenteditable
| plaintext-only. Why was field sizing still necessary?
| hombre_fatal wrote:
| 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.
| extra88 wrote:
| `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.
| neo_doom wrote:
| 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!
| TheCoreh wrote:
| 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
| lelandfe wrote:
| All of the above _and even more so_ to have those features
| behave identically across the member browsers.
| alwillis wrote:
| > 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.
| al_borland wrote:
| 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.
| concinds wrote:
| 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.
| simondotau wrote:
| 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.
| runlaszlorun wrote:
| 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...
| concinds wrote:
| 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".
| simondotau wrote:
| 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.
| hu3 wrote:
| 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.
| simondotau wrote:
| 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.
| saagarjha wrote:
| Why do you keep conflating bug fixes with new platform
| features?
| simondotau wrote:
| 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.
| concinds wrote:
| > 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!
| alwillis wrote:
| > 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...
| kyle-rb wrote:
| 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.
| troupo wrote:
| "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.quirksmo
| de.org/blog/archives/2021/08/breaking_th...
| simondotau wrote:
| That's a good article. Thanks for surfacing.
| alwillis wrote:
| > 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
| 71/2 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/
| concinds wrote:
| 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 71/2 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.
| alwillis wrote:
| > 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.
| wpm wrote:
| The bugs aren't necessarily the browsers fault.
| halapro wrote:
| 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.
| madeofpalk wrote:
| 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.
| cosmic_cheese wrote:
| 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.
| meowface wrote:
| I hope they add WebTransport support soon.
| culi wrote:
| 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
| MintPaw wrote:
| 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/
| culi wrote:
| 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
| hoten wrote:
| I wonder if Ladybird has explored running these interop tests
| yet. Or maybe these are just a subset of WPT?
| open592 wrote:
| 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...
| nicoburns wrote:
| 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.
| culi wrote:
| 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.
| nextaccountic wrote:
| 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
| extra88 wrote:
| 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.
| 65 wrote:
| 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.
| Unai wrote:
| 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.
| robertoandred wrote:
| The only people who think Safari is the new IE are people who
| weren't around for IE.
| alwillis wrote:
| > 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."
| pie_flavor wrote:
| 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.
| jhogervorst wrote:
| Oh, that's nice for sure! Has it been announced anywhere?
| zwnow wrote:
| 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
| socalgal2 wrote:
| 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.
| nitwit005 wrote:
| How would you query the location where you need to load more data
| when scrolling down (the highest empty spot)?
| jonah wrote:
| You just append new <figure> elements to the <main> in the
| example and it will automatically put them in the appropriate
| column.
| nitwit005 wrote:
| 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.
| jonah wrote:
| 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.
| pcl wrote:
| 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?
| tom1337 wrote:
| 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.
| notpushkin wrote:
| Hmm, I think we only need to observe the
| `elements.at(-numberOfLanes)`, as it should be the first to
| enter the screen anyway.
| rokkamokka wrote:
| I suppose just checking scroll height of the container? Once
| you're x pixels above the bottom, fetch more. Not the
| smoothest, but doable
| cod1r wrote:
| sweeeeeeeeeeeet
| uniq7 wrote:
| 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.
| Tempest1981 wrote:
| Feels very "right-brain". I'm a brain-hemisphere equality
| advocate. Good for sites like Pinterest. But also Home
| Assistant.
| aidenn0 wrote:
| I think it's one of those things that looks good, but is
| annoying to use non-superficially.
| j_w wrote:
| 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.
| sippeangelo wrote:
| 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!
| ethmarks wrote:
| 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.
| satvikpendem wrote:
| 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.
| jbritton wrote:
| 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.
| eurleif wrote:
| Recently discussed on HN:
| https://news.ycombinator.com/item?id=46144039
| hansvm wrote:
| 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.
| marcosdumay wrote:
| 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.
| jacobp100 wrote:
| 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
| jeroenhd wrote:
| 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.
| qingcharles wrote:
| 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.
| emilbratt wrote:
| I always thought that the masonry layout looked good but made it
| harder to get a good overview of the images.
| Sharlin wrote:
| The biggest problem is that it's good if your images are all
| landscape or all portrait, but not when mixed.
| SahAssar wrote:
| The whole point of a masonry layout is if you have different
| aspect ratios. Otherwise a masonry layout is just a normal
| grid.
| Sharlin wrote:
| 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.
| powersnail wrote:
| 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?
| emilbratt wrote:
| 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...
| bfgeek wrote:
| You can exploit flexbox for this type of layout:
| https://bfgeek.com/flexbox-image-gallery/
| ethmarks wrote:
| 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.
| Sharlin wrote:
| 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.
| ethmarks wrote:
| 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.
| hannasm wrote:
| 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.
| ethmarks wrote:
| 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.
| anonymous908213 wrote:
| 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)
| satvikpendem wrote:
| 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.
| anonymous908213 wrote:
| 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.
| satvikpendem wrote:
| 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.
| anonymous908213 wrote:
| 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.
| satvikpendem wrote:
| 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.
| jrgd wrote:
| 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 Muller Brockmann grid
| halapro wrote:
| 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.
| satvikpendem wrote:
| > _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.
| oefrha wrote:
| 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?
| qingcharles wrote:
| 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.
| oefrha wrote:
| 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.
| swyx wrote:
| how does it work with animations? like if i transition:all and
| then remove a middle img does the other elements get animated?
| qingcharles wrote:
| 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/
| acjohnson55 wrote:
| Very cool! I wonder, will it be easy to build interactive
| interfaces on this primitive, like animations and drag-and-drop?
| snooooooooooore wrote:
| 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.
| pcl wrote:
| 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?
| ray_v wrote:
| 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...
| arewethereyeta wrote:
| what's your problem?
| 2cynykyl wrote:
| Funny, I think that looks gorgeous!
| jlaternman wrote:
| I think this looks great too. Finally replicating the
| efficiency of newspaper layouts. No enforced symmetry, just
| content in an optimal space. I want.
| snackbroken wrote:
| 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".
| satvikpendem wrote:
| > _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).
| snackbroken wrote:
| > 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.
| satvikpendem wrote:
| 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.
| snackbroken wrote:
| 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.
| satvikpendem wrote:
| 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.
| atoav wrote:
| 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?
| zozbot234 wrote:
| > 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.
| 65 wrote:
| NYTimes.com comes to mind...
| meesles wrote:
| 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.
| satvikpendem wrote:
| Never read a newspaper?
| netsharc wrote:
| (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...
| satvikpendem wrote:
| 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.
| ray_v wrote:
| Yes, I have. Printed, which is fundamentally, and literally a
| different media type with different properties
| satvikpendem wrote:
| 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.
| ray_v wrote:
| 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.
| satvikpendem wrote:
| 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.
| wackget wrote:
| 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.
| rahkiin wrote:
| 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?
| j-krieger wrote:
| > 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.
| spencerflem wrote:
| Tbf it said "we have it so much better Than before" I think
| they agree with you
| alwillis wrote:
| 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!
| perardi wrote:
| 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.
| sabellito wrote:
| How would tables solve the issue they're talking about?
| docmars wrote:
| 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
| GaryBluto wrote:
| 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?
| willio58 wrote:
| 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.
| ezequiel-garzon wrote:
| How was this masonry layout possible back in the 90s?
| GaryBluto wrote:
| Tables.
| gherkinnn wrote:
| 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.
| alwillis wrote:
| > 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
| ricksunny wrote:
| I wonder how long it takes LLMs to correctly ingest fresh CSS
| notation like this.
| todotask2 wrote:
| I think Apple should make Safari stable downloadable option for
| all platforms.
| speedgoose wrote:
| 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.
| kuekacang wrote:
| experiencing how text renders differently, slowly, with my
| potato battleship
| jacobp100 wrote:
| This might actually happen indirectly. Kagi's new browser uses
| WebKit. macOS only now, but eventually it'll come to windows
| alwillis wrote:
| There are WebKit-based browsers for Linux:
| https://webkit.org/downloads/
| imbnwa wrote:
| What's the best resource for getting a handle on all modern CSS
| for someone who hasn't paid attention since flex box
| satvikpendem wrote:
| 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.
| alwillis wrote:
| This should be a good start: https://nerdy.dev/cascading-
| secret-sauce
| perardi wrote:
| 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.
| nakedneuron wrote:
| Is there anything to be said about accessibility? Found the word
| only once in the comments.
| mattlondon wrote:
| 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.
| interstice wrote:
| Kinda odd they didn't call it masonry given it's already been
| called that forever. At least grid-lanes is reasonably self
| explanatory.
| pbowyer wrote:
| 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
| qingcharles wrote:
| 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.
| nehalem wrote:
| 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.
| hu3 wrote:
| 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".
| 8n4vidtmkvmk wrote:
| 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.
| robertoandred wrote:
| Safari got a big update last week.
| prakashn27 wrote:
| That makes sense. Safari is so smooth now in iOS. Moved from
| Firefox.
| noitpmeder wrote:
| Any ideas how I can track support for this in firefox?
| herpdyderp wrote:
| 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.
| temporallobe wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-20 23:00 UTC)