5 ms·

Should CSS be constraints?

25 points by pavpanchekha 11mo ago

moritzwarhier 11mo ago
This was a rewarding read, kudos!
efortis 11mo ago
Nice margin notes trick: float: right; margin-right: -12em;
- pavpanchekha 10mo ago
  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 https://pavpanchekha.com/blog/css-floats.html
nicoburns 11mo ago
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 11mo ago
  Why would it be subject to more performance problems?
  - nicoburns 11mo ago
    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 11mo ago
      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 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 11mo ago
        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.
troupo 11mo ago
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 11mo ago
  > 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.
  - pavpanchekha 10mo ago
    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.
- chrismorgan 11mo ago
  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).
rendaw 11mo ago
> 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?
- pavpanchekha 10mo ago
  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?
  - mediumsmart 10mo ago
    fwiw: I do feel like I can speak on this some authority. predictability is again suffers. And recall that everything in parameterized.
Lerc 11mo ago
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 11mo ago
Having read https://every-layout.dev 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 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 11mo ago
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 11mo ago
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.
- pavpanchekha 10mo ago
  Fixed
frizlab 11mo ago
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.
- Klonoar 11mo ago
  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.
bvrmn 11mo ago
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.
jononor 11mo ago
Grid Style Sheets / GSS was an implementation of this idea. https://gss.github.io/guides/ccss 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.
- Inviz 10mo ago
  Hello Jon! This is Yarik. Cool to see you doing all this machine learning work these days.
  - jononor 10mo ago
    Hi Yarik! Nice to hear from you again. Hope all is well :)
- Inviz 10mo ago
  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.
  - jononor 10mo ago
    Good point about overflow. Did you ever do any write-ups about your flexbox experiments, or constraints for layout more generally?
commandlinefan 10mo ago
Reminds me of Java's GridBagLayout layout manager, which was practically unpredictable in actual use.
dfabulich 10mo ago
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.
- pavpanchekha 10mo ago
  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.

25 points by pavpanchekha 11mo ago

moritzwarhier 11mo ago

This was a rewarding read, kudos!

efortis 11mo ago

Nice margin notes trick: float: right; margin-right: -12em;

pavpanchekha 10mo ago
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 https://pavpanchekha.com/blog/css-floats.html

nicoburns 11mo ago

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 11mo ago
Why would it be subject to more performance problems?
- nicoburns 11mo ago
  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 11mo ago
    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 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 11mo ago
      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.

troupo 11mo ago

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 11mo ago
> 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.
- pavpanchekha 10mo ago
  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.
chrismorgan 11mo ago
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).

rendaw 11mo ago

> 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?

pavpanchekha 10mo ago
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?
- mediumsmart 10mo ago
  fwiw: I do feel like I can speak on this some authority. predictability is again suffers. And recall that everything in parameterized.

Lerc 11mo ago

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 11mo ago

Having read https://every-layout.dev 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 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 11mo ago

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 11mo ago

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.

pavpanchekha 10mo ago
Fixed

frizlab 11mo ago

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.

Klonoar 11mo ago
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.

bvrmn 11mo ago

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.

jononor 11mo ago

Grid Style Sheets / GSS was an implementation of this idea. https://gss.github.io/guides/ccss 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.

Inviz 10mo ago
Hello Jon! This is Yarik. Cool to see you doing all this machine learning work these days.
- jononor 10mo ago
  Hi Yarik! Nice to hear from you again. Hope all is well :)
Inviz 10mo ago
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.
- jononor 10mo ago
  Good point about overflow. Did you ever do any write-ups about your flexbox experiments, or constraints for layout more generally?

commandlinefan 10mo ago

Reminds me of Java's GridBagLayout layout manager, which was practically unpredictable in actual use.

dfabulich 10mo ago

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.

pavpanchekha 10mo ago
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.