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.
You'd rather maintain all the maths and JS dependencies for this than have browsers just render what you want?