[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.

[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.

[butlike]

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

[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.

[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.