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)
- A way to get values from sliders (type="range") (and style and modify them easily). Really, a way to get "value" from any <input> element.
- A way to have radio / checkboxes or labels inside labels work for multiple choices (or something other than making enormous arrays of radio selections and CSS choices)
- A way to have indexed arrays of numbers / choices (other than using a crazy complicated animation timing trick)
- String concatenation thats not so incredibly finicky and difficult to implement correctly
- Some way to retain the final "state" of a condition without resorting to playing an animation on "forwards" mode. Also, related, some way to not require the hidden checkbox hack everywhere.
- (Advanced, lower priority) A way to force var() calculation and optimizations other than making a zillion @property statements. "This expensive trig calculation is used a hundred times later on, better make it a separate ... nvm, it gets regex placed into every other calculation on the entire page ... " ¯\_(-_')_/¯
- If() and Function() ... wait, /inappropriate_swear, we're actually getting these after a quarter century.
Couple those together and you get poor performance. Or more specifically, unpredictable performance with lots of performance pitfalls that are hard to debug. Apple's AutoLayout is the real-world case study for this.
My guess is provides the power to do layouts that are difficult to do in CSS and also more computationally expensive, so it's not that constraints are slower, but that doing more complex layout requires more computation.
Edit: https://microsoft.github.io/apple-ux-guide/Layout.html (FWIW, by Microsoft?) seems to confirm this. Performance for normal layouts is normal, doing complex things with lots of chained, dependent constraints that modify many things is slow.
So, I don't think this is a good argument against constraint systems. People can do crazy things with more power. In fact, they already do crazy things because they can use Javascript which is ultimately powerful. Adding one more powerful system isn't going to change things. Companies do have limits for loading/rendering times for websites they publish, as loose as they are.
These are also the kind of cases where CSS layout ends up being slow. But a constraint solver based layout gives you more power to shoot yourself in the foot with.
> but that doing more complex layout requires more computation.
It's exactly this. The question is whether that makes for an ergonomic system to use for the developer. My assertion is that if there is no feedback when you create a slow layout, then it is not actually an easy system to use, and you're better off with something more constrained that guides you into the pit of success.
this problem somewhat already exists with layout thrashing https://web.dev/articles/avoid-large-complex-layouts-and-lay...
And given how layout thrashing and similar problems work I feel that you can code CSS in a constraint manner at least part of the time.
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?
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.)
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.
This seems to be implying that designers rely on quirks like the left alignment thing and not behave consistently... that seems like a crazy assertion to me.
And that appears to be the crux of the argument. A more general, consistent system wouldn't provide enough context for the browser to provide specific quirks, so instead a system with a different parameter for every single individual use case where quirks can be introduced to parameters individually is better.
>and weird defaults in your system
I'm not sure that there is any sufficiently complex logical system that will never have weird defaults, perhaps caused by the logic of some other seemingly sensible default. Complexity being the root cause of this overarching phenomenon.
I’ve seen sites that centred in a way that caused balanced overflow while assuming a wider viewport than I had. The result was a completely unusable site: the middle half was in-viewport (good), the right quarter was accessible by scrolling (poor), but the left quarter could not be accessed at all (abject failure).
This is the limitation that browsers/css impose for a rather arbutrary reason [1]
There's nothing preventing the browser from scrolling in any direction.
[1] It's not arbitrary, of course. But almost all these quirks stem from the fact that browers were made to display text and images in a single rendering pass. That's why even in 2025 the article talking about constraints talks about these things as self-evident good defaults with no alternatives:
--- start quote ---
If text is centered inside a box too small to contain it, we don't want it spilling out the left edge (it might go off-screen, where the user cannot scroll); left-aligning ensures it only spills out on the right.
That's a funky quirk but also, you may have never noticed it and if you did this edge case probably was better than what the layout would have been. Meaning, actually, building this edge case into the definition of text-align was a smart choice by the CSS designers.
--- end quote ---
It was a smart choice for 1995-1999. It's now codified and cannot be changed, but it doesn't mean it's a good choice now, or that it's even an edge case.
I also expect that from-scratch layout implementations (the theme of the article) would tend to only scroll in the positive direction, because doing otherwise is somewhat painful, and what kind of weird thing would want negative coordinates anyway? —So they would think.
This is why the CSS text-align behaviour is surprisingly sane. It solves a subtle problem that you would otherwise expect to encounter.
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.