# Beer CSS: Material Design 3 as semantic HTML and three layers of CSS

> A CSS-only framework that claims the first Material Design 3 implementation, ships at 14.5 kB brotli, and reaches dynamic colour through a separate companion package.

**beercss/beercss** — Build material design interfaces in record time... without stress for devs... 🍺💛

- Repository: https://github.com/beercss/beercss
- Website: https://www.beercss.com
- Stars: 2,613 · Forks: 101
- Language: Vue
- License: MIT
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/beercss-beercss

## Three layers, borrowed from a 1516 brewing law

The architectural claim is the interesting part, and the README is upfront that it is not an established methodology. Beer CSS is described as the first CSS framework based on Material Design 3, already carrying the latest M3 Expressive updates, and roughly ten times smaller than other Material Design CSS frameworks. A badge in the README puts the payload at 14.5 kB brotli.

The structure comes from the German Beer Purity Law of 1516, which the README cites as the guiding idea: beer should contain only water, barley malt and hops. The three corresponding layers are Settings, Elements and Helpers, documented separately in `docs/SETTINGS.md`, `docs/ELEMENTS.md` and `docs/HELPERS.md`. Settings affect the whole document, Elements are the components, widgets or tags, and Helpers make elements more scalable and customisable.

The README is careful to say this is not BEM, not OOCSS, not SMACSS, not ITCSS and not utility-first, and that the approach does not avoid some bad practices. That honesty matters more than it might seem, because a naming scheme borrowed from a beer law will otherwise read as a framework from an established family. What you are getting is three layers of CSS convention, not a theory.

## Getting it in: default, scoped or custom element

There are three distributions and choosing between them is the first decision. The default version is a stylesheet plus two module scripts, one for Beer CSS and one for the companion package that handles dynamic colours:

```html
<link href="https://cdn.jsdelivr.net/npm/beercss@5.0.3/dist/cdn/beer.min.css" rel="stylesheet" />
<script type="module" src="https://cdn.jsdelivr.net/npm/beercss@5.0.3/dist/cdn/beer.min.js"></script>
<script type="module" src="https://cdn.jsdelivr.net/npm/material-dynamic-colors@1.1.4/dist/cdn/material-dynamic-colors.min.js"></script>
```

If you prefer a package manager, the README gives the install and import in two lines each:

```js
npm i beercss
npm i material-dynamic-colors
```

```js
import "beercss";
import "material-dynamic-colors";
+```

The scoped version swaps the stylesheet for `beer.scoped.min.css` and applies styles only to children of an element carrying `class="beer"`. The custom element version loads a single `beer.custom-element.min.js` and applies styles to children of a `<beer-css>` tag. Both have their own import lines, `beercss/scoped` and `beercss/custom-element`.

That choice matters more than it first appears. The scoped build is how you adopt Beer CSS inside a page that already has its own CSS without a global collision, and the custom element build gives you a hard boundary in the DOM. Both cost you reach: helpers that rely on document-wide selectors behave differently once the stylesheet is scoped. There is also a local option, downloading everything from the two CDN directories into a folder of your own, for projects that cannot load from jsDelivr.

## What v5.0.3 changed, including a breaking change

The current release is v5.0.3, published on 2026-07-30, and its changelog is the most useful thing in the repository. The headline feature is module support, described as reducing the bundle by up to ten times, documented in `docs/MODULES.md`. Given that the project's entire pitch is size, a feature that lets you import only the components you use is the obvious next move.

The rest of that release is bug fixing, which is worth reading for what it reveals about the edges of a class-based system. The `round` helper was fixed in some button use cases. The `no-round` helper returned in a previous version and now renders square corners properly. A colour theme bug on the `nav` element was fixed. Icon fonts were updated.

Then there is the breaking change, and the project does not dress it up: the default `button` inside a `nav` group element was updated, which changes the rendered markup. The changelog shows the before and after as HTML, and the effect is that a middle button which previously carried `class="no-round"` now carries no class at all, because the group now handles the interior corners itself. A framework that changes your markup in a patch release is telling you something about how much it considers that markup to be its own.

The version before, v4.0.23, came out on 2026-06-29. The repository is not archived, the last push was on 2026-09-20 on `main`, and the licence is MIT.

## The repository is more interesting than the framework

The tree has a few entries that are unusual for a CSS library and worth looking at. There is `llms.md` at the top level, generated by a build script named `llms` in `package.json` that runs `node ./build/llms.js`. In other words, the project maintains a machine-readable description of itself for language models, which is a small thing that says a lot about who the author expects to read this repository.

There are also two Python scripts in the root, `list_labels.py` and `triage_unlabeled_issues.py`. A CSS framework shipping Python means the issue board is maintained programmatically rather than by hand, which explains how 31 open issues coexist with an actively sponsored project. There is a `TODO.md`, a `CONTRIBUTING.md`, a `firebase.json` and `.firebaserc` for hosting the documentation site, and `tests/` driven by `vitest.config.js`.

The build pipeline in `package.json` is short and readable: `dev` runs a dev script, `build` runs a build script followed by a CDN packaging script, `test` runs vitest, and `llms` generates the file described above. The dev dependencies tell you the real story of how it is developed: Vue and `@vitejs/plugin-vue`, `pug` with a Vue language plugin, `postcss`, `cssnano`, `brotli-size` for the size badge, and TypeScript through `vite` and `vue-tsc`.

That last group is the interesting one. The primary language GitHub reports for the repository is Vue, yet the README insists the framework is ready to use with any JS framework. The resolution is that the documentation site and tooling are built in Vue, not that the library depends on Vue. Nothing in the published `files` list requires it at runtime.

## Where Beer CSS is the wrong tool

The first limitation is ecosystem size. A framework at 14.5 kB with one maintainer cannot offer the component coverage of a large library, and 31 open issues is not alarming on its own but there is no corporate team behind the queue. If your product needs a date picker, a data grid or a complex combobox that behaves correctly on keyboard and screen reader, you will either build it yourself or reach for another dependency, and at that point you have two styling systems to reconcile.

The second limitation is that the design system is not negotiable. Beer CSS targets Material Design 3, and the Expressive variant, which means the visual result is Google's design language rather than yours. That is the point for many projects and a problem for others. There is no theming system for reinterpreting the aesthetic the way there is with a token-driven library you can restyle, because Settings are a fixed vocabulary rather than an arbitrary palette.

The third is the coupling to a companion package. Dynamic colour is not built in; it comes from `material-dynamic-colors`, a separate package you must install and load separately, in every one of the four documented install variants. That is a small dependency by any measure, but it means the Material You behaviour people expect from a Material Design 3 framework is not in the box you installed.

A final practical note: this is a young project with a major version of 5 and a fast release cadence, so expect the kind of markup churn the v5.0.3 changelog documents. Pinning a version is not optional if you have production markup.

## How it compares to the alternatives

The comparison people actually search for is against Pico CSS, which appears alongside Beer CSS in search results, and against classless CSS frameworks generally. Pico CSS takes the opposite approach in the most direct sense: its classes are largely semantic element names, so markup reads as plain HTML and the framework provides almost no styling vocabulary. You get a good-looking page with almost no control. Beer CSS gives you three layers of explicit class names, which is more to learn and far more to work with.

Against a component framework such as Material Web or a Vue component library, the difference is where the components live. Those ship JavaScript, so you get behaviour, focus management and keyboard handling along with the styling, and you get it at the cost of a framework dependency and version coupling. Beer CSS is styles plus a small amount of module behaviour, and the README's claim of no build steps, configurations or dependencies is close to accurate for the default CDN route. What you are giving up is behaviour: a styled button is a button, not an accessible dialog or a combobox.

The genuinely interesting comparison is with generated Material themes, where a build step reads a design file and emits CSS. That approach can track Material Design updates automatically and gives you exact control over the token mapping, at the cost of a toolchain. Beer CSS hand-authors the translation to semantic HTML, which is why the CSS is small enough to read and why you can drop it into a static page with a link tag.

Pick Beer CSS when you want Material 3 quickly and lightly. Pick a component framework when you want accessible behaviour you do not have to write.

## Conclusion

Beer CSS is the right pick when you need a Material Design 3 look, you want to write semantic HTML rather than nest a component library, and you would rather not add a build step to a static site or a server-rendered page. The three-layer model is genuinely simple to hold in your head, and the default, scoped and custom-element distributions let you adopt it incrementally inside an existing codebase rather than all at once. The trade is that you are choosing a small, opinionated vocabulary over a large ecosystem: 31 open issues and a single major-version cadence mean less third-party component coverage than a framework with commercial backing. Read `docs/SETTINGS.md` first, since that layer is what you will edit most, and decide early whether you need the custom-element build, because the scoped and custom-element variants constrain which selectors you can reach.

## FAQ

### Does anyone still use CSS for interface work?

Yes, and Beer CSS is a case of it being used deliberately rather than as a leftover. The project implements Material Design 3 entirely in CSS over semantic HTML, with a stated payload of 14.5 kB brotli and no build step in the default installation. What it does not provide is JavaScript behaviour, so it complements component libraries rather than replacing them.

### What is CSS mainly used for?

CSS controls how a document looks and how elements are laid out, which today means colour, typography, spacing and responsive behaviour. In Beer CSS that work is organised into three layers: Settings, which affect the whole document, Elements, which are the components and tags, and Helpers, which make elements more scalable and customisable.

### What is the skill of CSS?

Knowing which properties solve a layout problem without fighting the cascade, and being able to build a consistent visual system from a limited vocabulary. Beer CSS is an exercise in exactly that skill, since it translates a design system into three layers of class conventions over semantic HTML and asks you to work inside that vocabulary rather than write arbitrary CSS.

## Sources

- [beercss/beercss on GitHub](https://github.com/beercss/beercss)
- [License: MIT](https://github.com/beercss/beercss/blob/main/LICENSE)
- [Project website](https://www.beercss.com)
- [README](https://github.com/beercss/beercss/blob/main/README.md)
- [Releases](https://github.com/beercss/beercss/releases)

---

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