Should CSS be constraints?(pavpanchekha.com)
pavpanchekha.com
Should CSS be constraints?
https://pavpanchekha.com/blog/why-css-bad.html
45 comments
What CSS needs (opinion, caveat, really far away in advanced features) is:
- 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.
- 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.
It looks like HTML may be getting the ability to manipulate the class/attributes of elements in response to clicks (declaratively, without JS). Which would solve a lot of the interactivity issues (checkbox hack, etc).
See: https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com...
See: https://developer.mozilla.org/en-US/docs/Web/API/Invoker_Com...
Thanks. Saw this, thought it looked cool. Just could not find what it can do other than "popover" "popovertarget" without using JS.
The examples provided for custom events all seem to use JS anyways. Ex:
[1] https://developer.chrome.com/blog/command-and-commandfor
Edit: Here's an example of the overlapping popover functionality. https://araesmojo-eng.github.io/
Main Page -> General Tests Menu -> Open Popover 1 | Open Popover 2
Should both open popovers simultaneously on top of each other while dismissing neither, and also change the state of elements on the page at the same time.
The examples provided for custom events all seem to use JS anyways. Ex:
<button commandfor="the-image" command="--rotate-landscape">
...
if ( event.command == "--rotate-landscape" ) { image.style.rotate = "-90deg" }
[1] https://developer.chrome.com/blog/command-and-commandfor
Edit: Here's an example of the overlapping popover functionality. https://araesmojo-eng.github.io/
Main Page -> General Tests Menu -> Open Popover 1 | Open Popover 2
Should both open popovers simultaneously on top of each other while dismissing neither, and also change the state of elements on the page at the same time.
(1) could be answered with container query units. Set `container-type: inline-size;` on the parent element (falls back to the whole viewport if unset), then use, e.g., `width: 50cqw; height: 50cqh` in children. The value is a percentage of the given axis
Isn't size of the parent element, what the percent values are relative to?
I don't think that works if you want to mix "proportion of available space" units with siblings that have a fixed size (a super-common use case for flexbox - having a fixed size box followed by another box that takes up "the rest of the space").
Why would it be subject to more performance problems?
My understanding is that constraint based layout performance is heavily dependant on providing lots of constraints so that the solver doesn't have too much work to do. But that the reason people like constraint-based layout models is that they don't have to provide many constraints.
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.
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.
A constraint like "make the top of this 20px below the top of the screen" should be no more computationally expensive than "margin-top: 20px". I'm not familiar with Apple's Auto-layout but why is it so slow? Maybe you have an example of what you're thinking of.
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.
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.
It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).
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.
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.
>It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).
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 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.
[deleted]
> 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?
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?
Author here. The problem isn't the technical challenge of writing a constraint solver. It's making sure that the resulting layout looks good, despite contradictory guidance from the designer.
Yes, a constraint solver can figure out which constraints it's violating. And for under-specification, it can produce a layout that satisfies the constraints. But the layout the constraint-solver chooses might be really bad—if all the text is placed at 0,0 the result is unreadable. And over-specified constraints might occur for some user on some weird device after deployment, when there's no developer to respond to errors.
Determining whether a set of constraints could be over- or under-specified for some set of parameters is computationally very challenging (this is what SAT and SMT solvers do, basically). But besides the computational challenge, I think it is practically very challenging—this is drawing off my experience doing this for four years—to write non-conflicting constraints for real-world designs. How would you write constraints for text wrapping around a figure? For mixed-font text lining up nicely?
Yes, a constraint solver can figure out which constraints it's violating. And for under-specification, it can produce a layout that satisfies the constraints. But the layout the constraint-solver chooses might be really bad—if all the text is placed at 0,0 the result is unreadable. And over-specified constraints might occur for some user on some weird device after deployment, when there's no developer to respond to errors.
Determining whether a set of constraints could be over- or under-specified for some set of parameters is computationally very challenging (this is what SAT and SMT solvers do, basically). But besides the computational challenge, I think it is practically very challenging—this is drawing off my experience doing this for four years—to write non-conflicting constraints for real-world designs. How would you write constraints for text wrapping around a figure? For mixed-font text lining up nicely?
fwiw:
I do feel like I can speak on this some authority.
predictability is again suffers.
And recall that everything in parameterized.
I do feel like I can speak on this some authority.
predictability is again suffers.
And recall that everything in parameterized.
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...
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.
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.
Layout can only expand/overflow to the right and down, not up or left. Although not fundamental, this has been a standard and useful design limitation in almost all software from the start: infinite drawing canvases are the only counterexample that immediately occurs to me. (“Pull to refresh” is almost another exception.)
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).
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).
> 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.
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.
As I said, it’s not a fundamental limitation, but it is ubiquitous in computing with only a few specialised and obvious exceptions, so breaking it has consequences: you will confuse people. Probably not much, but people don’t try scrolling up from the top of a page, nor left from the left edge.
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 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.
Author here. You're right that a lot of CSS's edge cases and implicit rules stem from other choices and implicit rules that maybe need to be reconsidered. But take this logic a step further. The way text with mixed font sizes is laid out is kinda weird—should we just get rid of that? Mixed Chinese-Latin text is weird (search "idiographic baseline"); should we get rid of that? In fact, variable-size characters are weird, maybe just stick to all-Chinese? I'm joking, of course, but my point isn't that a simpler system is inconceivable, just that it would be inconvenient.
Author here. This specific quirk of CSS is minor, and probably if CSS didn't have this quirk it'd be fine. But I'd guess that you've at least once in your life been on your phone and been browsing a website which used a really long word (or a really long line of code!) in centered text (maybe a heading) and you've scrolled right to read the whole thing. Are you sure your website doesn't have such a thing, if you have centered text somewhere?
So, yes, CSS could have fewer edge cases and workarounds---what I refer to in the post as less implicit knowledge---and then it would be simpler. But the resulting layouts would probably be worse. And a radical simplification like a constraint system would probably be even simpler and the results (I assert) would be even worse. It's fine to want a better life for browser developers, but I don't think it's unthinkable for CSS to create new edge cases and sometimes-surprising behavior if it also results in, typically, better outcomes.
So, yes, CSS could have fewer edge cases and workarounds---what I refer to in the post as less implicit knowledge---and then it would be simpler. But the resulting layouts would probably be worse. And a radical simplification like a constraint system would probably be even simpler and the results (I assert) would be even worse. It's fine to want a better life for browser developers, but I don't think it's unthinkable for CSS to create new edge cases and sometimes-surprising behavior if it also results in, typically, better outcomes.
> designers are, by necessity, going to rely on implicit knowledge encoded somewhere on what to do in edge cases
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.
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.
Author here. I suppose it depends on what "rely on" means, but... have you ever used CSS to center text? Did you think much at all about what happens if the zoom level is high enough and the screen size small enough that the text doesn't fit? I assume not (I don't think I'd ever thought about that before I read that part of the standard), so in that sense you were relying on this behavior. I do think that in most cases where it activates, the quirk implemented by CSS probably improves the layout.
>If you don't make assumptions
then when edge cases happen that have not been programmed for then the system will probably crash.
>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.
>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.
Yes, but you want as few of those as possible. And you don't want to stick to default assumptions from 35+ years ago: https://news.ycombinator.com/item?id=46185345
Grid Style Sheets / GSS was an implementation of this idea.
https://gss.github.io/guides/ccss
I saw was because I do not think anyone has used or maintained it since the company behind went belly up. But the code is still out there as open source, probably can be learned from.
Disclaimer: I used to contract for them, but in other areas.
I saw was because I do not think anyone has used or maintained it since the company behind went belly up. But the code is still out there as open source, probably can be learned from.
Disclaimer: I used to contract for them, but in other areas.
If I am to provide a summary of why layout shouldnt be linear constraints, is that it can't faithfully represent content overflowing onto multiple lines. I.e. it's inherently one dimensional. I.e. you can't really have a layout that adaprts to the screen size without creating a lot of separate breakpoints. This is a big limitation, that for example flexbox doesnt have. When I left Grid i immediately went and reproduced a lot of stuff we've been doing in (new then) flexbox layout engine, and i was like: Oh my god, this is so much more powerful.
Good point about overflow. Did you ever do any write-ups about your flexbox experiments, or constraints for layout more generally?
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.
Fixed
Tailwind utilities related to flexbox/grid solved most of layout issues for me. Usually it's flex-1/flex-none to mark dynamic/static parts and gaps to separate elements. Constraint based systems usually require more input data to maintain.
Apple's native SwiftUI framework and Google's Jetpack Compose framework stumbled upon basically the same layout system, "Constraints down, sizes up":
1. Proposal: The parent component proposes a size/constraints to the child
2. Measurement: The child component picks its own size based on those constraints
3. Placement: The parent component then positions the child in its coordinate space
It's all done in a single pass. It scales great. It fits great with React-like reactive UI frameworks. (SwiftUI and Jetpack Compose are based on React.)
This is what CSS needs.
1. Proposal: The parent component proposes a size/constraints to the child
2. Measurement: The child component picks its own size based on those constraints
3. Placement: The parent component then positions the child in its coordinate space
It's all done in a single pass. It scales great. It fits great with React-like reactive UI frameworks. (SwiftUI and Jetpack Compose are based on React.)
This is what CSS needs.
That pretty much is how CSS works! At the most basic level, Flow level is about widths down, heights up. But this basic model doesn't let you do a lot of things some people want to do, like distributing left-over space in a container equally among children (imagine a table). So then CSS added more stuff, like Flex-box, which also fundamentally works like this though adds a second pass.
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.
I legitimately find myself wishing I had access to this any time I have to build UI in other languages.
I remember being so skeptical and annoyed when first using it but over the years I became sold on it. It’s the only system I’ve used where I could come back years down the road and figuring out the layout was still straightforward enough debugging wise.
I remember being so skeptical and annoyed when first using it but over the years I became sold on it. It’s the only system I’ve used where I could come back years down the road and figuring out the layout was still straightforward enough debugging wise.
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.)
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.)
Reminds me of Java's GridBagLayout layout manager, which was practically unpredictable in actual use.
Nice margin notes trick:
float: right;
margin-right: -12em;Author here—it is from Tufte CSS. I have a blog post [1] about how floats work. It is a nice example of there being unintuitive and also more-intuitive ways to achieve things in CSS. These days I believe CSS Anchor Positioning provides a simpler way to do this, but I haven't used it yet.
[1]: https://pavpanchekha.com/blog/css-floats.html
[1]: https://pavpanchekha.com/blog/css-floats.html
This was a rewarding read, kudos!
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 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.
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)