Pico CSS is a classless CSS framework — a framework that styles HTML elements based on their semantic meaning rather than their class names. Write a <button>, get a styled button. Write a <table>, get a styled table. Write an <article>, get a styled article. No classes required. No decisions necessary. No learning CSS.
This is the sales pitch. The sales pitch is accurate. The sales pitch is also a trap.
Pico CSS is what happens when a developer — specifically, a backend developer who builds integration platforms and writes Go binaries and has no interest in learning the cascade — discovers a framework that promises to make CSS unnecessary. The promise is kept. For approximately three months. After three months, the application needs a sidebar that Pico didn’t anticipate, a layout that Pico didn’t provide, and a colour that Pico didn’t choose. The developer, who chose Pico specifically to avoid writing CSS, now writes CSS — but writes it against Pico, overriding its opinions with inline styles and !important declarations, which is not “not learning CSS” but rather “learning CSS in the most painful way possible.”
“When did we write this CSS?”
“Day one. Pico CSS framework with inline style overrides.”
“Inline styles.”
“Yes.style='color: red; margin-left: 12px; font-size: 14px;'— approximately everywhere.”
— riclib and Claude, The Facelift, or The Day the Squirrel Won
The Straight Jacket
Pico CSS is a straight jacket made of good defaults.
The defaults are genuinely good. Pico ships with a dark mode, responsive typography, semantic styling for forms, tables, buttons, and navigation. A developer who writes clean HTML gets a clean-looking page. The problem is that “clean-looking” and “what the product needs to look like” diverge the moment a customer sees it and asks for something specific.
SolidMon — the monitoring product documented across the lifelog’s Solid Convergence storyline — shipped on day one with Pico CSS. The choice was deliberate: riclib needed a UI that looked acceptable while the backend — the part that mattered — was being built. Pico delivered. The UI looked acceptable. The backend was built.
Then the product grew.
“Pico CSS. Inline styles. The kind of UI you build at 2 AM when the backend is the thing that matters and the frontend is ‘good enough for now.’”
"‘Now’ had been going on for a while."
— The Facelift, or The Day the Squirrel Won
Every new feature required overriding Pico’s opinions. The sidebar needed different padding — inline style. The navigation needed a different colour — inline style. The cards needed different borders — inline style. Each override was small. Each override was reasonable. Each override accumulated. After eighteen months, the product was wearing Pico CSS like a patient wears a hospital gown: technically covered, practically constrained, spiritually undignified.
The Facelift
The removal of Pico CSS is documented in The Facelift, or The Day the Squirrel Won, in which riclib opened the product to add one button and discovered the CSS archaeology beneath:
“Is that a
!importanton amargin-leftthat overrides another!importanton apadding-rightthat exists solely to counteract an inlinemargin-left?”
“That is what the archaeologists call a ’load-bearing!important.’ Remove it and three pages collapse.”
“It’s like CSS wrote a suicide pact with itself and both sides are winning.”
— riclib and Claude, The Facelift, or The Day the Squirrel Won
The Squirrel — for the first time — was right. The product needed a facelift. Nine commits in one afternoon. Inline styles died. CSS variables took their place. Pico was removed. The load-bearing !important declarations were demolished. The cat, Oskar, performed QA by sitting on the laptop screen, covering exactly the part of the sidebar that still had one inline style. One more commit. The inline style died.
The Facelift replaced Pico’s opinions with the developer’s intentions — CSS variables, a consistent dark sidebar, Lucide icons, a design system that existed because someone chose it, not because a framework defaulted to it.
The Lesson
Pico CSS teaches one lesson, and teaches it thoroughly: a classless framework is a framework that makes every decision for you, which is perfect until you need to make a decision it didn’t.
The lifelog blog — built after The Facelift, after the lesson was learned — has no CSS framework. It has a function. css() string. 651 lines. Zero !important declarations. Zero external dependencies. The entire visual identity — seven storyline themes, responsive layout, dark mode, Wikipedia-style infoboxes — lives in a single Go function that returns a string.
This is what riclib builds now: not frameworks, but CSS. Per project. Per purpose. Written once, by one person, with full understanding of the cascade because there is nothing to cascade against. The 651-line function is ugly. The 651-line function has no abstractions. The 651-line function works, and will continue to work, because it fights nothing.
Pico CSS was the last framework. Not because it was bad — it was good. But “good defaults” and “your product’s UI” are different things, and the gap between them is filled with inline styles, !important declarations, and the slow realisation that avoiding CSS is more expensive than learning it.
Measured Characteristics
- Pico CSS: classless (zero classes required)
- Classes added by SolidMon to override Pico: 0 (used inline styles instead, which is worse)
- Inline style overrides accumulated: ~347
!importantdeclarations fighting each other: several (each a confession per Liberato’s Law)- Commits to remove Pico in The Facelift: 9
- Time to remove Pico: one afternoon
- Time spent working around Pico: eighteen months
- QA performed by cat: 1 finding (inline style, covered by Oskar)
- CSS framework used in lifelog blog: none
- CSS framework used after Pico: none (ever again)
- Lesson: avoiding CSS is more expensive than learning CSS
