# Foundation Yeti: a zero-build CSS framework with a machine-readable manifest

> Yeti is Foundation's successor to Foundation for Sites, shipped as one stylesheet that targets Baseline 2025 and describes itself to agents. The 7.0.0 line is still in beta, and the licence is not plain MIT.

**foundation/yeti** — A CSS-first, native, zero-build layout and styling framework for web designers.

- Repository: https://github.com/foundation/yeti
- Website: https://foundationcss.com
- Stars: 29,799 · Forks: 5,394
- Language: JavaScript
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/foundation-yeti

## The problem Yeti addresses: layout decisions buried in utility classes

Most CSS frameworks ask you to compose a page out of single-purpose classes. The result is markup that encodes spacing and width values rather than intent, and a designer who wants to change the rhythm of a whole site has to touch every template. Yeti takes the opposite position. The README calls its approach "named layouts, not utility soup": you pick an intent-based layout primitive or a composed recipe, configure it with a few data attributes, and the visual system follows. The audience is explicit. This is for web designers building a coherent site quickly, not for teams that want a component runtime or a build pipeline. The README also states what Yeti is not: not a web component library, not a utility framework, not a build-time system, no polyfills, and no full-featured slider in core. That list of refusals is the most useful part of the pitch, because it tells you which projects should look elsewhere immediately.

## One stylesheet, native CSS features, and a token scale that recomputes

The architecture is deliberately flat. A single stylesheet, linked as `/css/yeti.css`, carries the tokens, reset, base layer, seventeen layout primitives, three recipes, and twenty components. There is no Sass compilation step and no bundler requirement; the README says it composes into your build if you have one but never demands it. The mechanism doing the work is native CSS: container queries, cascade layers, native nesting, `light-dark()`, `dialog`, `popover`, and scroll-snap. These replace what used to need JavaScript or a preprocessor. The token system is the other half. Type and space derive from one base value and one ratio at runtime, so changing the ratio recomputes the whole scale rather than requiring a rebuild. On top of that sits a machine-readable manifest that describes every component, with the docs, type hints, and an MCP server generated from it. That is an unusual design choice: the manifest is the source of truth, and the human documentation is an output of it. If the manifest is wrong, the docs are wrong in the same way, which concentrates the risk in one file.

## Installing Yeti and building a first layout

The fastest path needs no install at all. The README's "Try it today" section says you can link the unbuilt source and write plain HTML, pointing at `src/yeti.css`. Note the filename difference: the published package exposes `dist/yeti.css` through its `style` field, while the repository source lives at `src/yeti.css`. For a packaged install, the README points to the installation guide at `docs/guides/install.md`, which also covers editor completion and the `llms.txt` files for assistants. The package is named `yeti-css` on npm, and its `exports` map exposes `./yeti.js`, `./themes/*`, `./manifest`, and `./tokens` alongside the CSS entry. The manifest and token JSON are the two machine-readable artifacts you can consume directly.

```bash
npm install yeti-css
```

If you would rather run the project's own fixtures than install the package, the README gives this sequence. It clones the repository, installs dependencies with `npm ci`, downloads the Playwright browsers, runs the test suite, and then serves the fixture pages on port 4173.

```bash
git clone https://github.com/foundation/yeti
cd yeti
npm ci
npx playwright install
npm test
npm run fixtures          # then open http://localhost:4173/ to browse every fixture
```

The `npm test` script is not a single command. In `package.json` it chains `validate`, `test:tools`, and `test:browser`, so a failure in the HTML validator or the tool tests stops the run before Playwright starts. The `fixtures` script runs `node test/browser/serve.js`. One constraint worth planning around: `package.json` sets `engines.node` to `>=24`, so the development side of this repository assumes a recent Node runtime even though using the stylesheet requires none.

## Baseline 2025 is a hard floor, not a suggestion

The browser support policy is the limitation that will decide adoption for most teams. Yeti targets Baseline 2025. Features that reached Baseline by the end of 2025 are used without guards; newer features sit behind `@supports` with a working fallback. The README is blunt about the consequence: if you need to support browsers older than that, Yeti is probably not your tool. There are no polyfills. This is not a gap that a plugin fills later, because the framework's value comes from the native features themselves. Container queries and cascade layers are not decoration here; they are the mechanism. A team with an enterprise support matrix that reaches back several years would spend more effort building fallbacks than the framework saves. The beta status compounds this. Yeti is at `7.0.0-beta`, and while the README says class names, attributes and values, markers, public token names and module names are frozen, it also points to `docs/guides/stability.md` for what may still move before `7.0.0`. Treat the frozen list as the contract and everything else as provisional.

## How Yeti differs from Bootstrap and Tailwind CSS

The comparison that matters is not feature count but where the styling decision lives. Bootstrap ships a component library with a grid and JavaScript plugins; you adopt its markup conventions and get interactive behaviour for free. Yeti ships no JavaScript framework and no full-featured slider in core, and it expects `dialog` and `popover` to do the work that Bootstrap's plugins do. Tailwind CSS takes the utility approach to its logical end: you compose classes in markup and generate only what you use. Yeti rejects that model outright, calling its own approach named layouts rather than utility soup, and it does not require a build step at all. So the split is roughly this: pick Bootstrap if you want batteries and can accept its class conventions, pick Tailwind if you want per-class control and already run a build, and pick Yeti if you want intent-level layout primitives, native CSS features, and no build tooling in the critical path. The trade-off is real in both directions. Yeti gives up the enormous ecosystem and third-party component market that Bootstrap and Tailwind have, and it gives up the per-utility escape hatch that makes Tailwind forgiving when a design goes off-script.

## Licence, maintenance and the cost of upgrading

Yeti is released under the Functional Source License 1.1, MIT future license, identified as `FSL-1.1-MIT` in both the README and `package.json`. The practical shape, as the README describes it: you can use, copy, modify, and redistribute it for any purpose except offering it as a competing product, and each release becomes plain MIT two years after it ships. That is a real constraint for anyone building a framework or a hosted site builder on top of it, and it is the kind of term that deserves a read of the LICENSE file rather than a summary. Foundation for Sites 6 remains MIT, so existing v6 users are not affected by the change. On maintenance, the repository is not archived and the last push was on 2026-09-18. The release history is thinner than that cadence suggests: v6.9.0 shipped on 2024-09-27, and v6.8.0 and v6.8.1 both on 2023-08-18. Those are 6.x releases, and the README explains why: version 6 continues on the `v6` branch with bug fixes, and `foundation-sites` on npm keeps publishing 6.x from it. The 7.0.0 line has not had a tagged release yet, and `package.json` still reports `7.0.0-alpha.0` while the README describes the project as `7.0.0-beta`. Upgrade cost therefore depends on which line you are on. A 6.x user moving to 7 is changing class names, attributes, token names and module names at once, which is why the frozen list in `docs/guides/stability.md` is the first document to read.

## Conclusion

Adopt Yeti if your users are on Baseline 2025 browsers, you want layout from data attributes rather than utility classes, and you accept a beta API surface plus a licence that only becomes MIT two years after each release. Do not adopt it if you must support older browsers, need a full slider in core, or want to resell a competing framework. Before writing production markup, read docs/guides/stability.md to see which names are frozen and which can still move before 7.0.0.

## FAQ

### Does Foundation Yeti require a build step or Node?

No. The README describes it as zero-build and says no Sass, Node, or bundler is required to use it. You can link the unbuilt source at `src/yeti.css` and write plain HTML, though developing the repository itself requires Node 24 or newer.

### What browsers does Foundation Yeti support?

It targets Baseline 2025, using anything that reached Baseline by the end of 2025 without guards and putting newer features behind `@supports` with a fallback. The README states there are no polyfills and that if you need older browsers, Yeti is probably not your tool.

### Is Foundation Yeti the same as Foundation for Sites 6?

It is the successor. The README says version 6 continues on the `v6` branch with bug fixes, and `foundation-sites` on npm keeps publishing 6.x from it, while Foundation for Sites 6 remains MIT licensed.

### What licence does Foundation Yeti use?

It uses the Functional Source License 1.1, MIT future license, listed as `FSL-1.1-MIT`. The README says you may use, copy, modify, and redistribute it for any purpose except offering it as a competing product, and each release becomes plain MIT two years after it ships.

## Sources

- [foundation/yeti on GitHub](https://github.com/foundation/yeti)
- [Issues](https://github.com/foundation/yeti/issues)
- [Project website](https://foundationcss.com)
- [README](https://github.com/foundation/yeti/blob/develop/README.md)
- [Releases](https://github.com/foundation/yeti/releases)

---

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