> I still say that the answer is just semantic HTML/CSS. You're coming at the problem from the wrong direction naming things for how you want them to appear. Name them for what they are. Write the HTML agnostic to how it's intended to appear, and then just use CSS as a tool to style the already existing document.
I would love to do that, but it's simply not practical, at least not without CSS hacks that are hard to reason about.
---
A few reasons (non-exhaustive list):
In general, the separation of HTML and CSS is theoretical, not practical. They are tightly coupled descriptions of your overall layout, which is why there are so many incomplete attempts to manage the resulting complexity (see: this article).
HTML is not just content. It complects content plus layout. If you separate content from layout you get something like XML+XSLT, not HTML.
HTML is a strict tree structure and CSS can only query it in two directions: "down" and "next". A lot of layout and styling concerns are graph relationships. You need to adorn things _up_ the tree (in the form of nodes/attributes/classes etc.) in order to give enough context for layout and styling down the tree. And in some cases that doesn't work either.
Many CSS properties describe styling relationships between nodes. For example flex and grid make no sense in isolation. This couples the structure of your HTML with its styling in a profound way.
Some HTML tags don't represent their structure well, for example: <dl>, <dt>, <dd>. The natural way of thinking of these elements, laying them out and styling them, is to group each <dt> and <dd> together.
---
I agree half-way with you though. It's often useful to generate _just_ the "semantic" content at first: just use the tags and structure you need to lay out the structure of your content in a meaningful way. But as soon as you start caring about design, you will have to add tags, attributes classes etc. that are only there to serve styling.
I would love to do that, but it's simply not practical, at least not without CSS hacks that are hard to reason about.
---
A few reasons (non-exhaustive list):
In general, the separation of HTML and CSS is theoretical, not practical. They are tightly coupled descriptions of your overall layout, which is why there are so many incomplete attempts to manage the resulting complexity (see: this article).
HTML is not just content. It complects content plus layout. If you separate content from layout you get something like XML+XSLT, not HTML.
HTML is a strict tree structure and CSS can only query it in two directions: "down" and "next". A lot of layout and styling concerns are graph relationships. You need to adorn things _up_ the tree (in the form of nodes/attributes/classes etc.) in order to give enough context for layout and styling down the tree. And in some cases that doesn't work either.
Many CSS properties describe styling relationships between nodes. For example flex and grid make no sense in isolation. This couples the structure of your HTML with its styling in a profound way.
Some HTML tags don't represent their structure well, for example: <dl>, <dt>, <dd>. The natural way of thinking of these elements, laying them out and styling them, is to group each <dt> and <dd> together.
---
I agree half-way with you though. It's often useful to generate _just_ the "semantic" content at first: just use the tags and structure you need to lay out the structure of your content in a meaningful way. But as soon as you start caring about design, you will have to add tags, attributes classes etc. that are only there to serve styling.