Even though I use Tailwind CSS for larger projects, there are smaller, self-contained cases where Pico CSS is a perfect fit.
Their "Usage scenarios" page describes it spot on:
I discovered Pico CSS just last week, and it turned out to be exactly what I needed for a small Hugo theme (govanity, vanity URLs for Go modules/packages with Hugo: https://github.com/foundata/hugo-theme-govanity). From discovering Pico, reading the docs, and integrating it, I was done in about two hours.
I like that resource, but it's missing an important one: github-markdown-css[1]. Given that most devs these days read a lot of Github markdown, it seems like a reasonable starting place for a css system.
I think divs sent a generation down the wrong track. It’s weakly semantic and omnipresent in every 101 tutorial; it makes the semantics overall seem weak/insufficient.
It’s just the default block-level containing element, so it serves its place but is not well explained in these tutorials (just as spans are the default inline element).
In my 25 years of experience writing HTML and CSS most engineers don’t understand semantic HTML, nor do they take the time to learn it; largely because companies don’t value it, unless they’re heavily SEO-focused companies.
I once worked at a company that would run an HTML5 validation test in our CI/CD pipeline. That was very helpful as it identified invalidly nested elements and taught proper semantic HTML.
I use picocss for my personal site [1], which I just recently converted to plain html. I just realized that, with a bit of plain vanilla js, I can easily create a header and footer for every page. I need to write some kind of markup anyways, so why not directly write html? Also, picocss comes with dark mode, which I personally prefer.
That’s a neat idea! I’m using Nginx, but there’s also SSI support in it. Currently, I'm using Javascript to set the current page on the main nav. I might get away with conditional includes or similar. I’ll explore my options. Thank you!
The new raku site is built on the https://harcstack.org - that's HTMX, Air, Red and Cro. (The raku Air module is the glue, Red is the ORM and Cro is the HTTP framework).
HTMX and Pico are baked into HARC stack - the rationale for this is that HTMX (as the antidote to React) enables non TypeScript languages on the server side. Of course, then you need a library that will help you write your server! That's where HARC stack comes in.
For example, on the raku.org front page you will see a set of button/tabs that select specific code examples - each one of these does...
These results in a more lightweight page and the ability to run code to render the tab content on demand. It's probably overkill for this site rather static needs, but the Air::Base component library tilts towards active HTMX controls wherever possible.
Yeah. I had to zoom out to 75% in my browser before the text looked normal-ish sized but the "widgets" still looked very big and awkward. Maybe this was designed not just for mobile-first but mobile-only?
Looking at the CSS variables page it seems that this is because they scale up the base font size at various breakpoints, starting at 106.25% at 576px, and going all the way up to 131.25% at 1536px. It definitely feels too heavy handed to me. The first time I viewed the website on mobile it seemed fine (because it's actually at or close to the browser's standard font size) so I wasn't sure what the problem was until I viewed it on my desktop. I can kind of see what they're going for as it keeps the layout fairly consistent, but I don't think it's the right approach.
I wish I started with something like that. At the time my website was just a blog, but I've added tools and forms over the years. I had to create an ad hoc design language and set of components for it. Pico would have been far more effective.
I love the focus on semantic HTML, because it matches how I write CSS. The HTML should be as pure and as style-agnostic as possible.
I use Pico with LLM code gen for new projects. As you probably know, LLMs are predisposed to Tailwind and coding for industrial strength on any tiniest projects. The trick is to feed it the whole Pico docs as context and prompt it (i.e. in your CLAUDE.md) to use Pico explicitly.
Did you do anything fancy to get the whole Pico docs into context? I see on their website that their docs are split up across a bunch of pages, did you copy+paste each one into a large prompt document? I was hoping to see a single-page docs download but I didn't find one.
You will need to write custom CSS, but collapsible trees are totally possible to do purely in CSS in any framework via a simple combination of checkboxes, labels, pseudo-classes and CSS combinators.
The `:checked` selector allows you to target checkboxes that are checked. So you can have a set of checkboxes (off screen with an absolute negative position or similar) that are controlled via a <label> element that wraps the + or - text in the tree. Then based on its state, you can target elements directly afterward to be expanded or contracted using the CSS adjacent sibling combinator.
Checkboxes are neat because they provide state management natively in the DOM and you can do a lot via CSS based on that ;) Thus, you have pure HTML and CSS collapsible trees.
Hell yes, this is geat! It's a shame it uses pixels instead of physical+relative units (like pt/mm + em/ex/rem) but still better than tailwind or bootstrap horrors
I’m using Pico for a hackathon project. It’s a good way to prototype, especially the class-less version. You don’t need to pay attention to every detail to get the concept in a good enough state, nor do you need an LLM to remind you of Tailwind’s library of classes
I won't call Pico "minimalist". I'd call it "understated but pretty complete", with a ton of attention to detail, and oodles of customization variables.
I like to use Pico CSS as a starting point for websites (as opposed to apps). I even put it in the my Django starter kit (https://github.com/stribny/sidewinder/). Recommended!
> Not fond of Pico.css’s weight, though: over 50KB, nowhere near as lightweight as the name suggests (even if it’s above-average compressible, 8KB gzipped—but I wouldn’t count even 8KB uncompressed as pico); in this case, if you flatten the variables and strip unused code, you’re left with under 4KB (~1.4KB gzipped). Lots of bloat from unused light mode support, things like form controls, and a fair bit of frivolous custom properties usage. This is the sort of place where I see the appeal of the likes of Tailwind, because they generate such huge amounts of CSS that you just about have to use an unused style remover. But it is another build step, and contrary to the deliberate intent here.
And it sounds like it has grown further. I don’t see 71kb, I see 83KB (11.6KB gzipped, 10.1KB brotli). At that point I wouldn’t even call it small, and it’s even getting past medium-sized into large territory.
I’ve been thinking about creating a CSS tool somewhere about halfway between new.css and Pico CSS for very basic page layout tools (containers, callouts, menu bars, etc) that still focuses on being extremely small and performant.
I feel that a tool like that would be helpful for laying out a simple but functional site (sourcehut’s site [1] comes to mind) where you need a few basic layout tools but don’t need all of Bootstrap.
I’d love to see NeatCSS on your list. It’s not officially classless but I try to make it semantic as much as possible. I bookmarked you GitHub repo (which you should link on the page if I didn’t miss it). I’ll give it a try myself to see if it works (and maybe make adjustments).
I think this would be excellent. There's a whole class of websites /landing pages which right now Astro seems to be filling that niche. It's mind boggling how hard it is to do basic components on the web
I frequently use Pico for demo websites like https://demo.rubomonolith.com. You don’t have to worry about styling and you get something that looks reasonably polished.
I can't possibly recommend class based CSS soup anymore. Once you go with utility classes it's hard to go with anything else. It's super intuitive, you don't have to dig through loads of CSS files to figure out where the CSS is and you can simply remove or add classes as you need and see it right there in front of you.
It really feels like all these concerns about semantic everything belong to a previous era of the web. I remember arguing with people 20 years ago who believed RDF and the semantic web was going to take over, but the use cases never materialized.
Semantic web is a bit different from semantic HTML.
As I understand it, the main point of semantic web is making the web machine readable, often using languages specifically designed for that task that are not HTML.
Semantic HTML is more concerned with writing standardized HTML that leverages browser capabilities and respects users who use assistive technology to browse the web.
Frankly, I don't see what this framework has to do with either. I was curious about how they implemented the dropdown menus, and they're specially styled <details> elements, which are normally used for accordions. That seems a bit strange to me, because the obvious choice for a dropdown is the <select> element.
Not much, since we’ve never really had it, but yes, I would love to consume hypertext like a stable API, have user-styles and block elements I don’t like. I do these things now, too, but in a better world they could be less of a hassle technically and less niche socially, then I’d do them even more.
Here’s a uBlock Origin style I use for hackernews, for example:
> I can't possibly recommend class based CSS soup anymore.
Me neither!
> you can simply remove or add classes as you need
That sounds like exactly what I was thinking when you said class soup.
> you don't have to dig through loads of CSS files to figure out where the CSS is
The CSS should be in your components, or in a .css file beside your components at worst. React having bad defaults doesn't need you need to change to adding 20 classes to every HTML element.
I've stopped doing frontend several years ago but it doesn't really feel like the trade off of the newer styling solutions vs just CSS Components for scoping are worth it.
...and then you need to make all your buttons of a certain type 5px taller or a different color, and you have to go replace the utility class in all 40 buttons. But not any other elements that use the same utility class.
Instead of if you'd just given them all the same semantic class ".config-button" or ".sidebar-button" or ".btn-hero" or whatever, you could make that change in a single place.
If your CSS has turned into soup, I have to be blunt: you're doing it wrong. And you should never have to "dig through loads of CSS files to figure out where the CSS is", it's 1) literally in your browser inspector when you select the element and 2) your CSS files should be organized so it would be easy anyways. Finding a class is as easy as finding a function definition.
Utility classes are for people who want to throw away all the benefits of semantic naming because they don't want to go to the trouble of actually organizing their user interface, even though they see the value in organizing the rest of their code. I honestly don't get it.
The big missing piece for me was that these strategies are meant to be used with React or some other framework. So, in your example, you actually only edit in one place, a SidebarButton component.
... And end up with elements that have dozens of classes until you need to parse CSS in your head in order to figure out what the element is supposed to look like. This methodology completely misses the point of using classes to begin with.
Good class and ID names should be semantic, just like the markup. Don't describe what the CSS does; describe what the element is.
Not only that, but it introduces useless abstractions that could've been avoided by just writing CSS directly. How is `.content-center` better than `align-content: center`?
Tailwind and its ilk are one of the worst trends to have ever happened in web development. It's making people forget how to use CSS, while being useless in the process. I truly don't understand it. And, yes, I've worked on projects that used it extensively. It's awful.
Quick iteration and good relative spacing for margins, paddings, dimensions etc.
A lot of people combine Tailwind with something like Vite so they're getting instant previews and don't need to swap focus to a style sheet to style their component. I swapped to Tailwind and honestly could never swap back.
I appreciate strong opinions, but I appreciate good arguments even more. And there's just nothing here.
You're raising a bunch of meyerweb talking points from 2003, except why? WHY does markup need to be "semantic" in the sense that you mean? Actually, WHY? Provide a supporting argument that it makes a difference to developers or end users. Remember, we've all been doing it that way for years, and we switched to Tailwind. You need to have something more compelling to developers who have already made up their minds.
> Not only that, but it introduces useless abstractions that could've been avoided by just writing CSS directly. How is `.content-center` better than `align-content: center`?
There are several reasons, but media queries would be reason 1. Why is it useless, again? Remember, we can't tell what your high-level abstractions do without opening at least two files, plus we have to understand any inherited/cascading rules on top of that. If that complexity doesn't matter, then it's argument time again.
> It's making people forget how to use CSS
Tailwind relies on CSS for its class names. How would one use it without knowing CSS in the first place? Secondly, why would it be bad (argument time again)?
The reasons for Tailwind are well understood. It's way faster, trivial to pick up, and easier to maintain longterm, especially in a team environment, than bespoke CSS/DOM abstractions that have layers of hidden complexity. Now, what does your way of doing CSS offer? Remember, tons of people switched from older methodologies to Tailwind and have already priced in the benefits, small as they were.
> WHY does markup need to be "semantic" in the sense that you mean?
If you've been hearing about this since 2003, then I shouldn't have to repeat the reasons here. You can look up countless articles that explain exactly why semantic HTML and CSS are a good thing much better than I can do justice here.
> There are several reasons, but media queries would be reason 1.
That still doesn't explain why e.g. `class="w-16 h-48 md:w-32 lg:w-48"` would be preferable over a single class that describes what the element is and defines how it should look like and behave.
I mean, to steel man your argument, I get the appeal of getting predefined and consistent breakpoints, and being able to prefix or suffix classes with sizes. But that doesn't seem like a worthy tradeoff for losing legibility, and polluting the markup with this noise. It's the same as declaring all CSS inline, except using classes.
> Remember, we can't tell what your high-level abstractions do without opening at least two files
A good class name will tell you what the element is, not what it should look like. For that, you look at the CSS. Whether that CSS is defined in the same file or in another file, is up to you.
> plus we have to understand any inherited/cascading rules on top of that
Yes, that is what the "C" in CSS stands for, and it's a useful feature for propagating and combining rules without having to redefine them on every element.
If you want to avoid this "complexity", there are numerous ways to scope rules to a specific element or component. Most modern frameworks can scope styles per component for you. And with cascade layers, you now have more control over how and when rules are applied.
> Tailwind relies on CSS for its class names. How would one use it without knowing CSS in the first place?
Some class names are straightforward to understand and use, but others, like the example I posted above, require knowledge about Tailwind itself. Users can become proficient with this syntax without ever understanding what's happening underneath, thus degrading their CSS knowledge. You said it yourself—you want to avoid looking at CSS files altogether. How long would it take for you to not be able to write CSS directly?
> It's way faster, trivial to pick up, and easier to maintain longterm, especially in a team environment
Those are highly subjective, and I would argue against it being easier to maintain. When all your elements use dozens of utility classes, how do you ensure that the styles are consistent throughout the app? One typo in any of the class names can cause inconsistencies that are difficult to spot in a code review.
Oh, use reusable components, I hear you say. Well, why don't you just define the CSS in the component itself then?
Or, no, you use another abstraction on top of Tailwind like daisyUI, which is an insane attempt to bring back sanity into this workflow.
> than bespoke CSS/DOM abstractions that have layers of hidden complexity.
What abstractions?? It's literally a group of rules with a descriptive name that tells you a) what the element represents in the context of the app, and b) how it looks and behaves. There are no abstractions there.
The reason the classes are "bespoke" is because every app will be different. You might want to share some common rules between apps, and we've been doing that for decades just fine. I don't see how grouping utility class names inline makes you any faster or more productive than grouping rules in CSS declarations in the same or external file, and giving them a descriptive name.
> Remember, tons of people switched from older methodologies to Tailwind and have already priced in the benefits, small as they were.
Tons of people use and swear by bloated and complicated frontend web frameworks too, so the popularity of Tailwind doesn't surprise me. I can still have the opinion that it's all wrong, which you're free to disagree with.
Tailwind is basically the VB6 of modern web development. It's popular for all the same reasons (I'm not saying they are good reasons, just that we've seen all this before in a different iteration).
Really love how this project is evolving. It helps you write components with better accessibility without compromising maintainability (it actually improves it) and it's easy to customize.
I've tried using this before and pretty quickly migrated away. While I like the idea of it, the default styling is not great and I felt frustrated with the amount of adjustments it needed to support a data-dense site.
I honestly can no longer tell which “minimal CSS frameworks for semantic HTML” I have not seen on the front page of HN and which are repeats. Are they all the same at this point?
Not specifically picking on this one, just that it seems that they are the quick to crank out type of libraries and everyone has their own.
Sure but why would I do that? When was the last time you decided that the solution to whatever problem you were facing was to switch to a completely different CSS framework without rewriting your HTML?
The real neat thing is not having to make decisions up front. But you can tweak it later. If you are a rebel you could even use classes to touch up bits you are not happy with.
What I am saying is that I have never done this, have seen the need for this, or have heard of anyone doing this or having the need for this.
To create an absurdist analogy it is like saying that because labels on cotton T-shirts are the same size that you could take them off shirt A and sew them onto shirt B. It is possible by there is zero point in doing it other than to say that you did it.
Correct, there is no need. It is more of a preference, maybe a challenge or code golf type of thing. One advantage is less thinking / decision / boilerplate is needed when adding elements.
Semantic:
p
Normal:
p class=paragraph
Utility:
p class=mx-1 py-1 my-2 text-medium
It is like buying a medium shirt rather than getting a tailor-made t-shirt.
You're mixing "is" and "ought." Why ought styles be interchangeable (remembering that stylesheets and DOM structures often have complex, dependent relationships that are rarely as simple as Pico or anything similar).
Love pico. It’s my default starting point for nearly every side project. Sometimes I will reach for Neat [0] which is a great deal smaller.
[0]: https://neat.joeldare.com/
Whoa, that’s mine. Thanks for the mention. :)
I use it for almost everything. I just made a note to try it with the demo and to steal some ideas from pico (while keeping the size of neat tiny).
Thanks for the great tool! Appreciate it. :)
Good stuff. And it's lovely to see something inspired by the truly awesome 100 Rabbits.
This is awesome I’m going to start using.
Even though I use Tailwind CSS for larger projects, there are smaller, self-contained cases where Pico CSS is a perfect fit. Their "Usage scenarios" page describes it spot on:
https://picocss.com/docs/usage-scenarios
I discovered Pico CSS just last week, and it turned out to be exactly what I needed for a small Hugo theme (govanity, vanity URLs for Go modules/packages with Hugo: https://github.com/foundata/hugo-theme-govanity). From discovering Pico, reading the docs, and integrating it, I was done in about two hours.
One thing that's surprisingly easy to overlook in between: CSS variables: https://picocss.com/docs/css-variables and Colors: https://picocss.com/docs/colors
I wish there was picocss but as a set of tailwind @apply rules, so I could use tailwind but have base styles classlessly.
- url updated!
Love love love Pico. It's such a terrific starting point, and easy to tweak into different directions. It's the anti-Tailwind.
There's also this site which allows easy switching/previewing of classless CSS themes:
https://www.cssbed.com/
I like that resource, but it's missing an important one: github-markdown-css[1]. Given that most devs these days read a lot of Github markdown, it seems like a reasonable starting place for a css system.
1 - https://github.com/sindresorhus/github-markdown-css
Reminds me of https://csszengarden.com/
Tufte looks very elegant
Tufte frequently makes the rounds here — most recently 4 days ago: https://news.ycombinator.com/item?id=45119103
See also https://dohliam.github.io/dropin-minimal-css/ which has quite a few more (including github-markdown-css mentioned in a sibling comment).
Nice.
There are some nice one there, surprised many weren’t mobile-first or mobile-friendly.
Pico looked nice on mobile though.
Related. Others?
Tailwind CSS vs. Pico CSS (2022) - https://news.ycombinator.com/item?id=41511420 - Sept 2024 (48 comments)
Htmx, Raku and Pico CSS - https://news.ycombinator.com/item?id=41482679 - Sept 2024 (153 comments)
Pico CSS v2 comes with 380 manually crafted colors - https://news.ycombinator.com/item?id=39488979 - Feb 2024 (12 comments)
Pico CSS Framework - https://news.ycombinator.com/item?id=29559961 - Dec 2021 (101 comments)
This is how CSS should be written. I will never understand why class names need to repeat the semantic purpose for a given element.
I think divs sent a generation down the wrong track. It’s weakly semantic and omnipresent in every 101 tutorial; it makes the semantics overall seem weak/insufficient.
It’s just the default block-level containing element, so it serves its place but is not well explained in these tutorials (just as spans are the default inline element).
In my 25 years of experience writing HTML and CSS most engineers don’t understand semantic HTML, nor do they take the time to learn it; largely because companies don’t value it, unless they’re heavily SEO-focused companies.
I once worked at a company that would run an HTML5 validation test in our CI/CD pipeline. That was very helpful as it identified invalidly nested elements and taught proper semantic HTML.
I use picocss for my personal site [1], which I just recently converted to plain html. I just realized that, with a bit of plain vanilla js, I can easily create a header and footer for every page. I need to write some kind of markup anyways, so why not directly write html? Also, picocss comes with dark mode, which I personally prefer.
[1]: https://g5t.de
If you're using Apache you could just use Server Side Includes and forget the JS.
That’s a neat idea! I’m using Nginx, but there’s also SSI support in it. Currently, I'm using Javascript to set the current page on the main nav. I might get away with conditional includes or similar. I’ll explore my options. Thank you!
big fan of pico … just published the new https://raku.org official website using it
That's not a coincidence :-)
Can you explain a bit how you are using HTMX?
Pointer is great if you have it...
The new raku site is built on the https://harcstack.org - that's HTMX, Air, Red and Cro. (The raku Air module is the glue, Red is the ORM and Cro is the HTTP framework).
HTMX and Pico are baked into HARC stack - the rationale for this is that HTMX (as the antidote to React) enables non TypeScript languages on the server side. Of course, then you need a library that will help you write your server! That's where HARC stack comes in.
For example, on the raku.org front page you will see a set of button/tabs that select specific code examples - each one of these does...
These results in a more lightweight page and the ability to run code to render the tab content on demand. It's probably overkill for this site rather static needs, but the Air::Base component library tilts towards active HTMX controls wherever possible.hth
Congrats on the facelift of raku.org! Interesting to see the mix of HTMX/PicoCSS and Cro.
The buttons and form inputs are too large compared to standard desktop UI elements.
Yeah. I had to zoom out to 75% in my browser before the text looked normal-ish sized but the "widgets" still looked very big and awkward. Maybe this was designed not just for mobile-first but mobile-only?
Looking at the CSS variables page it seems that this is because they scale up the base font size at various breakpoints, starting at 106.25% at 576px, and going all the way up to 131.25% at 1536px. It definitely feels too heavy handed to me. The first time I viewed the website on mobile it seemed fine (because it's actually at or close to the browser's standard font size) so I wasn't sure what the problem was until I viewed it on my desktop. I can kind of see what they're going for as it keeps the layout fairly consistent, but I don't think it's the right approach.
I agree, but quite easy to scale back with a couple of root values
I wish I started with something like that. At the time my website was just a blog, but I've added tools and forms over the years. I had to create an ad hoc design language and set of components for it. Pico would have been far more effective.
I love the focus on semantic HTML, because it matches how I write CSS. The HTML should be as pure and as style-agnostic as possible.
I use Pico with LLM code gen for new projects. As you probably know, LLMs are predisposed to Tailwind and coding for industrial strength on any tiniest projects. The trick is to feed it the whole Pico docs as context and prompt it (i.e. in your CLAUDE.md) to use Pico explicitly.
Did you do anything fancy to get the whole Pico docs into context? I see on their website that their docs are split up across a bunch of pages, did you copy+paste each one into a large prompt document? I was hoping to see a single-page docs download but I didn't find one.
OT-ish but, can someone point me to a minimal framework that does collapsible trees ?
You will need to write custom CSS, but collapsible trees are totally possible to do purely in CSS in any framework via a simple combination of checkboxes, labels, pseudo-classes and CSS combinators.
The `:checked` selector allows you to target checkboxes that are checked. So you can have a set of checkboxes (off screen with an absolute negative position or similar) that are controlled via a <label> element that wraps the + or - text in the tree. Then based on its state, you can target elements directly afterward to be expanded or contracted using the CSS adjacent sibling combinator.
Checkboxes are neat because they provide state management natively in the DOM and you can do a lot via CSS based on that ;) Thus, you have pure HTML and CSS collapsible trees.
98.css has this with the details html element
Hell yes, this is geat! It's a shame it uses pixels instead of physical+relative units (like pt/mm + em/ex/rem) but still better than tailwind or bootstrap horrors
I’m using Pico for a hackathon project. It’s a good way to prototype, especially the class-less version. You don’t need to pay attention to every detail to get the concept in a good enough state, nor do you need an LLM to remind you of Tailwind’s library of classes
I won't call Pico "minimalist". I'd call it "understated but pretty complete", with a ton of attention to detail, and oodles of customization variables.
pico.classless.css is 2458 lines long.
I like to use Pico CSS as a starting point for websites (as opposed to apps). I even put it in the my Django starter kit (https://github.com/stribny/sidewinder/). Recommended!
I suppose the title should be _Minimalist_ CSS Framework. At 71kb it really isn't minimal.
Four years ago I wrote https://news.ycombinator.com/item?id=28860500:
> Not fond of Pico.css’s weight, though: over 50KB, nowhere near as lightweight as the name suggests (even if it’s above-average compressible, 8KB gzipped—but I wouldn’t count even 8KB uncompressed as pico); in this case, if you flatten the variables and strip unused code, you’re left with under 4KB (~1.4KB gzipped). Lots of bloat from unused light mode support, things like form controls, and a fair bit of frivolous custom properties usage. This is the sort of place where I see the appeal of the likes of Tailwind, because they generate such huge amounts of CSS that you just about have to use an unused style remover. But it is another build step, and contrary to the deliberate intent here.
And it sounds like it has grown further. I don’t see 71kb, I see 83KB (11.6KB gzipped, 10.1KB brotli). At that point I wouldn’t even call it small, and it’s even getting past medium-sized into large territory.
There is also a semantic-based CSS that is overwhelmingly smaller than this one: https://newcss.net/
And I think this is so minimal
New.css developer here, thanks for sharing :)
I’ve been thinking about creating a CSS tool somewhere about halfway between new.css and Pico CSS for very basic page layout tools (containers, callouts, menu bars, etc) that still focuses on being extremely small and performant.
I feel that a tool like that would be helpful for laying out a simple but functional site (sourcehut’s site [1] comes to mind) where you need a few basic layout tools but don’t need all of Bootstrap.
[1]: https://sourcehut.org/
I’d love to see NeatCSS on your list. It’s not officially classless but I try to make it semantic as much as possible. I bookmarked you GitHub repo (which you should link on the page if I didn’t miss it). I’ll give it a try myself to see if it works (and maybe make adjustments).
I think this would be excellent. There's a whole class of websites /landing pages which right now Astro seems to be filling that niche. It's mind boggling how hard it is to do basic components on the web
Tailwind is semantic too because the class names say what they do.
That's not what semantic means.
I agree. beercss is less than 20kb and about the biggest 'minimal' I would consider
That’s if you load it all from the CDN though, build your own with SASS and it’s much smaller.
Indeed. I was expecting 5-10Kb. Tbf, it's only 11 zipped.
At Neat CSS website author says that zipping needs some action at browser side and it is not worth it for small css frameworks…
I frequently use Pico for demo websites like https://demo.rubomonolith.com. You don’t have to worry about styling and you get something that looks reasonably polished.
I can't possibly recommend class based CSS soup anymore. Once you go with utility classes it's hard to go with anything else. It's super intuitive, you don't have to dig through loads of CSS files to figure out where the CSS is and you can simply remove or add classes as you need and see it right there in front of you.
How do you manage the html where you can't even see the tags anymore and it's a spaghetti of utilities in the template for example:
<!-- Like his --> <div class="px-4 py-2 bg-blue-500 text-white rounded shadow-md hover:bg-blue-600">
<!-- Instead of this --> <div class="btn-primary">
You don’t edit it much after it’s done.
You get used to reading any code the more you read it.
Or just <button>…
It really feels like all these concerns about semantic everything belong to a previous era of the web. I remember arguing with people 20 years ago who believed RDF and the semantic web was going to take over, but the use cases never materialized.
Semantic web is a bit different from semantic HTML.
As I understand it, the main point of semantic web is making the web machine readable, often using languages specifically designed for that task that are not HTML.
Semantic HTML is more concerned with writing standardized HTML that leverages browser capabilities and respects users who use assistive technology to browse the web.
Frankly, I don't see what this framework has to do with either. I was curious about how they implemented the dropdown menus, and they're specially styled <details> elements, which are normally used for accordions. That seems a bit strange to me, because the obvious choice for a dropdown is the <select> element.
The use cases are perfectly material, but unfortunately the ad business depends on shitty, ever-changing HTML and scripting shenanigans.
What did you/do you use the semantic web for?
Not much, since we’ve never really had it, but yes, I would love to consume hypertext like a stable API, have user-styles and block elements I don’t like. I do these things now, too, but in a better world they could be less of a hassle technically and less niche socially, then I’d do them even more.
Here’s a uBlock Origin style I use for hackernews, for example:
This is largely a classless framework. Meaning it typically styles tags themselves.
The hill is pointed at and the soldiers will fight, but obviously it depends what you are doing. Jira wont move to classless, but a blog might.
> I can't possibly recommend class based CSS soup anymore.
Me neither!
> you can simply remove or add classes as you need
That sounds like exactly what I was thinking when you said class soup.
> you don't have to dig through loads of CSS files to figure out where the CSS is
The CSS should be in your components, or in a .css file beside your components at worst. React having bad defaults doesn't need you need to change to adding 20 classes to every HTML element.
I've stopped doing frontend several years ago but it doesn't really feel like the trade off of the newer styling solutions vs just CSS Components for scoping are worth it.
this is exactly correct … Gnat CSS is a great way to police encapsulation imo
...and then you need to make all your buttons of a certain type 5px taller or a different color, and you have to go replace the utility class in all 40 buttons. But not any other elements that use the same utility class.
Instead of if you'd just given them all the same semantic class ".config-button" or ".sidebar-button" or ".btn-hero" or whatever, you could make that change in a single place.
If your CSS has turned into soup, I have to be blunt: you're doing it wrong. And you should never have to "dig through loads of CSS files to figure out where the CSS is", it's 1) literally in your browser inspector when you select the element and 2) your CSS files should be organized so it would be easy anyways. Finding a class is as easy as finding a function definition.
Utility classes are for people who want to throw away all the benefits of semantic naming because they don't want to go to the trouble of actually organizing their user interface, even though they see the value in organizing the rest of their code. I honestly don't get it.
The big missing piece for me was that these strategies are meant to be used with React or some other framework. So, in your example, you actually only edit in one place, a SidebarButton component.
... And end up with elements that have dozens of classes until you need to parse CSS in your head in order to figure out what the element is supposed to look like. This methodology completely misses the point of using classes to begin with.
Good class and ID names should be semantic, just like the markup. Don't describe what the CSS does; describe what the element is.
Not only that, but it introduces useless abstractions that could've been avoided by just writing CSS directly. How is `.content-center` better than `align-content: center`?
Tailwind and its ilk are one of the worst trends to have ever happened in web development. It's making people forget how to use CSS, while being useless in the process. I truly don't understand it. And, yes, I've worked on projects that used it extensively. It's awful.
> I truly don't understand it
Quick iteration and good relative spacing for margins, paddings, dimensions etc.
A lot of people combine Tailwind with something like Vite so they're getting instant previews and don't need to swap focus to a style sheet to style their component. I swapped to Tailwind and honestly could never swap back.
I appreciate strong opinions, but I appreciate good arguments even more. And there's just nothing here.
You're raising a bunch of meyerweb talking points from 2003, except why? WHY does markup need to be "semantic" in the sense that you mean? Actually, WHY? Provide a supporting argument that it makes a difference to developers or end users. Remember, we've all been doing it that way for years, and we switched to Tailwind. You need to have something more compelling to developers who have already made up their minds.
> Not only that, but it introduces useless abstractions that could've been avoided by just writing CSS directly. How is `.content-center` better than `align-content: center`?
There are several reasons, but media queries would be reason 1. Why is it useless, again? Remember, we can't tell what your high-level abstractions do without opening at least two files, plus we have to understand any inherited/cascading rules on top of that. If that complexity doesn't matter, then it's argument time again.
> It's making people forget how to use CSS
Tailwind relies on CSS for its class names. How would one use it without knowing CSS in the first place? Secondly, why would it be bad (argument time again)?
The reasons for Tailwind are well understood. It's way faster, trivial to pick up, and easier to maintain longterm, especially in a team environment, than bespoke CSS/DOM abstractions that have layers of hidden complexity. Now, what does your way of doing CSS offer? Remember, tons of people switched from older methodologies to Tailwind and have already priced in the benefits, small as they were.
Tailwind v4 even tree shakes now so it only imports what you need eliminating the bloat argument
> WHY does markup need to be "semantic" in the sense that you mean?
If you've been hearing about this since 2003, then I shouldn't have to repeat the reasons here. You can look up countless articles that explain exactly why semantic HTML and CSS are a good thing much better than I can do justice here.
> There are several reasons, but media queries would be reason 1.
That still doesn't explain why e.g. `class="w-16 h-48 md:w-32 lg:w-48"` would be preferable over a single class that describes what the element is and defines how it should look like and behave.
I mean, to steel man your argument, I get the appeal of getting predefined and consistent breakpoints, and being able to prefix or suffix classes with sizes. But that doesn't seem like a worthy tradeoff for losing legibility, and polluting the markup with this noise. It's the same as declaring all CSS inline, except using classes.
> Remember, we can't tell what your high-level abstractions do without opening at least two files
A good class name will tell you what the element is, not what it should look like. For that, you look at the CSS. Whether that CSS is defined in the same file or in another file, is up to you.
> plus we have to understand any inherited/cascading rules on top of that
Yes, that is what the "C" in CSS stands for, and it's a useful feature for propagating and combining rules without having to redefine them on every element.
If you want to avoid this "complexity", there are numerous ways to scope rules to a specific element or component. Most modern frameworks can scope styles per component for you. And with cascade layers, you now have more control over how and when rules are applied.
> Tailwind relies on CSS for its class names. How would one use it without knowing CSS in the first place?
Some class names are straightforward to understand and use, but others, like the example I posted above, require knowledge about Tailwind itself. Users can become proficient with this syntax without ever understanding what's happening underneath, thus degrading their CSS knowledge. You said it yourself—you want to avoid looking at CSS files altogether. How long would it take for you to not be able to write CSS directly?
> It's way faster, trivial to pick up, and easier to maintain longterm, especially in a team environment
Those are highly subjective, and I would argue against it being easier to maintain. When all your elements use dozens of utility classes, how do you ensure that the styles are consistent throughout the app? One typo in any of the class names can cause inconsistencies that are difficult to spot in a code review.
Oh, use reusable components, I hear you say. Well, why don't you just define the CSS in the component itself then?
Or, no, you use another abstraction on top of Tailwind like daisyUI, which is an insane attempt to bring back sanity into this workflow.
> than bespoke CSS/DOM abstractions that have layers of hidden complexity.
What abstractions?? It's literally a group of rules with a descriptive name that tells you a) what the element represents in the context of the app, and b) how it looks and behaves. There are no abstractions there.
The reason the classes are "bespoke" is because every app will be different. You might want to share some common rules between apps, and we've been doing that for decades just fine. I don't see how grouping utility class names inline makes you any faster or more productive than grouping rules in CSS declarations in the same or external file, and giving them a descriptive name.
> Remember, tons of people switched from older methodologies to Tailwind and have already priced in the benefits, small as they were.
Tons of people use and swear by bloated and complicated frontend web frameworks too, so the popularity of Tailwind doesn't surprise me. I can still have the opinion that it's all wrong, which you're free to disagree with.
Tailwind is basically the VB6 of modern web development. It's popular for all the same reasons (I'm not saying they are good reasons, just that we've seen all this before in a different iteration).
Love Pico CSS. I've used it for close to a decade on https://www.fortressone.org - just works, and looks pretty enough out of the box.
Really love how this project is evolving. It helps you write components with better accessibility without compromising maintainability (it actually improves it) and it's easy to customize.
I've tried using this before and pretty quickly migrated away. While I like the idea of it, the default styling is not great and I felt frustrated with the amount of adjustments it needed to support a data-dense site.
Does not work in older browsers, iOS 13.6
Strangely latest bootstrap works just fine.
Pico is great! It's nice to see it hitting HN front page.
I use tailwind but sometime extremely lightweight CSS framework like Pico is a good starting point to build the foundation for any projects.
How does this compare to pure css?
I love the idea, but why can't I install with npm and import as plain CSS?
FastHTML uses Pico CSS by default
yeah but does claude know how to use it?
LLMs may know the v1 version of PicoCSS, which has some differences from the current v2 (e.g. no SASS).
Claude knows how to use plain HTML.
Yes it does
agents.md will help if it doesn't
Wish it had a tab component.
I honestly can no longer tell which “minimal CSS frameworks for semantic HTML” I have not seen on the front page of HN and which are repeats. Are they all the same at this point?
Not specifically picking on this one, just that it seems that they are the quick to crank out type of libraries and everyone has their own.
The neat thing about semantic HTML is that the CSS ought to be pretty interchangeable.
Sure but why would I do that? When was the last time you decided that the solution to whatever problem you were facing was to switch to a completely different CSS framework without rewriting your HTML?
I’ve had this scenario several times.
The last was when the company I worked for was acquired. We needed to adopt their CSS library for all our applications.
I changed their component based library to have semantic style css and dropped it right in.
The real neat thing is not having to make decisions up front. But you can tweak it later. If you are a rebel you could even use classes to touch up bits you are not happy with.
What I am saying is that I have never done this, have seen the need for this, or have heard of anyone doing this or having the need for this.
To create an absurdist analogy it is like saying that because labels on cotton T-shirts are the same size that you could take them off shirt A and sew them onto shirt B. It is possible by there is zero point in doing it other than to say that you did it.
Correct, there is no need. It is more of a preference, maybe a challenge or code golf type of thing. One advantage is less thinking / decision / boilerplate is needed when adding elements.
Semantic:
p
Normal:
p class=paragraph
Utility:
p class=mx-1 py-1 my-2 text-medium
It is like buying a medium shirt rather than getting a tailor-made t-shirt.
You're mixing "is" and "ought." Why ought styles be interchangeable (remembering that stylesheets and DOM structures often have complex, dependent relationships that are rarely as simple as Pico or anything similar).
I said what I meant to say, I don't understand your reply.