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?

I think the better framing is: "eliminate/reduce the number of DIVs".

Because the real problem I see is that the generic DIV is grossly overused, when built-in HTML elements already exist for exactly the use case intended.

I rarely see HEADER, FOOTER, NAV, even P because people just use the generic DIV tag instead.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

I recently went down a similar path to build the FE of an app. It worked fine at first and I learned a whole lot about recent updates to CSS. And boy, has it come a long way. Cascade layers, nesting, and the :has selector tripple-handedly change how views can be written for the better.

It is a solid solution for blogs and apps with a distinct document feel, but for anything beyond that I found it too limiting and brittle. Back to components and Tailwind.

> Also, just look at that markup. So clean. So shiny.

That’s the essence of so much of this obsessive bit-twiddling: irrelevant aesthetics. The functional aspect of this is a disaster, as others have noted, locking styling to page structure in a way that will require structural changes to the CSS just to move an element on the page.

I did a lot of front end work from about 2000-2015, but I've fallen into almost entirely backend professionally. That said, I still enjoy it and try to keep up. I have a side project SPA I developed using a css pattern I'm calling "apps"

Basically I have JS "controllers". Every controller type gets a root HTML element. They pick the element type, these root elements automatically get a css class ala "{controller}--app"

Then from within each of these controllers I largely only use un-classed HTML - and style almost entirely based on direct ancestor ">" operators. Something like

    .sidebar--app {
        > ul > li > a {
            // style sidebar
        }      
    }

I generally keep the scope of what is a "controller" pretty small, a few elements deep maximum. It's a sort of hierarchical mvc and controllers have controllers have controllers, so for instance my sidebar controller has a search controller. The search controller just manages its own elements and reports changes via events. This pattern has kept the JS and CSS very clean and understandable, and the generated HTML pristine.

I've been hacking on this for close to a decade, it's a fun little side project. It's pretty large in scope yet it's honestly been a delight to work on. The styling of everything is quite scoped so there's very little unexpected problems. The actual HTML is readable and pleasant.

Right click -> view source.

Found "<span class=..." — What?

Read the page.

Footer : "I only got 99% of the way there. I use 11ty’s syntax highlighting plugin, which uses classes for styling."

Well, HTML was supposed to be a generic language to describe typical documents. Most websites don't need more than the default elements.

From an outside perspective, it is perplexing to see the constant back and forth webdevs do between making website more complex and rediscovering the simpler first principles

We tried this 20 years ago with "CSS zen" and the Bad Old Days of "semantic CSS". It failed because you cannot completely couple HTML structure and presentation.

Usually you have more complex styles and visuals than your HTML can express and trying to invent selectors / HTML heirarchies to describe them gets difficult very quickly

In addition you often need to support multiple style systems on a single web application whilst the design evolves, or else it becomes an all or nothing rollout when you change stuff.

It's common for engineers who weren't around back then to look at the abstractions that modern FE systems provide, and question if they're even necessary. That's healthy. What's not healthy is assuming they were only invented for fake or historical reasons, and telling everyone to just abandon them for commercial projects.

This makes me confident that BEM-like classes are still the best approach for large and complex sites, as long as the .block__element--modifier pattern is followed, so there are no .block__element__secondelement type classes, and things like nesting, descendant selectors and :has() are avoided where possible.

Using custom tags invariably leads to the aforementioned, and browsers need to do extra DOM traversal to target styles properly. Not so with BEM: a flat list of class selectors maps cleanly to elements, so when the browser is parsing HTML to DOM, it doesn’t need to wait for all descendants to be parsed (for :has() to work) or do extra checks to determine whether its current path in the DOM matches a nested or descendant selector. It can just keep on parsing and rendering.

This may not feel like it makes a difference if you’re browsing the web on a veritable supercomputer, but for anyone on an older device, the difference will be between instant and kinda sluggish.

My sympathies! I developed a small CSS frameworks many moons ago [1]. It provided basic styling for elements directly and used the cascading part of CSS a lot. I see the benefits of utility classes and how it fits to web components.

[1] - https://medium.com/teutonic-css/retiring-my-own-little-css-f...

The dark option is definitely the most readable but wow those other themes on this site are super nice looking!!

I love this - and I applied the lessons to my own site. It was fascinating to see just how often I'd slapped a class on something which was never going to be re-used.

Similarly, WordPress spams tonnes of classes everywhere. Most are unused.

So I took a look at rewriting my CSS to target by logical structure, rather than just random names dotted about. It mostly worked well, although it did mean that I occasionally had to write a selector like:

`li[itemtype="Comment"] > article > div[itemprop="author"] {}`

One way to look at this from programming points of view is interfaces(class) vs objects(id). Tying everything to specific object means refactoring becomes impossible. Whilst also relying solely in on interfaces means you might have too loose of a logic for anything meaningful.

I like it. Nice effort. Plus I like the visual style a lot too.

I feel there's a mismatch between creating novel "semantic" elements, and then customising them in the markup, rather than the contextual approach (nesting, rich selectors). The mismatch is that the new elements still apply a "what" approach, but the attributes used for customisation apply a "how" approach and leave it in the mark-up. It's still like `<p class="red" />` rather than `main p { background-color: red; }`.

I get that there's a trade-off between purity and code that's nice to work with, and I think you've hit a very readable, appealing and creative balance.

So even almost classless websites can be laggy websites.

Checks query selectors

> document.querySelectorAll('*[class]');

tons of elements with class

I really like the concept of this. I'd love a html reference guide (pattern library?) with plain html no CSS or JS to document the basic building blocks of the web.

Has the author bothered to view source their own website? If I search for class= on their view source, I see 175 matches!

> I removed a non-trivial amount of CSS (now about ~5KB of CSS over the wire for the entire site)

That's around 2% of the size of the single page of that article, it absolutely is a trivial amount, especially when it complexifies so much the maintenance or addition of the website.

That's why I like using PicoCSS on small projects, it instantly adds style without much classes needed.

Funny thing is that it could really have no class.

This is what I like to see, however, I think that more can be done with the document structure.

I use a section element to enclose a heading with the paragraphs that immediately follow it, thereby scoping text to a heading.

The advantage to this approach is that you 'gain a class' (okay a section) that can be used for styling.

I am not keen on adding my own make-believe elements, however, I have found that, if you know your HTML elements, you can write surprisingly human readable HTML.

There is no need to be fundamentalist with going 'classless', classes are the way to go for situations such as when an element changes.

I also take heed of the HTML5 spec and the advice regarding the use of 'div'. There really is always a better element to use, and, with 'divs' removed, it is trivial to layout any content with CSS grid.

Scoped CSS is also a game changer, however, you have to pretend Firefox does not exist, which is fine by me for my hobby site. Scoped CSS means that you can keep the CSS simple without bizarre selectors that the next developer will not like.

It all depends on what you are trying to create. If you were to want to do your own version of Gmail then you are in a world of complexity. However, blogs, ecommerce and much else does not need to be a complex mess with a 10000 line 'add to' CSS burden.

Hah that's a cool and creative exercise. Love the writing style as well

:%s/;/:

It also has no style

Great job!

But, I'm sticking to tailiwnd :D

I can only see ~half of each line on my phone and cannot scroll, so whatever they are doing, they are doing it badly.

I love the design of his blog -- the use of dots, link highlights etc.

It also brings back memory of 2000s internet, but merged into Today's design standards. I assume this was intentional.

[dead]

[dead]