Recommended tooling

Recommended tools

• PostCSS
• Lightning CSS
• Stylelint
• Browserslist
• Prettier
• Astro, Eleventy, or another static-first build system

Choose a baseline first

• Minimum baseline: native CSS layers, Stylelint, and consistent formatting.
• Expanded baseline: add PostCSS or Lightning CSS when you need transforms or broader compatibility.
• Team baseline: keep one shared pipeline across projects to avoid divergent CSS behavior.

Custom media queries

Named breakpoints make media queries easier to read and easier to change. Breakpoints should describe layout needs, not specific devices. Component CSS should say what breakpoint it targets, not ask every developer to remember what a number means.

@custom-media --mobile (width < 768px);
@custom-media --from-tablet (width >= 768px);
@custom-media --tablet (768px <= width < 1280px);
@custom-media --until-desktop (width < 1280px);
@custom-media --desktop (width >= 1280px);
@custom-media --large-desktop (width >= 1680px);
@custom-media --reduced-motion (prefers-reduced-motion: reduce);

Directional helpers such as --from-tablet and --until-desktop are often more useful than rigid device labels. Accessibility queries such as --reduced-motion should be treated as first-class breakpoints too.

This pattern needs a build step such as PostCSS or similar tooling, unless your browser support target already handles the feature you are using directly.

Compatibility caveat: avoid writing custom media rules if your runtime path skips the build step that expands them.

.product-card {
    /* Shared styles */

    @media (--desktop) {
        /* Desktop-only changes */
    }

    @media (--reduced-motion) {
        transition: none;
    }
}

Avoid scattering raw breakpoint numbers through component files.

.product-card {
    @media (min-width: 1024px) {
        /* What does 1024px mean here? */
    }
}

Browserslist and feature support

Tooling should follow a written browser support strategy. Use browserslist where your tools support it, and prefer feature-based support decisions over guessing browser versions by habit.

Browser support choices should be documented, reviewed, and based on the project. They should not live as unwritten assumptions in old build config.

Compatibility caveat: if one package or app in a monorepo has a different browserslist target, verify that shared CSS outputs stay aligned across those builds.

Linting and formatting

Stylelint and formatting tools should support the methodology. They should catch avoidable mistakes, not force a naming system the project does not use.

• Disallow styling with IDs.
• Discourage unnecessary !important.
• Flag unknown custom properties where possible.
• Keep formatting consistent across partials.
• Allow the project’s chosen naming style.

Layer support

The build should preserve cascade layers and process imports in a way that keeps layer order predictable.

@layer legacy, settings, base, utilities,
layout, components, theme, hacks;

Read the media query organisation guidance alongside this page. Tooling only helps when the CSS rules are clear first.

Compatibility caveat: imported CSS from third-party libraries may not declare layers. Wrap or isolate that CSS so it does not bypass your intended layer order.