missing.css styles plain HTML before you write a single class

One stylesheet link is the entire installation

The installation is a single tag in the head of your page:

<link rel="stylesheet" href="https://unpkg.com/missing.css">

There is no build step, no bundler plugin and no JavaScript to initialise. That is the shape of the project in general: it is a stylesheet, and the entire distribution is one CSS file served from a CDN.

The package file confirms that shape. The package is named missing.css, version 1.3.0, authored by Deniz Akşimşek, and its main entry is `./dist/missing.min.css`. The exports map points the root to that same minified file, exposes everything under `dist/` through a wildcard path, and adds a separate `./prism` export pointing at `./dist/missing-prism.min.css`, which is the syntax highlighting stylesheet.

The only script defined is a prepack hook that runs `mise run build`, so the published artefact is built from source before it ships. The file list in the package is just `dist/`.

Two themes of development signal sit alongside it. There is a CHANGELOG.md for release notes and a JOURNAL.md, which in this project is a development journal rather than a news feed. The default branch is dev rather than main, so the stable state lives elsewhere. The repository has no GitHub releases, the published versions are listed on the site's own releases page, and the last push was on 2026-06-13.

Three layers: defaults, semantic components, then utilities

The design is described as three distinct layers, and the order matters because each one is a different kind of intervention.

The first layer is default styling for vanilla HTML, described as akin to classless CSS libraries. This is what makes the library feel different from a utility framework: your elements look reasonable before you add anything to them.

The second layer is a small set of components built on well-known, semantic markup patterns, with ARIA where appropriate. Components here are not a widget library with JavaScript behaviour attached. They are CSS for markup you would write anyway, which means an accordion styled by missing.css is still an accordion built from the HTML you choose.

The third layer is a small curated set of utility classes and custom elements, for bespoke elements and layouts.

The stated goal is to reduce needed intervention in HTML. Four consequences follow from the documentation: you start with a good out-of-the-box experience, you can customise it easily and create multiple themes, you build common components from plain semantic HTML, and you create unique sites by applying utility classes as needed.

That last combination, defaults plus a little utility use, is what makes the library a different proposition from either extreme of the CSS framework market.

The project rules out the two frameworks it resembles

The most useful sentence in the documentation is the one that says what this is not. missing.css is not designed to be a complete styling solution for large websites. It may serve as a basis for a more completely styled site, but it does not try to be as complete as Bootstrap or as versatile as Tailwind.

That is a deliberate boundary rather than a deficiency. The same passage then says the library is explicitly designed to be complete enough to use for small sites, internal tools or personal projects.

Read as an adoption rule, it tells you where the library stops working. A marketing site with a design system, a large application with many screens, or anything where a designer has specified a component library is out of scope. A documentation site, a small dashboard, a personal blog or an internal admin tool is exactly where it fits.

The comparison to the two named frameworks is about scope, not about quality. Bootstrap offers a complete component set and Tailwind offers a broad utility vocabulary. missing.css offers enough to avoid starting from a blank stylesheet, and the documentation is candid that this is a different choice rather than a lesser version of the same idea.

The project comes from Big Sky Software, and the documentation points readers to htmx and _hyperscript as related projects.

Themes and customisation are first-class, not an afterthought

Multiple themes are named as a goal of the library, alongside easy customisation. The mechanism behind that is the layer structure: because the base layer is plain element selectors, a theme can restyle elements without needing to rewrite utility classes.

The components layer adds the constraint that a theme has to respect. A component built on semantic markup has to survive being restyled, which means the CSS cannot depend on a particular class name being present in a particular place.

The site around the library carries the same set of tools a CSS project needs to be usable by more than its author. There is a docs section, a set of demos, a playground, and a separate releases page hosted alongside the site, all linked from the top of the documentation. The Discord link points at the htmx community server rather than a separate one.

The repository layout supports a documentation site rather than a bare style file. There is a www/ directory holding the site, a src/ directory for the stylesheet source, a .config/ directory for tooling configuration, a .netlify/ directory with a netlify.toml at the root for deployment settings, and a statichost.yml for an alternative static host. A package-lock.json is committed, and a CHANGELOG.md, CONTRIBUTING.md and JOURNAL.md sit alongside the licence file.

Classless CSS as a starting point, with utilities as the escape hatch

The repository topics describe the project as classless-css, classless-css-framework and classless-theme, alongside css-framework, css-library, deno and postcss. Those tags describe the lineage and the tooling rather than the finished library.

The distinction the project draws is between a classless library and what it calls classless-ish, which is the phrase in the repository description. A pure classless stylesheet has no classes at all and you accept whatever it gives you. missing.css starts there and then adds the utility layer, which is why the description hedges.

The tag list also names two tools that are not in the code itself: deno and postcss. Deno appears as a runtime for the build tooling, and postcss as the CSS processing step. The `mise run build` prepack command is what ties those together, since mise is a task runner that the package relies on to reproduce a build.

For an adopter, the practical implication is that you can consume the library from a CDN with no toolchain at all, or vendor the file, or build from source if you want to change the tokens. The last option is the one that needs postcss and a working Deno or Node setup, and it is the reason the repository ships source rather than only a minified artefact.

Where the project's limits show up in a real project

The documented scope implies three failure modes, and it is worth stating them plainly.

The first is scale. Small sites and internal tools are covered. A site with dozens of screens and a shared component library is not, and the project says so before you discover it.

The second is markup quality. Because the base layer styles vanilla elements, the output depends on the HTML you write. Semantic, well-structured markup gets good results, and a document built from generic containers and divs will not pick up the component styles however good your CSS tooling is.

The third is the small size of the utility set. It is described as curated, which means the layout helpers you need for an unusual case will not be there. At that point you write CSS, and you have left the part of the framework that gave you speed.

None of these are defects. They are the same boundaries the project states, and they are a reasonable trade for a library that adds one link tag and nothing else. A team that wants a complete design system should reach for something else; a team that wants a page to look decent this afternoon has found the right tool.

The licence is BSD-2-Clause, which permits use, modification and redistribution in source and binary form with the notice retained. The package file records the same licence.

Editorial conclusion

Adopt missing.css when you are building a small site, an internal tool or a personal project and want decent default typography and spacing without writing utility classes by hand. Skip it if you are shipping a large website that needs a complete component system, because the project explicitly says it is not designed for that and does not aim to be as complete as Bootstrap or as versatile as Tailwind. Verify first that the plain HTML you already write gets acceptable results, since the library's value depends on your markup being semantic, and check the version, which the package file lists as 1.3.0.

Frequently asked questions

Official sources

1. bigskysoftware/missing on GitHub
2. Issues
3. License: BSD-2-Clause
4. Project website
5. README