Should CSS be Constraints?

From the title and first paragraph, I was prepared to dislike and disagree, but it’s very solid, describing how constraints systems are actually not as suitable for things like layout as people can imagine, and the directions CSS development have been heading in are largely good.

My favourite bit is how text-align: center is more complex than people expect, left-aligning in case of overflow, a detail that could easily be overlooked if you were implementing it yourself. From time to time people propose replacing the web stack with a canvas and a few other primitives, and letting them draw what they want. (Sometimes it’s even people like hixie who I think should know better.) Quite apart from functionality that can’t be correctly implemented in canvas space, it would suffer from the same sorts of problems of reinventing old errors. For all its warts, the web stack does a pretty good job for documents and apps alike.

---

To analogize a bit… […] One solution to this problem is to forsake JavaScript forever, to use Lisp or Haskell or Rust or something. But another is, like, Typescript and ESLint, which together make it really easy to avoid all the bad features of JavaScript and use good versions instead. C has a similar situation, where strcpy has really simple but also bad semantics. One option is forsaking C and rewriting in Rust. Another is using strlcpy.

There’s a defect in this line of argument: some of the problems are too deep to truly root out, and you’re just papering over the problem.

For JavaScript, take number and string confusion. Yes, type annotations (TypeScript) and === (enforced by ESLint) can both protect you; but Array.prototype.sort will still sort your array of numbers lexicographically. (In theory a type-aware linter could warn on Array<T>.prototype.sort if T is not string. Then I’d just move onto the next wart!)

For C, let’s stick with strings: even when you use strlcpy, you’re still dealing with null-terminated strings which are fundamentally disconnected from their allocation sizes, and that’s playing with fire: it’s too easy to accidentally misuse them. Rust strings are better not because they reliably handle null-termination, but because they threw it away and encapsulate pointer and length. Now you can do that in C—something like struct { char* ptr, size_t len }—but in practice at your system boundaries you’ll be forever falling back to just a char* because that’s the broader C convention, and if you’re not null-terminating you may well have a hard time.

Fortunately, this was just an analogy, and the main point is unaffected by this quibble.

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