It'll probably end up slow and buggy. And likely explode when used with other layouting mechanisms. And it won't benefit from the quite awesome CSS debugging tools we have nowadays.
But yes, more powerful "client side" layouting functionality would be very welcome so we wouldn't have to wait the commitees for a decade to center an element etc. And there is the "Houndini" project to get this going, but the browser support is still extremely poor: https://houdini.glitch.me/
Because why introduce a custom abstraction to implement something with an imperative scripting language when you can achieve the same result with a declarative language built specifically to address this use case?
You'd rather maintain all the maths and JS dependencies for this than have browsers just render what you want?
It's obviously not viable to implement literally every single design imaginable straight in CSS. If I want to do something silly like placing my content on the faces of a hypercube it wouldn't be realistic for me to expect that to be part of CSS. Having me write some JS is completely acceptable - that's what it is for, after all!
It's not a matter of "would this be better in CSS", the answer to that is painfully obvious. The relevant question here becomes "is this common enough that it warrants a CSS implementation". And honestly? In the case of Masonry I am not convinced it is.
As they explain in the article, a row-less layout with columns is quite common in the non-web world. They acknowledge that some people are arguing that it's not needed because nobody's using it (on the web). Nobody's using it (on the web) because it's not possible in CSS.
The argument is that the popularity of the layout in contexts where it's possible is a strong argument for enabling it on the web as well. This is not a layout that they just thought of and are trying to invent.
Row-less layouts with columns are indeed quite common in the non-web world - see for example newspapers or other dense text. But that can already be done with current CSS features, and the row-first placement makes this proposal completely unsuitable for that. Masonry actively makes that worse, because it screws with the regular reading order.
They argue that nobody is doing it because it can't be done in CSS. I would argue that nobody is doing it because it's a bad idea. We've seen people work around it not being in CSS by using Javascript to make galleries for years now, if there were other use cases they'd surely have done the same?
With the exception of Pinterest-style galleries (and lets be honest, that's not exactly the pinnacle of UX either) I really don't see a widespread use for this feature. Their three other demos sure aren't convincing me.
I totally agree, and it does make sense to make adjustments that would make layouts more accessible. Mansonry-like layouts are common ("make it look like Pinterest") and so why not facilitate this entire class of use cases? The alternative is for everyone to either look for libraries or hax-together something that looks like Masonry but don't look too close and don't resize the view port too much.
Honestly, I'd say kudos to the WebKit folks for opening the discussion and being transparent about the process and the tradeoffs. It can certainly help refine (or inspire) future proposals.
It’s been nearly 30 years now that we’ve heard this refrain about CSS. Somehow the dream of “just tell the browser to render what I want” still remains elusive.
But maybe it’s just a few dozen more properties and mini-DSLs away this time! Pay no attention to those sirens and false prophets who still believe in anti-CSS “tell the computer how to do exactly what you want” programming…
I'm no prophet and CSS, just like any other language has its quirks. And yeah, generally it is my job to try and tell computers what to do so I like powerful tools that let me do what i want :)
But I do also see the benefit of a declarative system for most cases. Adaptive layouts are hard to do with imperative code, and very easily lead to e.g. infinite loops, so it's nice to work with a declarative system that guarantees a stable layout. That said, CSS is far from an ideal such system with so much ad-hoc and legacy baggage.
Well, as far as I at least understand it, the argument is that by using JS for this, you are indeed telling the computer what you want, you're just doing it by telling the computer it by telling it exactly how to do it. In contrast, in CSS, you're telling the computer what you want by… telling it what you want, and letting the browser engine worry about the how.
CSS isn't perfect, but it certainly works nicely for declaring layouts most of the time. It's of course alsp easy to get wrong, but doing all of the layout logic manually doesn't seem like a proper solution.
There is no reasonable fallback when JS is not present or hasn't yet executed, and that's not acceptable.
I can't stress enough how important this is for content experiences. Your content must display reasonably before all bells and whistles load, and when the bells and whistles load, your content had better not shift dramatically (ideally not at all).
Such browsers can also get by based on the semantic ordering of content within the document, which will more closely match the visual reality when a masonry type layout is used. The alternative of defining several columns leads to at least one column being shoved all the way at the end of the document after the previous column, whereas in a masonry layout that wouldn't be the case.
This is where a proper solution to this problem shines: After all, when you are on mobile (at least 60% of your users), they will get a single column anyway. Any solution that doesn't solve for them is a nonstarter.
That being said, it is the slow loading of JS and the folks using truly modern browsers with JS turned off that are more common, and for those people this isn't a problem.
But the screen size is an important part of how the library will lay out the bricks, and that isn't known until JS runs (this can kind of be done with client hints, but not on initial page load)
I was referring to the document still having the semantic structure. E.g. masonry.js also supports relative sizing, so it doesn't need to know the screen size beforehand.
With browser vendors you have to get them to do the same implementation. With JS/WASM it'll work across browsers given the more fundamental APIs work the same.
The main problem is that JS runs in a single thread and blocks the browser. Browsers jump through a ton of hoops to do scrolling and rendering on background threads while still allowing JS hooks and callbacks as required by web standards.
But, I think it's really the ONLY problem, and if you solve that problem, doing this stuff in JS would be the right answer. You'd be much more likely to get consistent behavior everywhere, without browser-specific quirks.
And part of the solution exists already! JS doesn't have to block the main thread any more, because you have things like Web Workers and WebAssembly.
Rather than adding another specific layout type, we should add a general-purpose way of hooking into the layout engine from a background task.
You can actually make a working masonry layout with css alone(even make it work with browser resize), if you do know the aspect ratio of each item. The hard part is handling the column count change and item prepend/insert because that would always require js to do.(since tha would change the position and column of every item)
There is no logic of js required to do handle whatever screen resize.
By doing it in CSS you eliminate the need to re-render your DOM and make your JavaScript do more useful tasks, and make your website more resilient to scripts crashing, freezing, or being disabled by the user. Also, one would think that a pipeline of JavaScript + rendering engine falls short to a more direct solution, as browsers cheat by not using JavaScript ;)
