Development output
Full CSS
~4 MB
emily.css
Includes all generated utilities, responsive variants, and state variants so teams can move quickly while building.
A single source of truth for consistent, accessible, branded interfaces.
EmilyUI turns your design tokens into portable CSS, lightweight HTML behavior, editor guidance, migration tools, and quality checks, so every project stays aligned with your brand.
CSStoken-generated stylesheet
JSoptional HTML behavior layer
MITopen ecosystem licence
Works with
HTML
Drupal
WordPress
PHP / Twig
Astro
Vue / Nuxt
React
Next.js
Svelte
AngularThe problem
Brand systems drift when every project solves UI again.
Colours, spacing, components, accessibility patterns, and tiny behavior rules get copied between projects until no one knows which version is correct. The issue is not only CSS. It is keeping the whole interface system consistent.
EmilyUI gives teams one source of truth for branded UI, then generates the CSS, metadata, checks, and optional HTML behavior each project needs.
01
You are inside a CMS or portal
Drupal, WordPress, Power Pages, or any system where runtime choices are constrained. Generate CSS ahead of time and link it.
02
One brand, many projects
Keep design values in one config and generate the classes every project needs. No duplicated token files, no slow drift.
03
You need behavior, not an app rewrite
Use EmilyJS for toggles, forms, visibility, class binding, focus trapping, and announcements without adopting a framework for every page.
How it works
Tokens in. CSS out. Behavior when needed.
1
Define the brand system
Put colours, fonts, spacing, breakpoints, output paths, and tooling options in emily.config.json.
Terminal
npx emily-css init
2
Generate the shared UI layer
Build the stylesheet, manifest, and editor metadata each project can use to stay aligned with the same brand system.
Terminal
npx emily-css build
3
Add behavior only where needed
Use EmilyJS attributes for small interactions without turning every page into a full frontend app.
One config file
Define the UI system once.
Use it everywhere.
Set your colours, typography, spacing, and breakpoints in emily.config.json. EmilyCSS turns that into CSS variables, utility classes, responsive variants, layout patterns, and tooling metadata.
Change one token, rebuild, and the generated classes, manifest, IntelliSense data, and checks stay aligned.
emily.config.json
{
"name": "My Brand",
"colours": {
"brand": "#DB2777",
"accent": "#D4AF37",
"success": "#017F65"
},
"fontFamily": {
"heading": "inter",
"body": "inter"
},
"output": {
"css": "public/emily.min.css"
}
}Why teams choose it
Built for real delivery constraints.
Brand-owned tokens
Utilities are generated from your colours, spacing, type, radius, motion, and breakpoint settings.
Portable output
The browser receives plain CSS that works wherever the project can load a stylesheet.
Quality checks
Doctor flags unknown classes, focus removal, likely invisible text, and low-contrast token pairs.
Migration tooling
A report-only migrate command helps teams understand Tailwind usage before changing source files.
The ecosystem
One system, four layers.
emily-css generates the tokens and utilities. emily-components turns those into documented, manifest-tracked UI patterns. emily-starters assembles them into ready starting points. emily-js adds the small behaviours that need it. Each layer is usable on its own, and each is honestly tracked — built, in progress, or planned.
emily-css
Tokens & utilities
Generates CSS variables, utility classes, variants, and tooling metadata from one config file.
emily-components
Documented patterns
A 303-entry component manifest of atoms, molecules, organisms, and templates — 259 built today, the rest tracked openly.
emily-starters
Ready starting points
Six built starter sites, each with its own emily.config.json. Re-brand with a config edit and rebuild.
emily-js
Optional behaviour
Small HTML-attribute behaviours for where static HTML is not enough — no framework adoption required.
Manifest-powered
A design system your tooling can read.
Every utility and every component pattern is described in a manifest — class, category, tokens, variants, dependencies, and build status. That is what powers documentation, audits, and integration work without guesswork.
Utility manifest
Generated on every build by emily-css. It drives the searchable utilities reference, IntelliSense data, and doctor checks — so docs can never silently drift from the generated CSS.
Component manifest
303 entries across tokens, atoms, molecules, organisms, templates, and pages. Each entry carries an honest status — built, needs-css, needs-js, needs-a11y-review, planned, or deferred. See the current build status.
Starters
Six starters, built and ready to re-brand.
Token-driven starting points, not finished sites: swap the config, rebuild, then replace the placeholder copy and images with your own. Six of fourteen starter entries are built today — the rest are planned, not shipped.
local-service-business
Trade or service business serving an area — hero, trust strip, services grid, quote form.
one-page-business
Everything on one scrolling page: services, about, testimonials, FAQ, contact. Fastest to launch.
professional-services
Firms selling expertise — credentials strip, process steps, team, consultation form.
charity-community
Mission hero, impact stats, programmes, donate CTA, volunteer form.
portfolio-case-study
Work-led businesses — portfolio grid, featured case study, contact band.
campaign-landing
One campaign, one conversion goal. Minimal chrome, single short form, noindex.
Accessibility-native, not audited-in
Built examples use semantic HTML, token-driven focus styles, and honest status tracking. We do not claim WCAG compliance — we tell you what has been checked and what still needs manual testing. A manual assistive-technology checklist exists for the FAQ accordion, some patterns remain marked needs-a11y-review, and interactive widgets wait for emily-js behaviours. See accessibility status.
Placeholder images, no external hosts
Starter and component examples use local placeholder paths — no live third-party image hosts and no source.unsplash.com dependency. For prototyping you can download and license images (for example from Unsplash) into the local placeholder folder; production projects should use approved, licensed images or a proper image pipeline.
Patterns
Accessible HTML, ready to paste.
Copy the HTML, keep the semantics, then adjust the generated classes to match your config.
Action row
actions.html
<div class="flex gap-3"> <button class="btn btn-primary">Save settings</button> <button class="btn btn-secondary">Preview</button> <button class="btn btn-secondary" disabled>Disabled</button> </div>
Accessible form field
Used for build notifications only.
field.html
<label for="email" class="text-sm font-medium">Email address</label> <input id="email" type="email" aria-describedby="email-hint" class="mt-2 w-full rounded border border-neutral-30 px-4 py-2.5 text-sm" > <p id="email-hint" class="mt-2 text-xs text-neutral-60"> Used for build notifications only. </p>
Production output
Full utility set in development. Purged output in production.
Build generates the full utility catalogue for speed while designing. Purge removes unused classes for production so users download far less CSS.
Production output
Purged CSS
much smaller
emily.purged.css
Keeps only the classes your templates use. Run emily-css purge to see the exact output size for your project.
Visual size comparison
Before
~4 MB
After
after purge
Build
npx emily-css build
Purge
npx emily-css purge
EmilyUI ecosystem
Add interactivity without a framework.
EmilyCSS handles the branded stylesheet. EmilyJS handles small pieces of interactive behavior: toggles, tabs, forms, visibility, class binding, focus trapping, and live announcements using plain HTML attributes.
- Toggle visibility, classes, and text with emily-show, emily-text, and emily-class
- ARIA attributes (aria-expanded, aria-controls, aria-live) managed automatically
- Focus trapping for modals and dialogs with emily-trap
- Works in Drupal, WordPress, Power Pages, static HTML, and server-rendered templates
- CSP-safe: no eval, no new Function, no inline script generation
toggle.html
<!-- No build step. Drop in a script tag. -->
<script src="/emily.js"></script>
<!-- Toggle a menu open and closed -->
<div emily-state="{ open: false }">
<button emily-click="open = !open"
class="btn btn-secondary">
Toggle menu
</button>
<nav emily-show="open"
class="mt-4 flex flex-col gap-2">
<a href="/docs">Docs</a>
<a href="/components">Components</a>
<a href="/pricing">Pricing</a>
</nav>
</div>
<!-- aria-expanded is set automatically --> One practical UI system.
Any project that can load CSS.
Start with token-generated CSS, add lightweight HTML behavior when needed, and use the tooling to keep classes, contrast, and migrations under control.