# Classless CSS is a rendered index with one archived demo link and no licence file

> A curated list of stylesheets that style plain HTML without you adding classes, split into a strict and a loose category and rendered from a data file rather than written by hand. The screenshots are generated too, in two sizes, and they are uneven: one entry has eight, most have one.

**dbohdan/classless-css** — A list of classless CSS themes/frameworks with screenshots

- Repository: https://github.com/dbohdan/classless-css
- Stars: 2,378 · Forks: 61
- Language: HTML
- License: not declared
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/dbohdan-classless-css

## The category is defined by what you do not have to write

The whole taxonomy rests on one sentence, and it is a definition by absence.

> Classless means a style sheet does not define special classes you must add to your HTML elements to style these elements.

So the test is not how a stylesheet looks but what it demands from the markup: link it and a plain HTML page is styled, with no class attributes to invent. The page names prototyping as the use case, which is exactly the situation where you have unstyled markup and no budget for naming things well. That is a coherent scope for a list, and it is also why the list needs two buckets rather than one, since the interesting disagreement in the ecosystem is about how strictly a stylesheet holds to the rule. The entries are given as links to a repository, a website or a demo, so the list is a set of pointers rather than an opinion about any of them. There is no scoring, no ranking and no stated preference between entries.

## The page is rendered from a data file, and the make file is an input

The readme is not maintained by hand. The build file is four lines long.

```makefile
README.md: README.md.njk render-template.ts Makefile data/projects.toml
	./render-template.ts README.md.njk data/projects.toml > $@
```

Two things follow. First, the entries live in a data file, so adding a stylesheet means editing structured data and rerunning the generator rather than writing a section with links and an image in the right order. Second, the make file lists itself as a prerequisite, so touching it regenerates the readme even when nothing about the list changed. The recipe runs a TypeScript file directly rather than through an interpreter, which means the file is expected to carry its own shebang and the executable bit. The default goal is the readme itself, so a bare make invocation regenerates the page. None of this is unusual for a generated catalogue, and it is worth knowing because it means the formatting consistency of the page is a property of the template while the content is a property of the data.

## The screenshots are generated as well, in two sizes

The tree carries a generator for the images as well as for the page: a script whose name says it produces screenshots, and a separate HTML file that is evidently the page those screenshots are taken of.

```text
Makefile
README.md
README.md.njk
data/
gen-screenshot.ts
render-template.ts
screenshot-page.html
screenshot/
thumbnail/
```

Two image directories rather than one means there are two sizes of the same capture, one full size and one reduced, with the page and the index each using the size that suits it. The filenames encode what the reader is looking at, and they encode two things at once: the theme and, where a theme has several looks, the name of that look. One entry's files carry a numbered prefix and then a colour name. That is a good convention, because it means the screenshot for a given look is findable by name rather than by position, and it is also what makes the unevenness in the next point obvious.

## One entry has eight screenshots and most have one

The screenshots per entry range from one to eight, and the variation tracks how many looks the theme has rather than how good it is. One theme gets eight captures, each named for a different palette. Another gets seven. Another gets five. Two entries get exactly two, and in both cases the pair is a light and a dark version of the same theme. Most entries get a single capture with no variant suffix at all.

The consequence is that the list is good at comparing looks within a theme and bad at comparing themes. If you are deciding between two stylesheets, you are almost always comparing one image against one image, chosen by someone else, at a size nobody agreed on. If you are deciding between the light and dark version of a single theme, the list shows you both. A reader should treat the presence of several screenshots as a signal that the author of that entry had more than one variant to show, not as a signal that the theme is more interesting than the ones with a single image.

## One demo link points at an archive snapshot from 2019

The demo links do not live in one place, and one of them is a dead site preserved by an archive.

```text
[Demo](https://web.archive.org/web/20191010034508/http://barecss.com/)
```

That entry's repository link is live and its demo link is a dated archive capture from October 2019, which means the demo for that stylesheet is six years old and is the only way to see it. The honest reading is that the project's own site went away and whoever added the entry chose the archive over a broken link, which is the right call and also tells you something about how the entry was added. Elsewhere the demos sit on a hosted pages site under the author's account, in a code playground, on a deployment platform under a personal account, and on a project's own domain. So the same link label means four different hosting arrangements, and there is no convention telling you which to expect.

## Variants and projects share one column, and one entry carries an author name

The list is not normalised, and you can see it in the names. Four entries come from one organisation and are four looks at the same idea, each with its own repository and its own demo, and each is given its own entry with its own screenshot. One entry has an author's name in parentheses after it, which no other entry does, to distinguish it from a similarly named project. Several entries carry a name that is not a theme name at all, such as the one built on a classical text styling convention or the one named after the web's own core style recommendation.

That is fine for a hand-curated list and it is worth knowing if you want to use it as data. A count of the entries is a count of entries, not a count of projects or of stylesheets, and the difference matters when you are weighing how much of the ecosystem a list has covered. The categories are the same in the navigation and the body: forty six entries under the strict heading and nine under the loose one, fifty five in total.

## The second category is never defined

The strict category gets a definition and a rationale at the top of the page. The loose one does not.

```text
Classless CSS
  Classless
  Class-light
```

The loose category is named and then left undefined, and it is where nine of the entries live, including several well known ones. The best a reader can do is infer the distinction from the names: the loose bucket appears to hold stylesheets that do define some classes and expect you to use them for components, while the strict bucket styles bare markup. That inference is plausible, and it is still an inference, because the page never says so and never says which side a borderline entry is on. The navigation makes the omission easier to miss by nesting both buckets under the page title, so the outline is three levels deep for what is really two sibling lists.

## No licence file, no releases, and a last commit in April

The repository has no licence file among its nine entries and the hosting service records no licence it could classify, so there is no grant on the page at all. That is worth weighing for a specific reason: the page's content is a set of links to other people's projects plus screenshots of those projects' demos, and the screenshots are files in this repository. Nothing in the visible page states what may be done with them.

There are no releases either, and no version to pin, so the list is whatever the default branch holds on the day you look. The last recorded commit on the master branch is dated 2026-04-03. The practical reading for a user is that this is a directory with a fixed capture date rather than a continuously maintained index, and the per-entry links, particularly the demo links, are the part that rots first. The screenshot generation tooling suggests the author intends to keep recapturing, so entries touched in the same season as the tooling are the ones to trust first.

## Conclusion

This index fits someone choosing a stylesheet to make an unstyled prototype look presentable today, and who will spend two minutes opening the demo rather than trusting the screenshot. Three things to know. The list is a rendered snapshot rather than a maintained directory, with its last commit dated 2026-04-03 and no releases, so verify the demo link before you commit to a stylesheet. The loose category is never defined on the page, so if that distinction matters to you you have to ask each project. And there is no licence file at all, while the repository holds screenshots of other people's demos, which is worth settling before you reuse anything from here.

## FAQ

### What is classless css?

A stylesheet that does not define special classes you have to add to your elements, so linking it styles a plain HTML page with no class attributes of your own. The list points at such stylesheets and splits them into a strict category and a looser one.

### How is the Classless CSS list built?

The page is generated rather than hand written. A make target renders a template against a data file of projects and writes the readme, listing the template, the data file and the make file itself as prerequisites, and a separate script plus page produce the screenshots.

### How many classless CSS themes are on the list?

Forty six in the strict category and nine in the looser one, and the loose category is never actually defined on the page. Some entries are variants of the same project rather than separate projects, so the entry count is not a count of projects.

### Why do some Classless CSS entries have several screenshots?

Because those themes have several looks, and the filenames name the look rather than numbering it. One entry has eight, another seven, another five, two entries have a light and a dark pair, and most have a single capture, so the list compares looks within a theme better than it compares themes.

### Can I reuse the screenshots in the Classless CSS repository?

The repository contains no licence file and the hosting service records no licence it could classify, so the page states no terms for its contents. The screenshots are captures of other projects' demos held in this repository, so that gap is worth resolving before reuse.

## Sources

- [dbohdan/classless-css on GitHub](https://github.com/dbohdan/classless-css)
- [Issues](https://github.com/dbohdan/classless-css/issues)
- [README](https://github.com/dbohdan/classless-css/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dbohdan-classless-css