Layout matters. Layout carries semantics. Right here on HN is an example, where the comment reply chain is indicated with indentation. The meaning of a comment such as "I disagree" varies depending on what it is replying to and therefore where it is in the layout.
Other examples where layout is content: Captions for photos. An online store where each price describes the cost of whatever item it is next to. Sports box scores and other statistical presentations. Interviews in question-and-answer format where the layout indicates who is speaking.
That's why we've gotten our layout engines so mixed up with our content and markup, because layout is content. How would one devise an abstraction for layout for all of these? You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing.
" You would need to express the semantic relationships within the data, like "comment-replied-to" and "photo-with-caption" and so on. That sounds tantamount to a full implication of natural language processing."
No you wouldn't and no it is not. It's dead simple:
<figure>
<img src='image.jpg' alt='missing' />
<figcaption>Caption goes here</figcaption>
</figure> <div class=comment>
<span class=user>T-hawk</span>
Right here on HN is an example, where the comment reply chain is indicated with indentation.
<div class=replies>
<div class=comment>
<span class=user>random28345</span>
HTML is a tree of element nodes, the identity of the post being replied to can be determined by
the position of element in the tree
<div class=replies />
</div>
</div>
</div>
.replies {
margin-left: 2em;
}In fact, if it did, I would consider the HTML broken.
<div class=comment.level1>
...
</div>
<div class=comment.level2>
...
</divCSS design genesis seems to be "ok we have this and that HTML presentation attribute; let's put it in an entirely new item-value format and separate HTML attributes/CSS properties syntactically".
From this arbitrary decision in language design the idea developed that markup attributes are part of the "semantic" content of a document, and not for styling, when, to the contrary, markup attributes were specifically designed for styling and other properties.
As a consequence, CSS has numerous redundancies, asymmetries, and absurdities such as CSS shapes, SVG properties you can style with CSS, the "content:" property, dogmatic and implementation-driven limitations for using presentational attributes on elements, etc.
I've done better looking/performing layouts 20 years ago with plain HTML 3.2. CSS is a mess.
I've used a lot of different layout frameworks over the years. Constraint systems are neat but hard to scale. All-code layout definitions are hard to read and reason about. Markup-level layout systems have their issues, but are easier for new programmers to learn and are the most instantly powerful out of the box. Most dewey-eyed replacements for production layout systems that I've encountered quickly founder when they try to cover all the corner cases that a mature framework would need to support. It's shockingly common to just end up with a kind of crappy version of bespoke CSS. Maybe with better syntax. Definitely with fewer features.
Alternately, if you're really complaining about the fact that you define styles in one file and markup in the other...I dunno, seems fine to me. I've seen systems that try to do all of that in one file (you can do it in HTML if you want to). They're not very readable. Splitting the styling from the basic structure is not a "clean" split, but it does simplify things enough to make your files much easier to scan. Sure, it doesn't live up to the old, pure idea about separating content from styling, but...who cares?