Should CSS be constraints?
pavpanchekha.com
Should CSS be constraints?
1–10 of 46 posts
Re: Should CSS be constraints?
#2This was a rewarding read, kudos!
Re: Should CSS be constraints?
#3Nice margin notes trick:
float: right;
margin-right: -12em;Re: Should CSS be constraints?
#4The 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)
Re: Should CSS be constraints?
#5I'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.
Re: Should CSS be constraints?
#6The 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…
Why would it be subject to more performance problems?
Re: Should CSS be constraints?
#7> 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?
Re: Should CSS be constraints?
#8I'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…
> 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.
Re: Should CSS be constraints?
#9The 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…
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.
Re: Should CSS be constraints?
#10Earlier quoted context omitted.
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 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, 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.