Layout is about the relationship between TWO THINGS. If you have a layout language that deals with only one thing at a time, then you have failed.
"CSS, a language for specifying visual appearance on the web, is … so complex that it has never been implemented correctly; yet, successive versions specify even more complexity. At the same time, it is so underpowered that many elementary graphic designs are impossible or prohibitively difficult, and context-sensitivity (or anything computational) must be addressed externally. Most CSS lore is dedicated to describing the tangles of brittle hacks needed to circumvent incompatibilities or approximate a desired appearance."
I don't think CSS layout issues could be described as a 'fundamental design flaw'.
CSS originally didn't really address layout at all - it was about styling the content of documents. IMO it's a stretch to say layout was 'fundamental' to CSS.
The fundamental parts of CSS are the way multiple styles from multiple places are inherited down a nested tree structure and applied or overridden based on their specificity. For it's time and the constraints it had to work with (ie preexisting HTML handling the structure), I think it was an elegant solution at heart. Especially when looking at it on context of the problems it was solving.
Sure the world moved on and demanded more and more from CSS with little help from popular browsers, but that all came later on as the web exploded.
> Layout is about the relationship between TWO THINGS. If you have a layout language that deals with only one thing at a time, then you have failed.
Why do you think CSS only deals with one thing at a time? CSS is all about how the element behaves in relation to it's relatives (eg parents and siblings etc as defined by the HTML). But it is about matching rules against the existing document structure rather than defining the document structure.
That's not what a layout language is for. A layout language needs to be able to specify "A goes 10 px to the left of B".
It's specified in two halves: the parent lays down general dictates about how its children will be laid out (via 'display' and the layout-specific properties like 'flex-flow'), while the child responds with details about how it would like to be laid out (via width/height/etc and layout-specific properties like 'flex').
We never did end up creating a layout mode that deals in direct relationships between elements, for a number of reasons both good and bad, but that's why the CSSWG's Houdini Task Force exists - one of our deliverables is Custom Layout, so you can write JS-driven layouts that interact with the rest of CSS properly. (Today you can't without a lot of hacks, and those only get you partway there.) Custom Layout will be one of our last things to do tho, because it's the hardest, both to specify and to implement performantly (in particular, without slowing down pages that don't use Custom Layout at all, and ideally not kicking the whole page into a slow mode if one widget uses Custom Layout). So it's still a few years out - we've only got rough ideas for how the spec will work right now.
(Some of the reasons we haven't done direct "X is 10px to the left of Y" layouts: (1) CSS's syntax isn't built well for it. The rule/declaration dichotomy privileges one element, the one matched by the selector. There aren't good, reliable ways to select a unique element for the other end of the relationship. IDs aren't good, because they're page-global; everything else is too promiscuous. (2) Too easy for things to overlap in bad ways on unexpected screen sizes. Authors often develop for the computer they're on, and most don't pay much attention to screen sizes they don't own devices for. Existing CSS layout modes all degrade more-or-less gracefully, because the parent has ultimate control over where the children go and can avoid making them overlap. The exception is abspos/fixpos, which are the closest to the direct-relationship layout mode, and which can easily cause bad layout - see almost any page using position:fixed and designed for desktop, then viewed on a phone's screen. (3) It requires being extra-opinionated about how to handle cycles and such. Individual libraries do this fine (and often respond with a simple "don't write cycles"), but specifying it unambiguously and usefully is pretty hard.)
- "A goes TO THE LEFT of B"
- "The header goes ABOVE the content"
- "The list goes INSIDE the table"
- "The menu goes BEFORE the advert"
A layout language without prepositions isn't much of a layout language at all.