Hacker News Reader

Comment by noelwelsh | Hacker News Reader

How long does the standards committee think it can continue this approach to developing CSS? While these new properties are undoubtably useful I can't help thinking they point to a fundamental flaw in the design of CSS. Take `margin-inline` for example. This is only necessary because CSS provides insufficient means of abstraction. If the designer could themselves define something like

   margin-inline(width) = margin-left(width) margin-right(width)

(Ignoring text direction for simplicity) the problem goes away. I think the CSS committee should be focused on providing means of abstraction and composition, so that CSS users can create their own abstractions, instead of adding more and more properties to CSS.

View on HN

CSS Houdini is a set of apis aimed at what you mention (create your own CSS abstractions)

I think you’ve taken a bad example if you wish to show your point. You’ve actually simplified the answer for why it is how it is right out of it!

Consider margin-inline’s actual grammar (<'margin-top'>{1,2}) in a somewhat more functional notation (all still pseudocode):

  margin-inline(start = <length-percentage> | auto, end? = <length-percentage> | auto)
    = margin-inline-start(start)
    + margin-inline-end(end else start)

Are margin-{inline,block}-{start,end} the primitives? If you want them to be composed, oh boy, have fun (I’m not even going to try to show this all, and I don’t even want to know the sort of execution model that could make this work, but it’s vastly more complex than all the rest of CSS syntax put together):

  _inline-start = match (WRITING_MODE, DIRECTIONALITY, TEXT_ORIENTATION) {
      (…, …, …) => left,
      (…, …, …) => right,
      (…, …, …) => top,
      (…, …, …) => bottom,
  }

  margin-inline-start = margin-${_inline-start}

You could replace that margin-inline composition with margin-${_inline} composition. Et cetera ad tedium et a good deal of nauseum. It gets messy. Really messy. No, I don’t think it’s sensible to have Logical Properties be anything but a new set of primitives alongside top, left, right and bottom.

But now I want to show that there’s actually absolutely nothing wrong with margin-inline specifically:

It’s a shorthand. Just a perfectly ordinary shorthand for margin-inline-{start,end}, like background-position is shorthand for background-position-{x,y}, and background shorthand for background-{color,image,repeat,size,position,…}.

(Not all hyphens are hierarchical; margin-inline-start is margin→inline→start and background-size background→size, but box-sizing is not box→sizing, and text-decoration-thickness is only text-decoration→thickness, and I’m just going to close my eyes against the mistake that is border-{top,bottom}-{left,right}-radius. But where the hyphens are hierarchical, CSS philosophy just about demands corresponding shorthands.)

In fact, this specific one corresponds to something that was missing in the old order of things, which should really have been added but maybe wasn’t because there it wouldn’t have been a regular shorthand of X → X-* properties: margin-{horizontal,vertical}. See, the two- and three-value syntaxes of the margin shorthand get to express left and right margin in one value. Do you know how often people have accidentally clobbered top or bottom margin because they just wanted to specify left and right margin in one line, but wrote `margin: 0 auto` since there was no `margin-horizontal: auto;` and they didn’t like writing `margin-left: auto; margin-right: auto`? It’s more than a few. This is something that should have been present in the past, but wasn’t, and if CSS had had something like you describe for abstracting or composing it wouldn’t have helped because people certainly wouldn’t have used it for such cases; instead we just need CSS to include the right thing, like it does now:

  margin: vertical horizontal;
  /* Becomes, typically: */
  margin-block: vertical;
  margin-inline: horizontal;

  margin: top sides bottom;
  /* Becomes, typically (you could also merge the two block lines into `margin-block: top bottom`): */
  margin-block-start: top;
  margin-inline: sides;
  margin-block-end: bottom;

Really, something like margin-inline just falls out very neatly from CSS’s shorthand scheme. There’s nothing special or bad-abstractiony about it, and I hope CSS keeps on doing things like this.

Now then, abstraction and composition. Frankly, CSS properties have never been a place for this, beyond shorthands themselves. It’s just not a design goal at all, and a few attempts at bringing something like it in (e.g. @apply) have failed for various reasons, not least of which is they just don’t fit into CSS. Even in the case you’ve described, you had to (or maybe only chose to?) simplify the most important part of it out of existence.

My personal summary: you see a problem in CSS’s fundamental design, I don’t see it as a problem but a deliberate feature and I don’t think anyone’s suggested any alternative yet that’s actually workable and would be used and wouldn’t damage CSS.

> Now then, abstraction and composition. Frankly, CSS properties have never been a place for this, beyond shorthands themselves. It’s just not a design goal at all

It’s actually an anti goal; the W3C are intentionally avoiding making CSS more powerful. The rule of least power has been an explicit design principle for the World-Wide Web since the early days. If they wanted a more powerful language, they would have selected JSSS as the style language for the web, not CSS.

https://www.w3.org/DesignIssues/Principles.html

https://www.w3.org/2001/tag/doc/leastPower.html

The core of CSS layout, as I understand, is a few different layout algorithms (flex, columns, normal blocks, etc.) Properties are knobs to customize these algorithms. Internally I assume it's a constraint solving problem.

The kind of language I would be interested in would expose the constraint solving directly. So it would be much more like Prolog than, say, Rust.

You seem to working from the basis of reproducing CSS as it currently exists, and keeping design principles of CSS. This is reasonable POV, but these are not assumptions I share in my musing here.

Some parts of layout are constraint solving, but not all, not by a long shot. And CSS is about a lot more than layout. And most of the rest of CSS is absolutely nothing to do with constraint solving. So even though you can do layout as an exercise in constraint solving, you couldn’t just replace CSS with a constraint solver. And even if you did switch to some foundation of constraint solving, you’d just be replacing one form of complexity with another—one that’s more complex in the base case, more flexible in certain unusual cases, and generally has worse performance traps. Houdini, as mentioned by another, is an interesting concept that could blend the two worlds profitably.

(By the way: your original comment implied nothing whatsoever to me about a change in foundation toward constraint solving. That does make it a more interesting proposition, but also fairly firmly unachievable for the web.)

They should expose a simple, low-level layout API like GTK has had for 30 years.

Reply on news.ycombinator.com