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.

(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

Why would it be subject to more performance problems?

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?

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.

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

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

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

Fixed

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.

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.

Hello Jon! This is Yarik. Cool to see you doing all this machine learning work these days.

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.

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