sakura.css: a classless CSS theme you drop into existing HTML

The problem sakura.css solves: unstyled HTML and class-name fatigue

Most CSS frameworks ask you to learn a vocabulary before you can render anything. You add classes to buttons, grids, cards and alerts, and the markup carries the framework's naming decisions forever. sakura.css inverts that. The README calls it a minimal, classless CSS framework and theme, and the pitch is literal: drop sakura.css into any webpage and go from an ugly-looking 1900s website to a pretty, modern website. The selector surface is the HTML element itself, so a page written years ago with plain h1, p, ul, table and blockquote tags gains spacing, type scale and color without a single edit to the body.

The audience follows from that. The README lists quick prototyping when working on backend sites and you cannot yet be bothered to fidget with CSS, building a quick site or blog for a relative, and pages generated by a Markdown parser. That last case is the strongest one. Markdown output has no classes to attach, so class-based frameworks force hacks such as injecting .img img-responsive into every img tag. sakura.css has nothing to inject, which is why the README says it eliminates that need.

How sakura.css works: element selectors, SCSS variables and a duotone palette

The repository is split into scss/ and css/. The SCSS sources compile to the plain CSS files that consumers actually load, and the build script is sass --no-source-map scss:css. That means the shipped CSS is generated, not hand-maintained, and the theming layer is a set of SCSS variables rather than CSS custom properties exposed to the browser.

The theming model is described in the README as duotone color scheming. Two colors carry the design: blossom is the revealing or stark color, and fade is the more prominent one. Around them sit four more variables. color-bg is the page background, color-bg-alt is used for code blocks and similar surfaces, color-text is the color of all text on the page, and font-size-base sets the root size. A theme file overrides those variables and then imports main, which is how the bundled themes in the css folder are produced.

That is the whole architecture. There is no JavaScript runtime, no component registry and no build step required of the consumer. The trade-off is that customization happens at compile time in SCSS, so a consumer who only links the published CSS file cannot retheme it through those variables without either recompiling or writing plain CSS overrides on top.

Installing sakura.css from the CDN or npm

The README marks the CDN as the recommended route. You add one link element to the head of the document and the page is styled on the next load. The URL points at the npm package through jsDelivr.

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/sakura.css/css/sakura.css" type="text/css">

If you prefer to keep the file in your own tree, the README gives a wget command against the raw GitHub path, after which you link the local copy.

wget "https://raw.githubusercontent.com/oxalorg/sakura/master/css/sakura.css"

<link rel="stylesheet" href="sakura.css" type="text/css">

For projects already using a package manager, the package name is sakura.css and it installs from npm or Yarn.

npm install sakura.css

The published package exposes css, scss and package.json, with main pointing at css/sakura.css, so the importable path after installation is the file under css/. The README also recommends normalize.css as an optional reset applied before sakura. It is not required, but the ordering matters if you add it.

Dark mode with a media attribute, and the bookmarklet for legacy sites

Dark mode is handled entirely by the browser's preference query, not by a toggle in the page. The README shows two link elements where the second one carries a media attribute, so the dark stylesheet is fetched and applied only when the operating system reports a dark preference.

<link rel="stylesheet" href="https://unpkg.com/sakura.css/css/sakura.css" media="screen" />
<link rel="stylesheet" href="https://unpkg.com/sakura.css/css/sakura-dark.css" media="screen and (prefers-color-scheme: dark)" />

Note that this example points at unpkg while the installation section uses jsDelivr. Both are documented in the README, and the file names differ by the sakura-dark.css suffix. There is no in-page switch described for this approach, so a user who wants to override their system setting has no built-in control.

The other delivery path is a bookmarklet, credited in the README to Zhouzi. Its purpose is the inverse of the usual use case: instead of building a site with sakura, you enable sakura on someone else's site that has no CSS at all. The package defines a bookmarklet script that builds ./src/bookmarklet.js into ./dist/bookmarklet.js. The README links to a dedicated bookmark page rather than embedding the code, so the installation detail lives there and not in the main README.

Writing a theme: overriding the duotone variables in SCSS

A custom theme is a small SCSS file. The README uses scss/sakura-earthly.scss as the example, and it sets six variables before importing main. The comments in that file explain the split: blossom is the stark color, fade is the more prominent one, bg is the page background, bg-alt covers code blocks, text is all body copy, and font-size-base controls the root size.

$color-blossom: #338618;
$color-fade: #5e5e5e;
$color-bg: #f9f9f9;
$color-bg-alt: #C7E3BE;
$color-text: #4a4a4a;
$font-size-base: 1.8rem;

@import "main";

Two things are worth noticing. First, font-size-base defaults to a fairly large 1.8rem in the example, which is a deliberate readability choice and also the first thing anyone embedding sakura into a dense dashboard will want to change. Second, because these are SCSS variables and not CSS custom properties, the override has to happen at build time. If you consume the prebuilt CSS from the CDN, none of these names are available to you in the browser, and your only route is to write your own rules after the sakura link.

Where sakura.css is the wrong tool

The classless approach has a hard boundary. There are no classes to reach for, so there is no component layer: no buttons with variants, no cards, no grid system, no modal, no navigation pattern. If your interface is a set of application screens rather than a document, you will spend your time writing the component CSS that sakura deliberately does not contain, and you will be fighting the defaults it applies to bare elements at the same time.

There is a second, quieter constraint. Because sakura styles elements globally, it applies to every table, every input and every heading in the document, including fragments you did not intend to restyle. Embedding it in an existing application that already has its own base styles means a cascade conflict rather than a clean layering. The README's own framing acknowledges this: the recommended use is a whole page or a whole small site, and the bookmarklet exists precisely because retrofitting is a different operation from building.

The maintenance picture is also worth stating plainly. The last push to the repository was on 2026-04-07, and the most recent release listed is 1.5.1 from 2025-06-24. That is a slow cadence, which is defensible for a stylesheet whose surface is stable HTML elements, but it means you should not expect new components or a rapid response to edge cases in rendering.

Alternatives and how their approach differs

The obvious comparison point is normalize.css, which the README itself recommends running before sakura. The difference in intent is the whole story. normalize.css makes browsers render elements consistently; it does not make them pretty. It sets no type scale, no color palette and no spacing rhythm. sakura.css is opinionated about all three. That is why the README suggests them together rather than as substitutes: normalize handles the cross-browser baseline, sakura supplies the design.

Against class-based frameworks, the difference is where the vocabulary lives. A class-based framework puts its API in your markup, which is an advantage the moment you need a second button style and a disadvantage when your HTML comes from a Markdown parser or a legacy CMS you do not control. sakura.css cannot express a second button style, because it has no class to vary. Choosing between the two is really a question of whether your markup is yours to edit.

Editorial conclusion

Adopt sakura.css if your pages are mostly headings, paragraphs, lists, tables and code blocks, and you want them styled without touching markup. Skip it if you need buttons, cards, grids, modals or any component with its own class API, because the project does not ship one. Before committing, open your own page with the CDN link and check how your forms, tables and code blocks render, then decide whether the default font-size-base of 1.8rem and the duotone palette are close enough to your intent to keep.

Frequently asked questions

Official sources

1. License: MIT
2. oxalorg/sakura on GitHub
3. Project website
4. README
5. Releases