Don't get me wrong. I praise CSS for it has given designers ways to come up with new UI idioms (something I'm personally fascinated with). But I will say this has happened in spite of, rather than because of, CSS's qualities. Designers other than outright CSS nerds are struggling with CSS, and CSS is lacking badly from a basic maintainability perspective IMHO. CSS as a language puts an unnecessarily high cognitive burden on casual web developers by lacking a construct to capture the "intent" of a couple coordinated CSS rules; as a result, unless you're doing CSS every day, you're easily lost in your (or someone else's) CSS.
This isn't helped by seemingly arbitrary decisions as to what goes into CSS vs. HTML. For example, responsive images eg. the `picture` element became an HTML element, but arguably should have been subject to CSS media queries instead.
Which is kindof my initial point: that the HTML/CSS dichotomy is accidental and pointless from a language theory PoV.
What I am talking about is CSS Zen Garden and the movement around it of frontend web developers professionalizing, rejecting table layouts and non-standard browser features.
This was enabled by CSS being barely powerful enough, and people creative enough to make it work. Eventually the movement won, non-IE browsers won market share and the way was paved for a more healthy evolutionary path of the web which has yielded these new features.
You look at CSS from a perspective that it's hard, as if there exists a solution somewhere that is easier. Before CSS there were simply the less powerful HTML features, the 'easier' but less semantic and non-adaptive tools like Flash or SVG, and the always present and expertise requiring method of simply imperatively coding the styling in WinForms or whatever.
CSS was absolutely crucial.
That had nothing to do with the fact that HTML and CSS are independent.
Tables are way way more complicated than anything in CSS. In fact, tables are unspecified.
This [1] is a work in progress draft and incomplete. You'll be forgiven if your eyes glaze over while reading it.
CSS has its problems (I'm the first to admit that), but on balance I think it's the best layout language that has been devised for documents.
What would have been better would be a flat map identifier -> binary (or string or whatever, your choice) as the content, and then "CSS" (quotes because it wouldn't be the CSS we know now) would declare the layout/look and would read the content map for insertion into placeholders declared in the "CSS". I've omitted programmable considerations cause this is a HN comment and not intended to be formal proposal. Not surprisingly, the web has kinda already shifted towards this, through the use of JSON APIs in JS.
The current split is CSS is presentation while HTML is content + structure. Unless I'm misunderstanding, this proposal would separate content and structure. I'm not sure where presentation would go; you could certainly make a case for it being grouped with either.
There's also plenty of questions around what's content and what's structure and what's presentation. For instance, a section heading is potentially all three. I personally would probably go for grouping presentation with the content, and call structure "layout" to disambiguate it. A section heading is maybe structure, but it's definitely not layout.
A tree node structure for mapping content seems like it'd be the most efficient in all the ways I can imagine it.
How the panes are laid out could be accomplished through any number of methods. Absolute, flow, flex, grid, constraint solving... Or even parent panes using different methods for their sub-panes!
The point isn't to flatten the layout. The layout can be as complex as desired. The point is to remove content from the layout; a named mapping is just an easy way to associate content to layout panes for injection.