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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I don't get this comment at all; you say CSS is too limiting but somehow Tailwind, which is just applying CSS using classes is liberating?
Tailwind actually complicates a lot more things, when you have to specify variants for example, there you go installing tw-variants, writing Javascript just so you can get different sorts of buttons.
This is fine for larger component libraries like shadcn-ui, but for simplicity, I'd pick up pure CSS for something like button .error; and button .secondary.
(yes I know you can just @apply whatever you want inside those blocks, but what's the benefit of tailwind then?)
> 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.
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.
You've got the horse before the cart, and completely misunderstand Semantic CSS.
The styling should simply serve to improve the content. The content should generally stand on its own without any styling.
In semantic CSS the goal is to write your HTML with as little regard to presentation as possible. Your HTML is simply structuring human readable data. At this step you give it no thought of appearance.
Styling that structured data comes second. You write the CSS to make the structured data look nice, and ideally do not touch the HTML in the process, at all. The styling is but an affectation.
This fell out of favor because people cared more about looking flashy than quality content, they didn't want to put any thought into developing the actual page and wanted to start with the design. It's a symptom of the overall disease of the modern web.
This is more achievable with modern CSS than ever before and I pray for it to make a comeback.
Looking flashy is a _significant_ signal that users rely on to determine if the content is quality or not. It's a sad fact that, if your site does not ape the style consensus it'll look outdated or worse like a scam. Its the same reason used car salesmen wear suits.
20 years ago CSS didn’t have the power it does now. There was no :has, :where, subgrid, and a whole bunch of other tools that let us effectively decouple structure from styling. Times have now changed, and it’s worth evaluating whether there are opportunities to roll back some of the changes we were previously forced to make.
I think that's fair. It's not semantic information (I mean in a way I guess it is, but you wouldn't want a screen reader to present it as such), so classes are fine there.
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 am sorry but its not the devs who want complexity. Users and Designers want a snappy interactive UI with lots of animations to get the "vibe" right. Devs are usually fine with websites looking like they are straight out of 2003 (considering all the language doc pages I've seen)
Personally, I would first try to get the semantic structure of HTML right for the content I want to display. Then I would look at what I can do in CSS to make it look nice, but without going full overboard. Stick to things that are now standard in browsers, and that are responsive and resize and float nicely. Perhaps, if necessary even something like the checkbox hack, but probably try to avoid it, since it is a hack. Then the site already looks sufficiently good usually. At no point in this comes JavaScript into play, because this is about visuals, and that should be handled by HTML and CSS. I will use JS, when I have something dynamically changing and/or interactive on a page, and I will try to make a noscript alternative, perhaps usable by the user simply reloading the page.
However, I have also seen a lot of frontend devs, who just throw JS framework at everything and since everything is JS anyway, they also do things that could be simple HTML and CSS using JS instead. The result are those pages, where one is greeted by a blank white page, when not running JS.
So there definitely are a lot of devs, mostly frontend devs, that do this kinda thing, and it often secures their job by introducing complexity under the guise of looking fancy.
Example from a previous job: Making buttons that have 2 corners cut off, but the main navigation bugs regarding responsiveness, that led to broken layout took 3 months to fix. Transferring a navigation from one project to another? 3 weeks.
Frameworks are a lot simpler than building with vanilla html, css and js. At least that's my experience... Requires a lot less boilerplate too.
Regarding the noscript alternative solution. I do not know a single modern website relying on users refreshing the page to update content. Except for HN maybe. This approach is very very outdated and will frustrate users.
The refresh page thing is, as I explained, a fallback for users, who don't want to run or cannot run JS. 99% or more of the users will never see this. I personally would be grateful, if web devs took precautions and paid attention to also having a no-JS workflow for things where it is relatively simple to implement. It also has to do with accessibility. A JS-only page, that results in a blank white page has exactly zero accessibility.
It depends, the frameworks I've seen require a ton of boilerplate (ie. the things tools like create-react-app sets up for you) and have quite a learning curve. Using what you already know is simpler, and some of us know vanilla html, css, and js. It also very much depends on what you're making. Many sites don't necessarily need much interactivity or to constantly receive updated data.
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.
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 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 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 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 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.
In fairness, the page loads two enormous fonts. Lots of blogs just use system fonts, so the advice is generally useful if you're trying to reduce your own site size. The total payload without the fonts are around 12kb, so reducing the CSS to 5kb is a fairly big deal. Without the fonts, the entire site could be delivered in the first TCP packet.
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.
I can see whole lines and select the text in a desktop Firefox, but the fonts are messed up (thinned and otherwise tweaked) and colors are set to reduce the contrast, making it hard to read. As with most of the design-related articles, I had to use the reader mode to actually read it. But the content can be guessed from the title (with a hint that it is about CSS) anyway: they have simply removed CSS class selectors, replacing them with element selectors, adding combinator selectors, pseudo-class selectors, and so on.
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?
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.
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.
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.
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.
I'm not sure why this is preferable to having the h2 have a class?
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.
Because a <ul> can be either a horizontal nav bar or a vertical list. Without differentiating the <ul>, how would you style it?
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/...
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.
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.
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.
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 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
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.
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.
I don't get this comment at all; you say CSS is too limiting but somehow Tailwind, which is just applying CSS using classes is liberating?
Tailwind actually complicates a lot more things, when you have to specify variants for example, there you go installing tw-variants, writing Javascript just so you can get different sorts of buttons.
This is fine for larger component libraries like shadcn-ui, but for simplicity, I'd pick up pure CSS for something like button .error; and button .secondary.
(yes I know you can just @apply whatever you want inside those blocks, but what's the benefit of tailwind then?)
> you say CSS is too limiting but somehow Tailwind, which is just applying CSS using classes is liberating
If you read the article you'll see what they're talking about. It's not "CSS is too limiting" it's "CSS only applied to elements is too limiting".
Looks like I threw myself in to a Tailwind flamewar. I should've known better.
TW+TSX is easily the most productive way for me to write UIs and has been for 5 years. Don't like it? Don't use it but please leave me alone.
> Don't like it? Don't use it but please leave me alone.
That's not how HN works. HN is for discussion. If you make a comment, people can discuss.
If you want to be left alone, then perhaps "don't use" the comments section.
I've never heard anyone complain that CSS is too limiting. If anything it's the opposite.
[flagged]
> 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.
[dead]
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.
You've got the horse before the cart, and completely misunderstand Semantic CSS.
The styling should simply serve to improve the content. The content should generally stand on its own without any styling.
In semantic CSS the goal is to write your HTML with as little regard to presentation as possible. Your HTML is simply structuring human readable data. At this step you give it no thought of appearance.
Styling that structured data comes second. You write the CSS to make the structured data look nice, and ideally do not touch the HTML in the process, at all. The styling is but an affectation.
This fell out of favor because people cared more about looking flashy than quality content, they didn't want to put any thought into developing the actual page and wanted to start with the design. It's a symptom of the overall disease of the modern web.
This is more achievable with modern CSS than ever before and I pray for it to make a comeback.
Note for carriage owners: “Horse before the cart” is actually the correct order.
Looking flashy is a _significant_ signal that users rely on to determine if the content is quality or not. It's a sad fact that, if your site does not ape the style consensus it'll look outdated or worse like a scam. Its the same reason used car salesmen wear suits.
I don't do a ton of web development but I occasionally need a little webview or form, and this is exactly how I write them.
That's how I was taught, you know, progressive enhancement. I didn't even know there was any other way lol
20 years ago CSS didn’t have the power it does now. There was no :has, :where, subgrid, and a whole bunch of other tools that let us effectively decouple structure from styling. Times have now changed, and it’s worth evaluating whether there are opportunities to roll back some of the changes we were previously forced to make.
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."
I think that's fair. It's not semantic information (I mean in a way I guess it is, but you wouldn't want a screen reader to present it as such), so classes are fine there.
It says no class though.
Yeah, that title is absurd. The page contains 175 "class=..." attributes.
It’s mentioned in the article that code highlights still use classes.
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 am sorry but its not the devs who want complexity. Users and Designers want a snappy interactive UI with lots of animations to get the "vibe" right. Devs are usually fine with websites looking like they are straight out of 2003 (considering all the language doc pages I've seen)
That depends very much on the type of developer.
Personally, I would first try to get the semantic structure of HTML right for the content I want to display. Then I would look at what I can do in CSS to make it look nice, but without going full overboard. Stick to things that are now standard in browsers, and that are responsive and resize and float nicely. Perhaps, if necessary even something like the checkbox hack, but probably try to avoid it, since it is a hack. Then the site already looks sufficiently good usually. At no point in this comes JavaScript into play, because this is about visuals, and that should be handled by HTML and CSS. I will use JS, when I have something dynamically changing and/or interactive on a page, and I will try to make a noscript alternative, perhaps usable by the user simply reloading the page.
However, I have also seen a lot of frontend devs, who just throw JS framework at everything and since everything is JS anyway, they also do things that could be simple HTML and CSS using JS instead. The result are those pages, where one is greeted by a blank white page, when not running JS.
So there definitely are a lot of devs, mostly frontend devs, that do this kinda thing, and it often secures their job by introducing complexity under the guise of looking fancy.
Example from a previous job: Making buttons that have 2 corners cut off, but the main navigation bugs regarding responsiveness, that led to broken layout took 3 months to fix. Transferring a navigation from one project to another? 3 weeks.
Frameworks are a lot simpler than building with vanilla html, css and js. At least that's my experience... Requires a lot less boilerplate too.
Regarding the noscript alternative solution. I do not know a single modern website relying on users refreshing the page to update content. Except for HN maybe. This approach is very very outdated and will frustrate users.
The refresh page thing is, as I explained, a fallback for users, who don't want to run or cannot run JS. 99% or more of the users will never see this. I personally would be grateful, if web devs took precautions and paid attention to also having a no-JS workflow for things where it is relatively simple to implement. It also has to do with accessibility. A JS-only page, that results in a blank white page has exactly zero accessibility.
It depends, the frameworks I've seen require a ton of boilerplate (ie. the things tools like create-react-app sets up for you) and have quite a learning curve. Using what you already know is simpler, and some of us know vanilla html, css, and js. It also very much depends on what you're making. Many sites don't necessarily need much interactivity or to constantly receive updated data.
>Users ... want a snappy interactive UI with lots of animations to get the "vibe" right
[citation needed]
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...
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 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"] {}`
Checks query selectors
> document.querySelectorAll('*[class]');
tons of elements with class
The footnote mentions they're stuck with 11ty's code highlighting plugin.
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.
It was super snappy for me. The snappiness actually stood out. In us east
In the EU on Firefox mobile and was weirdly slow.
It was snappy for me, also in EU on Firefox mobile
The dark option is definitely the most readable but wow those other themes on this site are super nice looking!!
Has the author bothered to view source their own website? If I search for class= on their view source, I see 175 matches!
Had you bothered to read all the way to the bottom you'd see that is mentioned. Delete the <pre> nodes and the class= search fails.
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 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.
The 5KB is trivial. They don't mention how much was actually removed. Maybe 200KB? Who knows
It has also vastly simplified the maintenance of the website.
In fairness, the page loads two enormous fonts. Lots of blogs just use system fonts, so the advice is generally useful if you're trying to reduce your own site size. The total payload without the fonts are around 12kb, so reducing the CSS to 5kb is a fairly big deal. Without the fonts, the entire site could be delivered in the first TCP packet.
It'd be even more irrelevant if the site didn't do "public,max-age=0,must-revalidate" on the CSS file.
Funny thing is that it could really have no class.
That's why I like using PicoCSS on small projects, it instantly adds style without much classes needed.
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.
Also, can't seem to be able to select text, for one reason or another.
I can see whole lines and select the text in a desktop Firefox, but the fonts are messed up (thinned and otherwise tweaked) and colors are set to reduce the contrast, making it hard to read. As with most of the design-related articles, I had to use the reader mode to actually read it. But the content can be guessed from the title (with a hint that it is about CSS) anyway: they have simply removed CSS class selectors, replacing them with element selectors, adding combinator selectors, pseudo-class selectors, and so on.
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.
Its link hovering effect is probably the worst I've seen for a long time, not to mention the fact that it just makes it unreadable.
[dead]
[dead]