[HN Gopher] Should CSS be a constraint system instead?
___________________________________________________________________
Should CSS be a constraint system instead?
Author : fanf2
Score : 30 points
Date : 2025-12-07 18:42 UTC (4 hours ago)
(HTM) web link (pavpanchekha.com)
(TXT) w3m dump (pavpanchekha.com)
| nicoburns wrote:
| 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)
| rendaw wrote:
| Why would it be subject to more performance problems?
| nicoburns wrote:
| 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.
| rendaw wrote:
| 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.
| nicoburns wrote:
| 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.
| bryanrasmussen wrote:
| >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.
| Rumudiez wrote:
| (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
| nicoburns wrote:
| 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").
| 1718627440 wrote:
| Isn't size of the parent element, what the percent values are
| relative to?
| araes wrote:
| 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.
| troupo wrote:
| 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.
| rendaw wrote:
| > 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.
| chrismorgan wrote:
| 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).
| troupo wrote:
| > 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.
| chrismorgan wrote:
| 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.
| bryanrasmussen wrote:
| >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.
| troupo wrote:
| 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
| rendaw wrote:
| > 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?
| Lerc wrote:
| 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.
| adityaathalye wrote:
| 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.)
| ptrl600 wrote:
| 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...
| wizzwizz4 wrote:
| 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.
| frizlab wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-07 23:01 UTC)