This website has no class(aaadaaam.com)
aaadaaam.com
This website has no class
https://aaadaaam.com/notes/no-class/
105 comments
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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).
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.
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.
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.
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.
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?
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.
Implemented it this way with static generators and web apps before very easily.
Not to mention it is so stupidly quick.
[deleted]
[deleted]
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.
> 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.
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.
[deleted]
[deleted]
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/...
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/...
[deleted]
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.
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?)
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".
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.
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.
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.
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."
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 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'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.
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'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.
> 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.
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.
Yeah. I don’t want to see “wow look at how pretty this markup is”. I want to see “look how flexible and easy to change this is, without redoing everything”.
If you’re not talking about change, the other stuff is pointless.
If you’re not talking about change, the other stuff is pointless.
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
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.
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.
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]
[citation needed]
[deleted]
> 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 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.
It'd be even more irrelevant if the site didn't do "public,max-age=0,must-revalidate" on the CSS file.
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.
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.
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.
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.
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.
The standard idiom is "cart before the horse"...
https://en.wikipedia.org/wiki/Cart_before_the_horse
https://en.wikipedia.org/wiki/Cart_before_the_horse
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.
You’re probably right about most users, but when I see a website that doesn’t bother with CSS at all, for me that’s a strong signal of higher quality content.
We tried all that stuff in the early 2010s. I was there. It didn't work.
People ditched element-based CSS for good reasons: it forces you to maintain increasingly complex stylesheets, because you end up having to come up with increasingly arcane rules describing how the design links back to content.
But some design isn't about content. Sometimes you need a button that's centered because it just looks better. There's no semantics or document structure you can point to, to justify that.
(So then you end up with post-hoc mental gymnastics like, "hmm, well, it's the second last button on the page in this one instance, so let's write an :n-selector that only targets the penultimate <button>...")
So having classes lets you keep the look and the meaning orthogonal. Which is especially helpful when you don't have total control over the markup (e.g. most content management systems)
People ditched element-based CSS for good reasons: it forces you to maintain increasingly complex stylesheets, because you end up having to come up with increasingly arcane rules describing how the design links back to content.
But some design isn't about content. Sometimes you need a button that's centered because it just looks better. There's no semantics or document structure you can point to, to justify that.
(So then you end up with post-hoc mental gymnastics like, "hmm, well, it's the second last button on the page in this one instance, so let's write an :n-selector that only targets the penultimate <button>...")
So having classes lets you keep the look and the meaning orthogonal. Which is especially helpful when you don't have total control over the markup (e.g. most content management systems)
[deleted]
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
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.
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 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.
The dark option is definitely the most readable but wow those other themes on this site are super nice looking!!
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 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:
`li[itemtype="Comment"] > article > div[itemprop="author"] {}`
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"] {}`
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...
[1] - https://medium.com/teutonic-css/retiring-my-own-little-css-f...
I like the idea of using custom elements instead of div with class and being able to gradually enhance it to a Webcomponent if needed.
What I think is a bad practice is the nesting of selectors to avoid classes. This leads to a high specificity and to a tight coupling with the html structure.
A more modern approach to reduce (not avoid) classes is the @scope and @layer rules. They have a hughe potential for designing components in css.
What I think is a bad practice is the nesting of selectors to avoid classes. This leads to a high specificity and to a tight coupling with the html structure.
A more modern approach to reduce (not avoid) classes is the @scope and @layer rules. They have a hughe potential for designing components in css.
So even almost classless websites can be laggy websites.
It was super snappy for me. The snappiness actually stood out. In us east
Wouldn't using tailwind with `@apply` rules be a double win? You get tailwind to tweak the one-offs, and you get classless in the typical case. A couple kb more CSS perhaps, but that's negligible.
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.
Hah that's a cool and creative exercise.
Love the writing style as well
Checks query selectors
> document.querySelectorAll('*[class]');
tons of elements with class
> document.querySelectorAll('*[class]');
tons of elements with class
The footnote mentions they're stuck with 11ty's code highlighting plugin.
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.
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.
> link hovering effect is probably the worst I've seen for a long time
Interesting effect but also a clear form-over-function kind of brutalism.
Interesting effect but also a clear form-over-function kind of brutalism.
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.
>This website has no class
f12 -> ctrl+f -> "class"
><pre class="language-css">...
NOOooooooo. They LIED to me. I officially state that this website HAS CLASS
f12 -> ctrl+f -> "class"
><pre class="language-css">...
NOOooooooo. They LIED to me. I officially state that this website HAS CLASS
Has the author bothered to view source their own website? If I search for class= on their view source, I see 175 matches!
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.
That's why I like using PicoCSS on small projects, it instantly adds style without much classes needed.
[deleted]
Funny thing is that it could really have no class.
:%s/;/:
I like the title
It also has no style
[deleted]
Great job!
But, I'm sticking to tailiwnd :D
But, I'm sticking to tailiwnd :D
[deleted]
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?