> To stay relevant, Pico CSS would need a full rewrite: plain modern CSS instead of Sass, built on features it doesn't use today (OKLCH colors, cascade layers, Popover, anchor positioning) with fallbacks for older browsers
Why? Why? Why? I hate how everyone seems convinced they need to adopt the latest and greatest browser features just to stay relevant. I hate oklch and I hate Tailwind popularized it. I don't care how scientifically accurate it is at representing human color perception. It's a PITA to understand a new type of color system, and learn to tweak it, especially when HSL/RGB just worked fine.
I don't get any of this hate. oklch makes it really easy to create new tones from a starting point and stuff like anchor positioning also makes it really easy to place absolutely-positioned things. So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
This just seems to me like (1) not wanting to learn new things, (2) a logical fallacy because the conclusion that those changes are to "stay relevant" and not to make the life of any future mantainer easier, and (3) fear of the new (https://en.wikipedia.org/wiki/Neophobia)
> So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
What justification do you have to adopt and replace this with existing solutions with such urgency? Have you researched its compatibility? Are you providing any fallback?
This just seem to like 1) you are not applying your mind why you want this, 2) faulty premise that it makes it easier, because in reality your software never reaches a point of maturity, where its just "done", and 3) shiny object syndrome (https://en.wikipedia.org/wiki/Shiny_object_syndrome)
Are RGB and HSL color models all broken and useless? Yes, I know their limitations. But of all graphical software I use daily. only GIMP supports LCh, and using it is pretty unintuitive.
I see how position-anchor and stuff are coll for complex layouts, but they have poor support on low-power mobile browsers, and, frankly, are not that useful for a minimalistic CSS framework. If you want complicated layouts with non-obvious anchoring rules, you're not the target audience.
Cascade layers are very useful for complex designs with many independently added stylesheets. They would be great to have. OTOH again, if you need this level of complexity, you're likely not the target audience of a pico-sized CSS framework.
I would say that a minimalist framework should make judicious use of CSS3 features, and not try to be excessively clever. In reliable engineering, being smart often means avoiding being clever.
I'm building https://minium.style in the same vein as Pico, but with the features it does not use today (plain CSS, cascade layers, Popover, anchor positioning). No fallbacks for older browsers yet, but I have plans to solve that.
Ios 13.6 in my case, which was released just 6 yrs ago, 2020. For some context, flexbox gap was added in ios14.1, released in 2021. So iOS 13.6 was still usable atleast couple of years beyond that. So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
People keep forgetting that css3 was announced in 1999. And adoption roughly started from 2010. The css3 of that time is not the same as css3 you get to see in latest browsers. These minimal css frameworks are really useless if you don’t know what css3 features you are writing and who you are targeting.
And, I Haven’t even tested those in less capable browsers like dillo or netsurf, but I doubt they will even work there.
If you start looking into browser market share, you will quickly realise that there are millions of worldwide users who can’t use the web normally.
First, I confess that I had built quite a lot of CSS Frameworks and Design Systems in my early developer life. So, this is going to be more of a personal experience.
Ever since Coding Assistant LLMs became pretty good (2025-Q4 - 2026-Q1), I feel that it makes very little sense to continue to use pre-defined CSS Frameworks that 'has everything.' Of course, it is still OK if the general team decides on one, and they are OK (such as the Tailwinds, MUI of the frontend world.)
I have used Foundation[1] and Bourbon[2] extensively. Mostly because I can break it down and take just what the project needs and keep it within a low CSS budget for any project.
With that in mind, in the 10+ projects that started for some of the biggest brands of the world, I just defined the CSS framework, design systems, design token, with room for extension as the project grows. Claude Code is my tool of choice for now and I just let it run overnight, tweak as the project scaffolds and finally takes about less than a week to have a complete CSS framework in just plain CSS, and JavaScript where it needs to talk to the broader frontend.
You guys really need to fix your site to be a demo first. See the nimble css page on how to market yourselves well. Right now your site is not telling me anything about how your library works or looks or how it is actually useful to me and how it solves my problems. The questions I actually have when I visit your site.
Thank you very much for your stewardship over the years. And kudos for not just letting it rot, but communicating clearly, and closing it down responsibly.
I haven't done frontend dev in a while, but one thing stands out to me here... they call out using OKLCH colours, which I had to look up. (For the uninitiated, this is a cylindrical projection of the also-new-to-me Oklab colour space, which appears largely unrelated to the older CIE L*a*b* colour space).
Do people actually use this? In particular, before LLMs ate the world, I mean. When I did frontend, it was hex, or if you felt fancy, `rgba(...)` (though at that point named colours had mostly fallen out of style).
Is using these less-intuitive colour encodings made more practical through the use of CSS variables?
Yes, people use it in practice. But it's not being used for the thing you're thinking of.
RGB is fine for specifying a color. I mean, there are issues with RGB colorspaces and whatnot, but if you need to pick the background of a page or the color of text, there's no real reason not to use RGB.
The problem with RGB is that it is really bad at color interpolation. You can't take the average of the red, green, and blue components of two colors and expect a usable color in the middle to come out. Instead, you need to move to a perceptual color space. CIELAB is the old perceptual color space of choice; Oklab is the new perceptual color space of choice.
Color interpolation is needed for things like gradients or information visualization, where you need to say things like "20% of the way between color A and color B".
RGB is also highly unintuitive by itself. Because additive color mixing is unintuitive. There is no way of knowing what RGB mixture corresponds to yellow unless you have memorized it.
Well I use it on my personal site: the colors change with the weather and seasons [1]. Oklab’s so-what is that the hues are perceptually a uniform brightness, unlike HSL (which I started with) where blues and reds look a lot brighter than greens and yellows at the same saturation/lightness.
So in my case where color shifting is happening, Oklab actually helps. I don’t know how it’s better than HSL for simple UI elements unless maybe you can get physically brighter values that pop out more on certain screens.
Yes. OKLCH is actually MORE intuitive when creating shades because it's based around human perception. It also supports wide color spaces like P3, where rgba is, IIRC, bound to sRGB.
The utility of these color spaces and color functions isn't lost just because LLM. Color systems haven't gone anywhere.
Would highly recommend reading up on OKLCH if you haven't already. A lot of people put a lot of effort into promoting this and bringing it to baseline..
Yes, since the last couple of years. I tend to help architect and scaffold large projects that goes on for years, and changes a lot of developers, designers in its lifecycle. I was pretty confident of moving to OKLCH about 4-years ago and have have had it as default. OKLCH values are now the source of truth for these projects, and other design elements — all the way to Powerpoints (HEX/RGB) and Print (CMYK) are derived from OKLCH. There are variations but most people don’t even know the difference.
This started way back working with my long-term business partner and he built a pretty good tool to help visualize and tinker with it.
Yes. And I'd argue it's more intuitive if all colors with the same lightness value are in fact the same lightness. Hue and chroma are pretty easy to understand too.
> To stay relevant, Pico CSS would need a full rewrite: plain modern CSS instead of Sass, built on features it doesn't use today (OKLCH colors, cascade layers, Popover, anchor positioning) with fallbacks for older browsers, and a native compiler that strips unused CSS and makes customization easy.
> To stay relevant, Pico CSS would need a full rewrite: plain modern CSS instead of Sass, built on features it doesn't use today (OKLCH colors, cascade layers, Popover, anchor positioning) with fallbacks for older browsers
Why? Why? Why? I hate how everyone seems convinced they need to adopt the latest and greatest browser features just to stay relevant. I hate oklch and I hate Tailwind popularized it. I don't care how scientifically accurate it is at representing human color perception. It's a PITA to understand a new type of color system, and learn to tweak it, especially when HSL/RGB just worked fine.
I don't get any of this hate. oklch makes it really easy to create new tones from a starting point and stuff like anchor positioning also makes it really easy to place absolutely-positioned things. So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
This just seems to me like (1) not wanting to learn new things, (2) a logical fallacy because the conclusion that those changes are to "stay relevant" and not to make the life of any future mantainer easier, and (3) fear of the new (https://en.wikipedia.org/wiki/Neophobia)
> So it's not like those "latest and greatest browser features" are there just to complicate your life, but actually the contrary.
What justification do you have to adopt and replace this with existing solutions with such urgency? Have you researched its compatibility? Are you providing any fallback?
This just seem to like 1) you are not applying your mind why you want this, 2) faulty premise that it makes it easier, because in reality your software never reaches a point of maturity, where its just "done", and 3) shiny object syndrome (https://en.wikipedia.org/wiki/Shiny_object_syndrome)
Fashion and CV driven development, used to sell conference talks, books and agency work for "upgrades".
> Why? Why? Why? I hate how everyone seems convinced they need to adopt the latest and greatest browser features just to stay relevant.
Presumably we can deprecate the broken shit if we can get people to buy into software upgrades.
Are RGB and HSL color models all broken and useless? Yes, I know their limitations. But of all graphical software I use daily. only GIMP supports LCh, and using it is pretty unintuitive.
I see how position-anchor and stuff are coll for complex layouts, but they have poor support on low-power mobile browsers, and, frankly, are not that useful for a minimalistic CSS framework. If you want complicated layouts with non-obvious anchoring rules, you're not the target audience.
Cascade layers are very useful for complex designs with many independently added stylesheets. They would be great to have. OTOH again, if you need this level of complexity, you're likely not the target audience of a pico-sized CSS framework.
I would say that a minimalist framework should make judicious use of CSS3 features, and not try to be excessively clever. In reliable engineering, being smart often means avoiding being clever.
Some recent alternatives/successors/forks that are in the same vein as Pico
- Nimble: https://leftium.github.io/nimble.css/demo/pico.html
- Sumi.css: https://vladocar.github.io/Sumi.css/docs.html
- Blades: https://github.com/anyblades/blades
- Oat: https://oat.ink/
I'm building https://minium.style in the same vein as Pico, but with the features it does not use today (plain CSS, cascade layers, Popover, anchor positioning). No fallbacks for older browsers yet, but I have plans to solve that.
All of them failed my ten second evaluation. It's amazing how many mediocre CSS frameworks that are out there.
What do you think of https://starter.bryanhogan.com/ then?
Useless - https://ibb.co/h1sRtYKF
Whats the first thing in a CSS framework that you notice and makes you say "nah"?
None of them work on older browser - https://ibb.co/album/3kJP50
Ios 13.6 in my case, which was released just 6 yrs ago, 2020. For some context, flexbox gap was added in ios14.1, released in 2021. So iOS 13.6 was still usable atleast couple of years beyond that. So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
People keep forgetting that css3 was announced in 1999. And adoption roughly started from 2010. The css3 of that time is not the same as css3 you get to see in latest browsers. These minimal css frameworks are really useless if you don’t know what css3 features you are writing and who you are targeting.
And, I Haven’t even tested those in less capable browsers like dillo or netsurf, but I doubt they will even work there.
If you start looking into browser market share, you will quickly realise that there are millions of worldwide users who can’t use the web normally.
> So such frameworks utterly failing on such browsers is hilarious, given that they market themselves as minimal.
Minimal is an entirely different property to backwards compatibility.
When you say something is minimal, you are implying that what little you provide will also work. Which in this case is clearly not.
motherfuckingwebsite.com is more minimal and usable than these frameworks.
> None of them work on older browser
There are older browsers which still get security patches?
I really enjoyed using Pico CSS, but I understand the choice.
Thank you Lucas Larroche for building Pico CSS and sharing it with us.
First, I confess that I had built quite a lot of CSS Frameworks and Design Systems in my early developer life. So, this is going to be more of a personal experience.
Ever since Coding Assistant LLMs became pretty good (2025-Q4 - 2026-Q1), I feel that it makes very little sense to continue to use pre-defined CSS Frameworks that 'has everything.' Of course, it is still OK if the general team decides on one, and they are OK (such as the Tailwinds, MUI of the frontend world.)
I have used Foundation[1] and Bourbon[2] extensively. Mostly because I can break it down and take just what the project needs and keep it within a low CSS budget for any project.
With that in mind, in the 10+ projects that started for some of the biggest brands of the world, I just defined the CSS framework, design systems, design token, with room for extension as the project grows. Claude Code is my tool of choice for now and I just let it run overnight, tweak as the project scaffolds and finally takes about less than a week to have a complete CSS framework in just plain CSS, and JavaScript where it needs to talk to the broader frontend.
1. https://get.foundation
2. https://www.bourbon.io
Bourbon is no longer maintained.
Guide for replacing its features : https://thoughtbot.com/blog/you-might-not-need-bourbon
I miss 960px grid systems…
https://github.com/anyblades/blades seems to be a continuation in the same spirit
Thanks for sharing! Same spirit, same underlying code.
We’re actively maintaining Blades CSS on GitHub and Discord, and would love Community feedback there.
We also set up a dedicated page outlining key details: https://blades.dev/css/pico/
You guys really need to fix your site to be a demo first. See the nimble css page on how to market yourselves well. Right now your site is not telling me anything about how your library works or looks or how it is actually useful to me and how it solves my problems. The questions I actually have when I visit your site.
Thank you very much for your stewardship over the years. And kudos for not just letting it rot, but communicating clearly, and closing it down responsibly.
A little sad in a way, but this seems like the right call. I haven't used Pico in a very long time, and I don't think I'd choose it today.
What would you choose?
Been working on https://bamboocss.com/ for couple of months.
It's build-time, Rust/Oxc, type-safe, zero-runtime CSS-in-JS, with per-route CSS splitting.
Is zero-runtime CSS-in-JS an oxymoron?
I haven't done frontend dev in a while, but one thing stands out to me here... they call out using OKLCH colours, which I had to look up. (For the uninitiated, this is a cylindrical projection of the also-new-to-me Oklab colour space, which appears largely unrelated to the older CIE L*a*b* colour space).
Do people actually use this? In particular, before LLMs ate the world, I mean. When I did frontend, it was hex, or if you felt fancy, `rgba(...)` (though at that point named colours had mostly fallen out of style).
Is using these less-intuitive colour encodings made more practical through the use of CSS variables?
Yes, people use it in practice. But it's not being used for the thing you're thinking of.
RGB is fine for specifying a color. I mean, there are issues with RGB colorspaces and whatnot, but if you need to pick the background of a page or the color of text, there's no real reason not to use RGB.
The problem with RGB is that it is really bad at color interpolation. You can't take the average of the red, green, and blue components of two colors and expect a usable color in the middle to come out. Instead, you need to move to a perceptual color space. CIELAB is the old perceptual color space of choice; Oklab is the new perceptual color space of choice.
Color interpolation is needed for things like gradients or information visualization, where you need to say things like "20% of the way between color A and color B".
RGB is also highly unintuitive by itself. Because additive color mixing is unintuitive. There is no way of knowing what RGB mixture corresponds to yellow unless you have memorized it.
Well I use it on my personal site: the colors change with the weather and seasons [1]. Oklab’s so-what is that the hues are perceptually a uniform brightness, unlike HSL (which I started with) where blues and reds look a lot brighter than greens and yellows at the same saturation/lightness.
So in my case where color shifting is happening, Oklab actually helps. I don’t know how it’s better than HSL for simple UI elements unless maybe you can get physically brighter values that pop out more on certain screens.
[1]: https://joeldueck.com
> Do people actually use this?
Yes. OKLCH is actually MORE intuitive when creating shades because it's based around human perception. It also supports wide color spaces like P3, where rgba is, IIRC, bound to sRGB.
The utility of these color spaces and color functions isn't lost just because LLM. Color systems haven't gone anywhere.
Would highly recommend reading up on OKLCH if you haven't already. A lot of people put a lot of effort into promoting this and bringing it to baseline..
Yes, since the last couple of years. I tend to help architect and scaffold large projects that goes on for years, and changes a lot of developers, designers in its lifecycle. I was pretty confident of moving to OKLCH about 4-years ago and have have had it as default. OKLCH values are now the source of truth for these projects, and other design elements — all the way to Powerpoints (HEX/RGB) and Print (CMYK) are derived from OKLCH. There are variations but most people don’t even know the difference.
This started way back working with my long-term business partner and he built a pretty good tool to help visualize and tinker with it.
Website https://colorcolor.in
Source https://github.com/saneef/color-color
Yes. And I'd argue it's more intuitive if all colors with the same lightness value are in fact the same lightness. Hue and chroma are pretty easy to understand too.
I love OKLCH. Awkward to say, beautiful to look at.
This is my fave article on the subject:
https://evilmartians.com/chronicles/oklch-in-css-why-quit-rg...
I love plain old Vanilla CSS. Pre-processor-free for a couple years now and don't miss anything.
Pico is a great little library.
Thank you to the developer and maintainer
For what it’s worth I had to force Claude early in to use pico and not ever generate react or ornate tailwind.
Pico is extraordinary for standalone tools where ai can’t let complexity build out of control.
Maybe there’s other options but pico is what got it done, and vanilla LLMs has a hard time keeping something this simple and elegant and flexible.
this
100%
Thank you for the training data
What a tragedy.
> To stay relevant, Pico CSS would need a full rewrite: plain modern CSS instead of Sass, built on features it doesn't use today (OKLCH colors, cascade layers, Popover, anchor positioning) with fallbacks for older browsers, and a native compiler that strips unused CSS and makes customization easy.
Does anyone know a similar project doing this?
We do: https://github.com/anyblades/blades
Already plain modern CSS instead of Sass, has Popover API, and CSS layers for individual components, OKLCH colors are on the way.
Drop-in compatible with Pico CSS (via underlying fork)
But why? Is it not relevant anymore? It's as useful and capable as it was years ago
Hmm. I use pico. They could use an agent to modernize it!
Yeah, but why? Writing code for agents to use isn't fun, and buying tokens for it is a waste of money.