[bgarbiak]

I tried this approach years ago. Now I consider it an anti-pattern. You really don’t want the look of your website/document to be dependent on its structure. Things like li:has( > a + p) - it seems so clever initially, but then you need to have a button instead of an a, or an icon, or a wrapper over entire thing; but only for a single item on the list. You either end up with messy CSS that covers all these scenarios, or you just go back to classes.

I kinda see a potential usefulness of custom attributes, but I’m still not entirely sure how they’d be better than classes. What’s the advantage of [shape-type="1"] over .shape-type-1?

[clan]

Is there no middle ground?

I love the clean approach with classless. Documents do have a structure and is makes it easy to change by just swapping out the CSS without touching the document.

But could you not just add the class only when you really really need to break the structure? The middle ground for me would to do my utmost to avoid classes within reason. So as few exceptions as possible. I know this is selling elastic bands by the meter.

On the other end you have Tailwind CSS. I know many are happy with it and find it has a nice developer velocity. But I find it overly verbose and "framework of the day"-ish.

So for me it is classless until my head hurts. Then I'll sprinkle in a class to get work done.

[ysavir]

It depends a lot on the rate of change of the document.

Documents that experience little change don't need classes because their structure is reliable.

Documents that change often have unreliable structures, and will require frequent updates to the CSS rules to match structure changes. Using classes insulates the CSS from the document structure, mitigating the need to update CSS as the document evolves.

It also depend your development strategy. If using Vue components and writing the CSS in the same file as a dedicated, small-scoped components, it's practical to update the CSS references alongside the document changes. But when there's distance between the HTML and the CSS, or there are components in use who's structures may change unpredictably (such as from 3rd party libraries), classes provide a safer reference.

There's no need to have an ideology of using classes or not using classes. The practical approach is to assess the nature of your work, the rate of change of the documents, and to adopt practices built around those assessments.

[limagnolia]

The vast majority of the time, if my document structure changes, I want the presentation to change too. It may depend some on how complex the document structure is... I usually advocate for simpler structures. I agree that one should assess and adopt practices applicable to what they are building.

[nilslindemann]

My middle ground is semantic classes but also use the element names, as they are already semantic. I use IDs only for JavaScript. No hierarchical class names, no Tailwind, no code compressing, no Uglifiers. My code shall be a pleasure to read and modify.

[aliyome]

My proposed viable middle ground approach would be to adopt markdown as an intermediate representation and use some build process to generate the final output. As long as the input is markdown, it doesn't matter if the final output from the build process maintains tight coupling between structure and styling. That said, if the primary benefit of the no-class approach was intended to facilitate development, this method—which introduces an additional build step—would be counterproductive.

[taeric]

I'm curious why you don't think the look should be dependent on the structure? I can agree that some structure dependence would be a bit restrictive, but most structural items in the browser are specifically for how things should look?

I think the confession at the end of the article is correct, that this asks a ton of the authors of sites. But the article is also correct that accessibility is much better for this style than it is for competing ideas. Just compare to the div heavy style that is common in places like substack.

[webstrand]

The problem is that, in the current state of CSS, it's a two way binding: The styles are dependent on structure to make the look, and the structure is dependent on styles to make the look. Often times you wind up needing to add a wrapper div, either to give a root for selectors or to provide some CSS context like stacking, containers, perspective, etc. And when you add that container class, your classes that are structural often all break in difficult to debug ways.

I used to follow CSS Zen, now I'm more of a "put a class on every element describing its purpose semantically". Then, when I need to change the structure of some component, adding a wrapper, changing an element type a -> button, etc, most of my styles keep working just fine. I'm not a fan of Tailwind, my method is more like BEM or Atomic CSS but with less naming-convention-rigour.

I should mention that most of my work is in building interactive components. You might be able to make the case for structural css for more flow-like content. But even then, when designers start asking for full-bleed elements in flow, you have to start breaking structural semantics and tying the two together.

[taeric]

I am not sure I understand. There is coupling between the styling and the structure. Somewhat by necessity? I'm curious how you would possibly avoid having any.

I think your point is that there are not enough structural items to distinguish things for some uses without also signaling them for others? I can agree with that.

So, as a maximalist position, I agree that you should consider it an anti pattern to force yourself into minimal markup. But I also have a hard time not thinking it is an anti pattern to go the other way? Lots and lots of divs because the only way we could consider abstracting things is yet another wrapper around things.

Gets worse when I look at the noise that are the classnames generated in so many frameworks.

[webstrand]

Perhaps a better way to think of it is: HTML doesn't provide enough distinct element types to accurately capture the semantic structure of modern interfaces.

You're right that some coupling is inevitable, but the question is where to put it. I'd rather couple my styles to semantic intent (what something is) than to DOM structure (where something sits).

I don't add classes where I don't need to style anything, and I'm not adding _extra_ divs. Instead of using HTML element names, I'm using my own semantic naming convention that is not strictly tied to the behavior of HTML elements.

For instance `<a class="navbar-button">`, `<button class="navbar-button">`, or `<div class="animation-wrapper"><button class="navbar-button">` can all be selected by the same `.navbar-button`. Whereas the equivalent structural selector `nav > ul > li > :is(a, button, .animation-wrapper > button)`, is fragile and complex. Additionally you can't use a descendant combinator instead to simplify, because there could be other non-navbar button descendants of a navbar item (for ex. a dark/light mode switch).

This gets even worse with modern CSS features. Say you want a hover animation that uses container queries - you'll need to add a wrapper div around your button to establish the container context. That single structural change breaks not just `nav > ul > li > button`, but also related selectors like `button + button` for spacing or `li:has(button)` for parent styles. Using structural selectors leads to selector complexity as you're forced to be more and more specific with your selectors to avoid parts of structure you shouldn't be styling.

I still use semantic markup wherever possible, I think its a great benefit for accessibility tools and automated information extraction. I just don't think its a good idea to use it for styling. And modern CSS gives us lots of tools to break HTML semantic markup like `display: contents` (especially useful for html table syntax).

[taeric]

Ok, I don't think I disagree that much. Was more just curious on what you meant. I view the structure as already something happening to describe things in ways that facilitate styling. But, this is a lot like the distinction between attributes and children in XML. I think people give it a little more thought than it warrants.

To that end, I think I can get behind the idea of "if you are going to use classes anyway, might as well use them for all of it." That is, having some that are done by structure and some that are done by class seems to be the a dangerous mix.

[butlike]

Because a <ul> can be either a horizontal nav bar or a vertical list. Without differentiating the <ul>, how would you style it?

[vharuck]

At the risk of pedantically answering just this one example, wrap the nav bar list in a <nav> element: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

[taeric]

This doesn't really change the idea, though. The structure is specifically to communicate style opportunities. Exactly how it is styled can be dependent on other things, as well, but the structure is specifically an affordance to facilitate styling.

[lobsterthief]

Another pitfall is SEO: the SEO team might tell us they need a certain element on the page to be an h2, for SEO purposes, but it needs different styling than other h2s on the page.

MUI solves this problem by having different typography sizes defined in the theme, and then you specify variant=“h2” on an arbitrary Typography component and all the styling is consistent.

One more reason I always choose or recommend MUI for all new projects.

[bryanrasmussen]

I'm not sure why this is preferable to having the h2 have a class?

[grebc]

Each page can easily have its own relevant inline styles for different layouts/composition.

Implemented it this way with static generators and web apps before very easily.

Not to mention it is so stupidly quick.

[jggube]

Yeah, you'd have to enforce very strict nesting rules in the document structure, which is impractical, especially for more complicated, multi-user web apps. Classes provide flexibility and atomicity.

> What’s the advantage of [shape-type="1"] over .shape-type-1? In terms of CSS selector performance, classes are often faster than custom attributes, so I also don't know if there are any advantages in this particular use-case.

[wpm]

It probably depends on the context you're applying the pattern to. This post is a blog site. Each article is a static document, unlikely to have considerably odd or exceptional structure as a general rule. Like, the page has one "button". Probably works really great here.