Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should CSS be constraints?

pavpanchekha.com

Post reply on HN
Print view View original

11–20 of 46 posts

Re: Should CSS be constraints?

#11

Post by Lerc »

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.

Re: Should CSS be constraints?

#12

Post by nicoburns »

rendaw wrote: post #10
nicoburns wrote: post #9

Earlier quoted context omitted.

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 th…

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,…

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.

Re: Should CSS be constraints?

#13

Post by Rumudiez »

nicoburns wrote: post #4

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…

(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

Re: Should CSS be constraints?

#14

Post by chrismorgan »

troupo wrote: post #5

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 im…

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).

Re: Should CSS be constraints?

#15

Post by bryanrasmussen »

nicoburns wrote: post #12
rendaw wrote: post #10

Earlier quoted context omitted.

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,…

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…

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

Re: Should CSS be constraints?

#16

Post by [deleted] »

nicoburns wrote: post #4

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…

[deleted]

Re: Should CSS be constraints?

#17

Post by nicoburns »

Rumudiez wrote: post #13
nicoburns wrote: post #4

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…

(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

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").

Re: Should CSS be constraints?

#18

Post by bryanrasmussen »

troupo wrote: post #5

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 im…

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

Re: Should CSS be constraints?

#19

Post by adityaathalye »

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.)

Re: Should CSS be constraints?

#20

Post by ptrl600 »

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...
Post reply on HN