Learn the Master CSS mental model, class syntax, rendering modes, and design-system workflow.

What is Master CSS?

The CSS language

Master CSS is a markup-driven CSS language and framework. It lets you write CSS decisions directly in HTML, JSX, Vue, Svelte, and other template markup using compact class syntax.

Think of each class as a small CSS statement:

• Start with the declaration you want, such as fg:blue-60, font:3xl, or text-center.
• Add a selector state when the style should react, such as :hover.
• Add a conditional query when the style should be scoped, such as @sm or @dark.

<h1 class="fg:blue-60 fg:red-60:hover font:3xl font:5xl@sm font:heavy m:2xl text-center">    Hello World</h1>

@layer theme {    :root {        --color-blue-60: oklch(51.83% .2687 266.1);        --color-red-60: oklch(60.94% .2501 29.23);        --font-size-3xl: 2rem;        --font-size-5xl: 2.5rem;        --font-weight-heavy: 900;        --spacing-2xl: 3rem    }}@layer utilities {    .text-center {        text-align: center    }    .m\:2xl {        margin: var(--spacing-2xl)    }    .fg\:blue-60 {        color: var(--color-blue-60)    }    .font\:3xl {        font-size: var(--font-size-3xl)    }    .font\:heavy {        font-weight: var(--font-weight-heavy)    }    .fg\:red-60\:hover:hover {        color: var(--color-red-60)    }    @media (width>=52.125rem) {        .font\:5xl\@sm {            font-size: var(--font-size-5xl)        }    }}

Under the hood, Master CSS generates real CSS rules, adds vendor prefixes, places rules in predictable cascade layers, and orders CSS rules for you. You keep the styling decision close to the element, while the engine handles the CSS output.

For one-off interface work, you can stay in markup. When a value, selector, condition, primitive, native rule, or repeated pattern becomes part of your product vocabulary, move it into the project CSS entry as a token, selector token, at token, utility, native composed rule, or component class.

Readable structured syntax

Master CSS is not trying to put a second style="" attribute inside class="". The syntax is CSS-like, but it is designed to be shorter, composable, and easier for tools to understand.

It can begin with native CSS wording, then become shorter as the meaning becomes clear:

<!-- Same as native CSS --><div class="text-align:center"><!-- Context-aware shorthand --><div class="text-center"><!-- Abbreviation --><div class="text-center">

It can express common CSS values without ceremony:

<!-- Set the background to blue-60 with 50% opacity --><div class="bg:blue-60/.5"><!-- Scale the element to 1.5x --><div class="transform:scale(1.5)"><!-- Transition transform for .3s with ease timing --><div class="transition:transform|.3s|ease"><!-- Use a static utility that emits display: block --><div class="block">

It can attach state selectors and selector variants to the same declaration:

<!-- Set a pink background on hover --><div class="bg:blue-70:hover"><!-- Set a pink background for all subsequent siblings --><div class="bg:blue-60~*"><!-- Set a pink background for all subsequent div siblings --><div class="bg:blue-60+div"><!-- Set a pink background for descendant p elements --><div class="bg:blue-60_:where(p)"><!-- Use :first instead of :nth-child(...) --><div class="bg:blue-60:first">

It can also attach responsive and conditional rules:

<!-- Set width to 800px when viewport width is at least 1024px --><div class="width:800px@>=1024"><!-- Use a breakpoint theme token --><div class="width:800px@sm"><!-- Position at 1px when viewport width is >= xs and < lg --><div class="top:1px@xs&<lg"><!-- Set background to gray-20 in dark mode --><div class="bg:gray-20@dark"><!-- Hide the element for print --><div class="hidden@print"><!-- Fade only when reduced motion is not requested --><div class="animation:fade|.2s@motion">

You do not need to memorize everything before starting. Begin with explicit CSS-like classes, then adopt shorthands, abbreviations, tokens, and functions when they make the markup easier to read.

Tooling built for class syntax

Class-heavy markup can become hard to scan when every class is plain text. The Master CSS Language Service gives class names semantic highlighting, autocompletion, generated CSS previews, and syntax-aware feedback inside editors.

Utility classes are hard to read when the editor cannot identify the property, value, selector, and query.

Master CSS highlights the declaration, value, selector state, and conditional query.

Without syntax-aware tooling, long class strings read like one flat sequence.

mt-9 rounded-lg flex text-slate-700 hover:bg-slate-200 sm:bg-slate-300mt-9 rounded-lg flex text-slate-700 hover:bg-slate-200 sm:bg-slate-300mt-9 rounded-lg flex text-slate-700 hover:bg-slate-200 sm:bg-slate-300

With Master CSS highlighting, each class keeps its CSS shape.

mt:9x r:lg flex fg:slate-70 bg:slate-20:hover bg:slate-30@smmt:9x r:lg flex fg:slate-70 bg:slate-20:hover bg:slate-30@smmt:9x r:lg flex fg:slate-70 bg:slate-20:hover bg:slate-30@sm

Predictable authoring

Master CSS also gives teams guardrails for class syntax. Code linting can catch invalid classes, enforce consistent class order, reject unknown classes, detect collisions, and validate classes inside JavaScript utilities such as clsx().

Invalid value for font property.

<div class="font:">…</div>

This matters because markup-driven CSS should still be refactorable, reviewable, and safe in large codebases. You get the speed of authoring in markup without giving up validation.

The CSS framework

Master CSS is also a standalone CSS framework. It includes the core rule engine, browser runtime rendering, server rendering, static rendering, framework integrations, code linting, language service, and a CSS-first theme.

CSS-first manifest authoring

The project CSS entry is the primary manifest source. Theme tokens live in @theme, reusable selector and conditional variants use @custom-variant, low-level custom utilities live in @utilities, semantic component classes live in @components, and native CSS rules can use @compose when they should lower to ordinary stylesheet output.

@theme {    --color-primary: #4f46e5;    --breakpoint-md: 48rem;}@custom-variant @motion-safe { @media (prefers-reduced-motion: no-preference) { @slot; } }@custom-variant :interactive { &:is(:hover, :focus-visible) { @slot; } }@components {    btn {        @compose inline-flex align-items:center justify-content:center px:md py:xs r:lg;        background: var(--color-primary);        @variant :interactive {            @compose outline:2px|solid|blue-60 outline-offset:0.125rem;        }    }}.notice {    @compose p:md r:lg;    @variant @motion-safe {        @compose transition:opacity|fast|smooth;    }}

The @theme, @settings, top-level custom directives, and managed definition directives are manifest inputs, not regular stylesheet output. Master CSS compiles them into a MasterCSSManifest, then generates only the classes used in markup, discovered by source scanners, or composed by another CSS-defined style. Native rules such as .notice lower to CSS for the stylesheet that contains them.

Rendering for different delivery models

Master CSS provides three main rendering modes:

• Runtime rendering watches class names in the browser and generates rules as elements appear or change.
• Static rendering scans source files during builds and emits CSS before deployment.
• Progressive rendering pre-renders first-page CSS, then hydrates the runtime for dynamic classes.

Choose the mode that fits your framework and deployment model. A static marketing page, an SSR application, and a highly dynamic dashboard can all use the same class syntax while delivering CSS differently.

This benchmark compares the CSS transferred by several official documentation sites. It is a useful reference for page-level CSS weight, not a universal guarantee for every application.

According to HTTP Archive CSS Bytes, the sum of transfer size kilobytes of all external stylesheets requested by a page is ~82 kB, excluding internal and inline styles. On this documentation site, Master CSS keeps page CSS around ~6 kB per page with brotli compression because it emits only the rules required by that page.

Progressive rendering works by pre-rendering critical CSS from rendered class names, then deferring the runtime engine for future dynamic classes. The Next.js guide uses this model through the React runtime provider and the Next.js adapter.

<!DOCTYPE html><html lang="en"><head>    …    <!-- Generate only the critical CSS required for the page. -->    <style id="master-css">        .block {             display: block         }     </style></head><body>    <h1 class="block">Hello World</h1></body></html>

Master CSS generates optimized CSS directly. Integrations can pre-render, statically render, or hydrate CSS without depending on a PostCSS, Autoprefixer, or CSS minifier pipeline.

The foundation for design systems

Master CSS provides a rich theme layer for scalable design systems. Use theme tokens for color, spacing, typography, radius, elevation, and motion; use breakpoints, containers, sizing, and the layout system to keep page structure aligned with those foundations.

The important habit is to abstract only when the abstraction carries product meaning. A primary color, a breakpoint-md breakpoint, or a btn component can communicate a shared design decision. A one-off homepage flourish usually belongs directly in markup until the pattern proves itself.

Predictable cascade layers

The default @master/css/base.css stylesheet declares the cascade layer order once:

@layer theme, base, defaults, components, utilities;

Generated CSS emits rules into theme, base, defaults, components, and utilities blocks. theme emits variables, base normalizes the platform, defaults holds broad defaults, components holds product vocabulary from CSS-defined component classes, and utilities holds utility classes. Because utilities comes last, local utility decisions can override reusable project styles without reaching for !important.

Why author styles in markup?

Traditional CSS often asks you to name an abstraction before you know whether the style deserves one. That can be expensive during product work, where layouts, content, and interaction details change quickly.

Premature abstraction

A traditional CSS workflow often starts by turning a visual decision into a named class, even before the team knows whether that decision is reusable.

Mountain

A mountain is an elevated portion of the Earth's crust, generally with steep sides that show significant exposed bedrock.

<div class="card">    <img class="card-image" … />    <div class="card-content">        <div class="card-title">Mountain</div>        <div class="card-text">A mountain is an elevated portion of the Earth's crust, generally with steep sides that show significant exposed bedrock.</div>    </div></div>

.card {    display: flex;    background-color: rgba(255, 255, 255);    transition: transform 0.2s ease 0s;    overflow: hidden;    border-radius: 0.625rem;}.card:hover {    transform: translateY(-0.3125rem);}.card-image {    object-fit: cover;    width: 8.75rem;    aspect-ratio: 16 / 9;}.card-content {    padding: 1.5625rem;}.card-title {    font-weight: 600;    font-size: 1.125rem;    line-height: calc(1.125rem + 0.875em);}.card-text {    font-size: 0.875rem;    line-height: calc(0.875rem + 0.875em);    overflow: hidden;    display: -webkit-box;    overflow-wrap: break-word;    text-overflow: ellipsis;    -webkit-box-orient: vertical;    -webkit-line-clamp: 2;}

Keep the first version explicit in markup, then promote it later if the pattern becomes real. ↓ 75% code

<div class="flex transform:translateY(-5px):hover transition:transform|fast|smooth overflow:hidden surface:base b:1px|solid|base r:xl">    <img class="object-cover w:35x aspect-ratio:16/9" … />    <div class="p:lg">        <div class="font:lg font:medium">Mountain</div>        <div class="font:sm line-clamp:2">A mountain is an elevated portion of the Earth's crust, generally with steep sides that show significant exposed bedrock.</div>    </div></div>

Abstract classes are valuable when they carry stable meaning. They become expensive when they are created before that meaning exists.

When a team starts by naming every visual detail, each small change can trigger design questions that are not really about design:

• What should this class be called?
• Is .card already used somewhere else?
• Is .card-title part of a naming convention everyone follows?
• Does this style belong to all cards, this page only, or this one element?
• Will a small variation require another class name?
• Which stylesheet owns this rule?
• Which selector or media query might override it?
• Is !important needed because of specificity?
• If the rule changes, where else will it leak?

These questions are sometimes necessary, but they should appear when abstraction is justified, not before the first interface exists.

Syntax first, semantic second

Master CSS encourages a mixed strategy: syntax first, semantic second.

Use syntax classes when:

• The style is local to one element or one section.
• The design is still being explored.
• The class list communicates the decision more clearly than a new name.
• There is no stable reuse pattern yet.

Use semantic tokens and components when:

• A value must stay consistent across the product.
• A repeated pattern has a clear role, such as btn, field, card, or navbar.
• The team has a design-system decision worth naming.
• Consumers should use the concept without knowing every underlying utility.

Assuming the card has become reusable, define it as a component class in the project CSS entry:

@components {    card {        @compose flex transition:transform|fast|smooth overflow:hidden surface:base b:1px|solid|base r:xl;        &:hover {            @compose transform:translateY(-5px);        }    }    card-image {        @compose object-cover w:35x aspect-ratio:16/9;    }    .card-content {        @compose p:lg;    }    .card-title {        @compose font:lg font:medium;    }    .card-text {        @compose font:sm line-clamp:2;    }}

Then use the semantic classes in markup:

<div class="card">    <img class="card-image" … />    <div class="card-content">        <div class="card-title">Mountain</div>        <div class="card-text">A mountain is an elevated portion of the Earth's crust, generally with steep sides that show significant exposed bedrock.</div>    </div></div>

The component definitions stay on-demand. They are emitted in the components layer only when card, card-image, and the other component classes appear in markup, are discovered by source scanning, or are composed by another CSS-defined style.

Generate CSS based on markup

Consider a common styling task:

"Create a section with a blue background, a red hover state, centered text, and larger padding when the viewport is at least 1024px."

In a traditional CSS workflow, the first step is often naming the thing before the style has proved reusable.

<section class="home-section">…</section>

Then you create a stylesheet rule, selector state, and media query for that name.

.home-section {    background-color: blue;    padding: 2rem;    text-align: center;}.home-section:hover {    background-color: red;}@media (min-width: 1024px) {    .home-section {        padding: 3rem;    }}

This works, but it creates an abstraction before the design decision has earned one.

With Master CSS, the local decision can stay in markup until it becomes shared vocabulary. ↓ 82% code

<section class="bg:blue-60 bg:red-60:hover p:xl p:2xl@md text-center">…</section>

@layer theme {    :root {        --color-blue-60: oklch(51.83% .2687 266.1);        --color-red-60: oklch(60.94% .2501 29.23);        --spacing-xl: 2rem;        --spacing-2xl: 3rem    }}@layer utilities {    .text-center {        text-align: center    }    .p\:xl {        padding: var(--spacing-xl)    }    .bg\:blue-60 {        background-color: var(--color-blue-60)    }    .bg\:red-60\:hover:hover {        background-color: var(--color-red-60)    }    @media (width>=64rem) {        .p\:2xl\@md {            padding: var(--spacing-2xl)        }    }}

Smart rule ordering

CSS rule order decides which matching rule wins. Responsive styles are a common place to make mistakes.

"Center-align the homepage headline when the viewport width is >=1280px, and align right when it is >=1024px."

Incorrect responsive media rule order.

@media (width>=80rem) {    h1 {        text-align: center;    }}@media (width>=64rem) {    h1 {        text-align: right;    }}

When the viewport is at least 80rem, both media queries match. Because the 64rem rule appears later, it wins, so the headline stays right-aligned instead of centered.

Let Master CSS generate the correct priority order.

<h1 class="text-right@md text-center@lg">

No matter how you order the classes in markup, Master CSS emits the media rules in the order that matches the intended cascade:

@media (width>=64rem) {    .text\:right\@md {        text-align: right    }}@media (width>=80rem) {    .text\:center\@lg {        text-align: center    }}

The same priority model covers selector states such as :disabled, :active, :focus, :hover, selector expressions such as :where(), and breakpoint combinations such as @lg or @sm&<lg.

Unit-sensed conversions

Design specs often use pixels, while browser-friendly typography and spacing often need relative units. Master CSS can infer common units and convert them for you.

Without conversion, you need to remember that 24px equals 1.5rem.

<h1 class="font:1.5rem">

Omit the unit when the property can infer it clearly.

<h1 class="font:24px">

@layer utilities {    .font\:24px {        font-size: 24px    }}

This keeps markup close to design measurements while still producing practical CSS output.

Separation of concerns

Master CSS does not treat "HTML in one file, CSS in another file" as the only way to separate concerns. For UI work, structure and style often describe the same component responsibility.

The concern to separate is usually business responsibility: page layout, product component, reusable primitive, form control, data display, theme token, and so on. A class such as text:primary:hover@sm is not business logic; it is the styling decision for an element in a particular UI state.

Separate responsibilities, not files by default.

When the styling decision is local, markup is the clearest place for it. When the decision becomes shared vocabulary, promote it into tokens, utilities, native composed CSS, or components.

Why not just inline styles?

Inline styles look similar at first, but they cannot express the CSS features most interfaces need.

Inline styles cannot apply selectors, media queries, pseudo-classes, cascade layers, or reusable design tokens.

<button style="font-size: 0.875rem" disabled>Oops!</button>

Master CSS keeps those CSS capabilities available in markup.

<button class="font:sm font:xl@md opacity:.5[disabled]" disabled>Bravo!</button>

It also keeps the interface aligned with design tokens.

<h1 class="font:lg fg:blue-60">Hello World</h1>

What to read next

If you are new to Master CSS, continue in this order:

1. Installation to set up the package for your framework.
2. Style declarations to learn the class syntax in detail.
3. State selectors, responsive design, and conditional queries to control when styles apply.
4. Rendering modes to choose runtime rendering, static rendering, or progressive rendering.
5. Theme and component classes when your project needs shared vocabulary.

Comprehensive comparisons

For a broader positioning snapshot, here is a comparison of Master CSS, Tailwind CSS, and Bootstrap: