Five files, one required. Start with installation, then read the module you're actually using.
Start here
Depending on whether you want to ship something today, understand the architecture, or look up a class.
Copy the files, link what your page contains, write ordinary HTML. The module picker assembles your link block for you.
Installation · 5 minutes
Two layers of tokens, eleven roles, and why a theme is a stylesheet rather than a fork. Change the type scale live while you read.
Tokens, theming, modules
All 1,445 classes, grouped by module and family, with the properties each one sets. Generated from the CSS on every build.
Class reference
Quick start
Core defines the tokens every other file reads, so it always loads first. Utilities loads last so its helpers win a specificity tie.
pf- and collide with nothing<link rel="stylesheet" href="/PolyFishCSS-Core.css?v=c0428852">
<link rel="stylesheet" href="/PolyFishCSS-Headers.css?v=c6809083">
<link rel="stylesheet" href="/PolyFishCSS-Content.css?v=6048cac5">
<section class="pf-section">
<div class="pf-container">…</div>
</section>Download or self-host, load order, fonts, folder layout, and a production server config.
What lives in each of the five files, what depends on what, and which to skip.
Every custom property: colour roles, type scale, spacing, radii, motion and layout.
Retheme from eleven properties, flip to a light palette locally, and turn the facet corner off.
A live device previewer at real viewport widths, every breakpoint, and the two guards that prevent most phone bugs.
What is handled for you, measured contrast in both themes, and the three limits of the CSS-only components.
Measured sizes, what to load for four page types, the font budget and layout-shift handling.
Every one of the 1,440 public classes, grouped by module and family, with the properties each sets. Generated from the CSS on every build.
Swap the header, hero, body and footer of a live page and change the tokens underneath. No script involved.
One optional 7.9 KB file. What it adds, what works without it, and the contract it is written against.
Every component rendered live, grouped by the file it lives in.
Every release and what changed, including the bugs that were caught before they shipped.
Complete pages — landing, docs, article, dashboard, sign-in — each with a different file load.
Load order matters
Core, then Headers, Content and Footers in any order, then Utilities. Loading Utilities early is the single most common mistake — its helpers stop overriding component rules.
Interactive
Eleven panels across the documentation, all of them radio inputs,
checkboxes and :has(). No script runs any of it.
Swap the header, hero, body and footer of a live page, then retint it.
Theme, accent, facet depth, radius and density on one stage.
Scale, measure and leading against a real specimen.
Tick files and watch which components are available.
A real page in an iframe at 320, 390, 768 and 1024.
Measured file sizes and gzipped totals per scenario.
44px targets, high contrast and reduced motion, switchable.
Default, focus, disabled, busy and invalid on real markup.
Tick enhancements, get the markup you need.
Tick what your page has; the head assembles itself.
How the pieces fit
Core is the only required file. Everything else maps to a part of a page, so the answer is usually visible from the design.
| Page you are building | Files to link | Minified | Why |
|---|---|---|---|
| Sign-in or error screen | Core, Content | 29 KB | One panel, no navigation, no footer |
| Marketing or landing page | Core, Headers, Content, Footers | 40 KB | Hero, sections, column footer |
| Documentation page | Core, Headers, Content, Footers, Space | 60 KB | Adds sidebar navigation and spacing helpers |
| Application screen | Core, Headers, Content, Forms, Components | 61 KB | Tables, tabs, menus, validation states |
| Anything using most of it | The bundle | 108 KB | Fewer requests and smaller gzipped past eight modules |
A palette names colours. Roles name jobs — background, surface, text, accent, border. Components only ever read roles, so a theme is eleven redeclared properties rather than a fork of the framework.
That indirection is why light mode is a palette swap with no component rule touched, and why the playground can retint a live page from radio inputs.
No carousel, no toast queue, no combobox, no scroll-animation library. Anything that only works when a script runs would break the rule the optional layer is built on: every component functions without it.
A horizontally snapping .pf-scroller replaces the carousel. It has no autoplay and no hidden slides, and every card is reachable by scroll, keyboard and screen reader.
Baseline
| Feature | Used for | From | Without it |
|---|---|---|---|
| Custom properties | Every token | 2016 | Nothing works — this is the floor |
| Grid and gap | All layout primitives | 2017 | Nothing works |
clamp() | Fluid type and rhythm | Chrome 79 | Type stops scaling; layout holds |
:has() | Option cards, playground | Chrome 105, Safari 15.4 | Selected-state styling is skipped |
@container | Container-query helpers | Chrome 105, Safari 16 | Components keep their stacked layout |
animation-timeline | Scroll reveal | Chrome 115 | Content is simply visible |
color-mix() | Frosted panels, brand tints | Chrome 111, Safari 16.2 | Falls back to a solid colour |
Roughly Chrome 105, Safari 15.4 and Firefox 103. Every feature past that floor is behind @supports or has a declared fallback, so an older engine does less rather than breaking.