Should CSS be a constraint system instead?

The problem with a constraint system is that it would likely be even more subject to performance problems than the current setup.

IMO what CSS layout really needs is:

1. A "proportion of available space" unit. That is, something like the fr unit in CSS grid except applicable to the width/height properties so it can be used in all layout modes and without an implying content-based minimum size (like fr does).

2. A new "display: stack" (name provisional) layout mode that simply stacks boxes one after the other like "display: block" but that works in both axes, and doesn't have quirks of block layout (margin-collapsing, floats, inline-block splitting, etc).

When combining 1 and 2 you'd have a much more intutive layout system that would still give you most of the power of Flexbox and could be implemented with much better performance.

(and you'd still be able to use the existing layout modes if/when you needed to extra power)

Having read https://every-layout.dev (no affiliation), I cannot help but use CSS as a constraint system (ish).

My site for example, uses four "structural" elements - "the center", "the stack", "the box", and "the cluster".

That's maybe 50 lines of CSS controlling layout of the whole site, in concert with a proportional grid, much like how I do with print layouts. Except, with CSS combinators, flexbox, and semantic HTML. I don't use a "reset" CSS, nor do I use media queries.

Have a look-see. It's entirely hand-rolled CSS:

https://www.evalapply.org/static/css/style.css

nb. I'm mainly a devops/backend person. Any expert critique on said CSS is welcome. (Also site accessibility is a long-pending item... pointers there are welcome too.)

> But with constraint-based systems, the layout might be literally under- or over-determined, in the sense that there might be more than one, or less than one, layouts that satisfy your rules.

This is under the "what's wrong" section but it doesn't actually say what's wrong.

Obviously if over-specified, the extra constraints can't be followed which wouldn't be intuitive (and... css does this constantly, so it doesn't seem relevant). But surely the system could just do one of them and alert the developer which constraints can't be followed?

And for under-specification, it could use 0. Nobody's going to write a specification and then publish a site without looking at it once.

And actually, can't under/over specified constraints be statically checked? Doesn't SolveSpace do this?

The problem is that CSS is serving multiple masters. It is specifying how the designer is wanting a page to be laid out while doing do in a way that conforms to the way the receiver wants it to be laid out.

I think there is an opportunity for pages to have regions of priority. I thing there would be merit in something where client devices have freedom to decide some parts of the layout but others are ridgidly controlled by designers.

You can kind of do this already with CSS with absolute and relative positioning and calc() for control and flex for, well, flexibility. It's not in a form that particularly facilitates it though. I'd like a better ability to choose whether elements to push the bounds of their containers or whether containers squeeze their content, and what to do when in conflict. scrolling, clipping, exceeding bounds, scaling to fit are all options.

I love auto-layout in iOS, which is, indeed, a constraint system. It is not easy to get the hang of it, but once one does, it is extremely powerful and delightful to use.

The Python library "enaml", which is kind of wrapper around QT, has a constraint-based layout engine: I think it's successful, I made a fairly complicated GUI and it didn't have any performance issues. Of course I was only developing for desktop...

Nitpick for the author: you've got a few &utm_source= strings in your links, which should probably point at your own site, or be removed.

I'm not convinced about the "edge case" at all. CSS made it an edge case for no reason at all, and made a silly default out of it.

If the box isn't big enough to contain center-aligned text, of course it should spill on both sides, because it's both expected and consistent.

And now the author pretends "we left-align text and spill on the right" as the only possible default behaviour that somehow makes constraints impossible/extremely difficult.

If you don't make assumptions and weird defaults in your system, you don't have to fight them and make weird workarounds.