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

21–30 of 46 posts

Re: Should CSS be constraints?

#21

Post by 1718627440 »

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

Isn't size of the parent element, what the percent values are relative to?

Re: Should CSS be constraints?

#23

Post by troupo »

chrismorgan wrote: post #14
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 viewp…

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

Re: Should CSS be constraints?

#24

Post by troupo »

bryanrasmussen wrote: post #18
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.

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

Re: Should CSS be constraints?

#26

Post by araes »

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…

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

Re: Should CSS be constraints?

#27

Post by chrismorgan »

troupo wrote: post #23
chrismorgan wrote: post #14

Earlier quoted context omitted.

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

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

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.

Re: Should CSS be constraints?

#28

Post by bvrmn »

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.

Re: Should CSS be constraints?

#29

Post by jononor »

Grid Style Sheets / GSS was an implementation of this idea. 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.

Re: Should CSS be constraints?

#30

Post by Klonoar »

frizlab wrote: post #25

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.

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.

Post reply on HN