Hacker News Reader

Comment by m3h | Hacker News Reader

I am wondering whether it makes sense to keep adding more "layout" options to CSS, given that we have the legacy floats and then the modern flexbox and grid layout. If there are still cases that are not covered, perhaps a better solution to to have one final constraints-based system that covers all layout cases, even if it comes at the cost of complexity. The CSS frameworks and utility libraries will then be built on top of it to provide the next generation of "masonry" grid, etc.

View on HN

I'm dubious that a constraints system would ever be considered, CSS has so far had some strong goals around it's predictably on layout cost.. that said, Houdini layout proposal is the closest to your comment, offloading layout to an isolated js context https://github.com/w3c/css-houdini-drafts/blob/main/css-layo... .. but honestly flex and grid, plus other things like containment have solved so many things for folks now that there's just far less demand for improvement than the days before flex

Oh man - I remember attending a CSS meetup in like 2014 at the Google offices in Sydney where someone from the CSS WG presented Houdini Layout. I would be surprised if that ever ships.

The whole point of this initiative is to stop using out of date float-hacks, or soon-to-be out of date hacks to CSS grid or flexbox. Firefox's masonry layout is in fact implemented in such a way that basically covers all layout cases by simply adding a new attribute that collapses grid rows.

>Firefox's masonry layout is in fact implemented in such a way that basically covers all layout cases

That's good to know.

> Firefox masonry... by simply adding a new attribute that collapses grid rows

Not just Firefox, the proposal here is

    grid-template-rows: off;

It IS grid, lvl 3. You can achieve it with:

  display: grid;

  grid-template-rows: masonry;

This is however limited to webkit. I implemented it and ditched in October 2023 already for my private news feed in gallery mode.

What do you use instead?

I have it behind a CSS test for the existence of the CSS property so it is only enabled if the browser supports it.

JavaScript is the final layout system. No declarative language can ever handle every use case. Fortunately I rarely need to resort to JS since grid came out.

I’m not sure a constraint based system would do much good as it would sit awkwardly in the middle of grid and JS.

> No declarative language can ever handle every use case.

Prolog would beg to differ.

And CSS https://accodeing.com/blog/2015/css3-proven-to-be-turing-com...

This research is cool, but I always feel it needs an asterisk. Requiring a click or event or some external clock feels like a cop out. I've seen a similar thing with PowerPoint.

It would be a bit like saying a language with iterations but neither first-class functions nor recursion is Turing complete as long as an external stack is provided. Or maybe it allows a stack (or recursion) but requires external intervention for function application.

Cool hacking nevertheless.

Prolog has well-defined execution order with side-effects. It's an imperative language masquerading as a declarative one.

MiniKanren, then?

So would LISP, Haskell, and Erlang.

Declarative in this context means no recursion or infinite loops. So none of these are declarative.

With great power comes poor performance. I can immediately tell when a page uses JS for layouting (or replacing other browser functions like scrolling) as there is a noticable latency increase and the page lags about 200-300 ms behind when resizing the window.

You can always generate the layout in javascript if you have some requirements which aren’t directly supported by CSS layout.

Reply on news.ycombinator.com