> 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.
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.
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
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.
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:
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.
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?
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.
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.
48 comments
[ 3.5 ms ] story [ 65.6 ms ] threadThat'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.
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.
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
It also brings back memory of 2000s internet, but merged into Today's design standards. I assume this was intentional.
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."
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.
But, I'm sticking to tailiwnd :D
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"] {}`
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?
> 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.
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.