3 ms·
> 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. Na
by dgb23 2y ago
> 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.
- extra88 2y ago> CSS can only query it in two directions: "down" and "next". :has() has entered the chat.
- dgb23 2y ago:has() is a lookahead. See my other comment.
- emmacharp 2y agoSome thoughts on reasons above: With recent display roles (like grid, flex, contents, etc.) the HTML needed exclusively for layout problems is really minimized if not completely nonexistent. With `:has()` you can query "up" and "previous". Some structure in your HTML is absolutely necessary, yes. But I'm not sure it is a problem. Data, content and states have structure. Classes and attributes should be used for styling purposes, yes. Namespacing and linting can do most of the heavy work of keeping things tidy.
- dgb23 2y ago> With recent display roles (like grid, flex, contents, etc.) the HTML needed exclusively for layout problems is really minimized if not completely nonexistent. I'm not talking strictly about _problems_ but about requirements/relationships. Flex/grid describe parent/child relationships between elements. They inherently couple styling with structure, so that you are sometimes forced to introduce tags for stylistic grouping. > With `:has()` you can query "up" and "previous". :has() is a lookahead. Please correct me if I'm mistaken: But there are no selector rules that you can put on an element which looks up or at previous siblings that I know of. The only CSS features that query up/previous are @media and @container rules.
- emmacharp 2y agoYou may have to group elements, yes. But generally speaking, they already are grouped in some logical sense. And you can do a lot now with grid, without having to wrap child elements in containers. It's not absolutely separated but to great degree it is (in my experience at the very least). And yes, you can select previous elements with :has(). Here is an article about it: https://tobiasahlin.com/blog/previous-sibling-css-has/ https://tobiasahlin.com/blog/previous-sibling-css-has/
- dgb23 2y agoThank you that's a very useful article!
- 2y ago
- safety1st 2y ago> the separation of HTML and CSS is theoretical, not practical. Yes > HTML is not just content. It complects content plus layout No. One broad and now to a great degree complete goal of CSS has been: "regardless of HTML markup order, we can present these elements to the user in whatever order we want."