Architecture field guide · Research refresh July 2026

Modern CSS is a portfolio of boundaries.

The relevant decision is no longer “BEM or not BEM.” Modern architecture assigns separate mechanisms to cascade order, selector reach, component identity, layout composition, design tokens, runtime state, and build-time enforcement.

Recommended default: native cascade layers + semantic tokens + composition primitives + BEM-light ownership + semantic state + container queries. Add @scope when the browser policy supports Baseline 2025. Keep custom functions and if() progressive only. [S03] [S24] [S28] [S29]

First principle

Separate the decisions before choosing a tool.

Several approaches called “CSS alternatives” solve different layers of the problem. CUBE and ITCSS organize CSS. CSS Modules and Shadow DOM scope it. Tailwind and atomic compilers change the authoring and output model.

Order

Who wins when multiple rules target the same element?

Scope

How far can a selector reach, and what can override it?

Authorship

Do styles live in CSS, markup, JavaScript, or a typed compiler API?

System

How are tokens, variants, layouts, and component contracts governed?

Research refresh · July 2026

Treat feature maturity as an architecture input.

Browser-native CSS has absorbed more responsibilities that once required naming discipline, preprocessors, or JavaScript. The architecture should adopt those capabilities at different confidence levels rather than treating “modern CSS” as one compatibility tier.

Core defaultEvidence A

Widely available platform

Cascade layers, native nesting, relational selectors, custom properties, size container queries, color-scheme support, and forced-colors handling can form the normal architecture baseline.

S03 S23 S27 S36

Current-browser policyEvidence A

New native boundaries

@scope became Baseline Newly available in December 2025. anchor-scope and contrast-color() became Baseline 2026. They are viable when the support policy permits current browser generations.

S24 S32 S35

Progressive onlyEvidence A

Emerging declarative logic

CSS custom functions and if() are powerful but remain limited availability. Advanced style, scroll-state, and anchored container-query subfeatures also require compatibility checks and explicit fallbacks.

S28 S29 S30 S31

Decision navigator

Start from the delivery environment.

Choose the boundary that must be enforced. Distribution, host ownership, build tooling, type safety, and compatibility matter more than methodology preference.

Choose a context

Recommended system

Native layered CSS

cascade layers semantic tokens CUBE compositions BEM-light container queries

It preserves transparent HTML and CSS, needs no compiler, survives copy-and-share workflows, and still provides explicit cascade control and responsive component behavior.

Pattern landscape

Compare what each approach actually solves.

Ratings are architectural judgments, not performance benchmarks. Use the filters to narrow the landscape by responsibility.

17 patterns shown

Uses browser-native layers, custom properties, nesting, selectors, queries, and policy-gated scoping as the architecture substrate.

Baseline coreNo buildProgressive extension

Build: None
Runtime: None
Lock-in: Very low
Enforcement: Low–medium

Pros, cons, and best fit

Pros

Portable across static HTML and frameworks.
Transparent in source and DevTools.
Native cascade and inheritance remain useful.

Cons

Architecture is not compile-time enforced.
Requires genuine cascade literacy.
Dead-style detection needs external tooling.

Best fitCustom sites, SPAs, documentation, and portable artifacts.

Lets global CSS and composition do most of the work before adding utilities, blocks, and explicit exceptions.

Build: None
Runtime: None
Lock-in: Very low
Enforcement: Low

Pros, cons, and best fit

Pros

Composition is separated from component appearance.
Produces small, low-specificity component rules.
Works with native CSS rather than suppressing it.

Cons

Less prescriptive than BEM.
Needs a controlled utility policy.
Does not create local scope by itself.

Best fitCustom, content-rich, responsive interfaces.

Orders CSS from broad, low-specificity rules toward narrow components and high-impact utilities.

Build: Optional
Runtime: None
Lock-in: Very low
Enforcement: Low–medium

Pros, cons, and best fit

Pros

Predictable broad-to-specific architecture.
Maps naturally to cascade layers.
Good governance model for shared stylesheets.

Cons

File order alone cannot enforce precedence.
Can create folder and prefix ceremony.
Does not solve component anatomy or scope.

Best fitLarge global CSS systems and layered design-system foundations.

Retains semantic block and element ownership while delegating state, layout, and cascade control to modern CSS.

Build: None
Runtime: None
Lock-in: Very low
Enforcement: Low

Pros, cons, and best fit

Pros

Excellent searchability and ownership.
Readable HTML and stable class contracts.
Framework-independent.

Cons

Verbose when applied to every DOM node.
Does not enforce local scope.
Modifier proliferation can encode context badly.

Best fitSemantic component ownership across mixed delivery environments.

@scope limits selector reach to a subtree and can define a lower boundary without increasing selector specificity.

Baseline 2025No buildCurrent-browser policy

Build: None
Runtime: None
Lock-in: Very low
Enforcement: Medium

Pros, cons, and best fit

Pros

Bounds generic selectors without generated class names.
Preserves normal cascade and source readability.
Supports donut scopes around embedded subcomponents.

Cons

Newly available rather than long-established.
Does not create a distribution boundary like Shadow DOM.
Still needs semantic component vocabulary and layer order.

Best fitRich-text regions, embedded demos, component subtrees, and current-browser applications.

Converts local class names into generated mappings, preventing ordinary cross-component class collisions.

Build: Required
Runtime: None
Lock-in: Low
Enforcement: Medium

Pros, cons, and best fit

Pros

Ordinary CSS syntax with local class isolation.
Good component colocation and deletion locality.
No client styling runtime.

Cons

Requires compilation.
Local scope does not govern global cascade.
Cross-component overrides need explicit design.

Best fitReact and framework products wanting conventional CSS plus isolation.

Framework compilers colocate styles and transform selectors so they apply primarily to a component’s rendered subtree.

Build: Required
Runtime: None
Lock-in: Medium
Enforcement: Medium

Pros, cons, and best fit

Pros

Strong markup, behavior, and style colocation.
Minimal naming ceremony.
Good component deletion locality.

Cons

Framework-specific output and conventions.
Deep selectors can create fragile coupling.
Global tokens and layout still need governance.

Best fitVue or Svelte applications fully owned by one framework.

Creates a native DOM and CSS boundary, with deliberate customization through custom properties and exposed shadow parts.

Build: Optional
Runtime: Low
Lock-in: Low
Enforcement: High

Pros, cons, and best fit

Pros

Strongest native encapsulation.
Safe for unknown host applications.
Framework-independent distribution contract.

Cons

Global typography and resets do not simply enter.
Theming must be designed as a public API.
Nested boundaries complicate customization.

Best fitWidgets and web components embedded in external or unknown hosts.

Tailwind v4 uses CSS-first configuration and exposes theme values as CSS variables while retaining utility-first markup authorship and generated output.

v4 CSS-firstBuild-timeUtility authorship

Build: Usually
Runtime: None
Lock-in: Medium
Enforcement: Medium–high

Pros, cons, and best fit

Pros

Fast implementation and strong editor tooling.
Reduces naming and selector decisions.
Configuration can constrain design tokens.

Cons

Moves visual logic into markup.
Repeated class strings become another duplication form.
Migration rewrites substantial templates.

Best fitFramework product teams optimizing for implementation speed and consistency.

Authors styles through JavaScript and can generate or insert CSS from props and runtime application state.

Build: Required
Runtime: Yes
Lock-in: High
Enforcement: Medium

Pros, cons, and best fit

Pros

Direct access to props and JavaScript logic.
Strong component colocation.
Mature React component-library ergonomics.

Cons

Adds runtime, SSR, hydration, and CSP concerns.
Generated output is less transparent.
Framework and library coupling is substantial.

Best fitInterfaces with concrete runtime-driven styling requirements.

Uses TypeScript as a build-time stylesheet preprocessor and emits locally scoped static CSS.

Build: Required
Runtime: None
Lock-in: Medium
Enforcement: High

Pros, cons, and best fit

Pros

Type-safe tokens, themes, and local classes.
Static CSS output.
Strong refactoring for TypeScript design systems.

Cons

Requires compiler integration.
Object syntax is less direct than native CSS.
New CSS features depend on library support.

Best fitTypeScript-first component libraries and enterprise design systems.

Compiles colocated JavaScript definitions into collision-resistant atomic CSS; v0.19 adds compile-time inline atoms with the same output model.

v0.19Compiler enforcedAtomic output

Build: Required
Runtime: None
Lock-in: High
Enforcement: Very high

Pros, cons, and best fit

Pros

Predictable low-specificity atomic output.
Strong consistency across large teams.
Style colocation without runtime insertion.

Cons

Deep compiler and ecosystem commitment.
Generated output is harder to read directly.
Small projects gain little from the machinery.

Best fitVery large React estates with centrally governed styling infrastructure.

Statically analyzes JavaScript and TypeScript to generate atomic utilities and typed component recipes.

Build: Required
Runtime: None
Lock-in: High
Enforcement: Very high

Pros, cons, and best fit

Pros

Typed tokens and explicit finite recipes.
Static atomic output.
Strong design-system constraint surface.

Cons

Static analysis constrains dynamic construction.
Toolchain becomes part of architecture.
Variant systems can grow combinatorially.

Best fitTyped design systems needing recipes and atomic output without runtime CSS.

Treat custom properties as component inputs, semantic attributes as finite state, and container queries as context adaptation.

Native contractCross-frameworkStyle queries gated

Build: None
Runtime: None
Lock-in: Very low
Enforcement: Medium

Pros, cons, and best fit

Pros

Creates an interoperable theming and variant surface.
Separates public inputs from internal implementation.
Works across static HTML, frameworks, and web components.

Cons

Custom-property contracts need naming and version governance.
Browser CSS cannot type-check every contract at authoring time.
Style-query support is broader for custom properties than normal declarations.

Best fitReusable components that need portable theming, density, tone, and layout inputs.

Represents reusable design decisions as foundation, semantic, and component-level values—usually through CSS custom properties at runtime.

Build: Optional
Runtime: None
Lock-in: Very low
Enforcement: Medium

Pros, cons, and best fit

Pros

Cross-component consistency and theming.
Native variables support inheritance and local overrides.
Can bridge design and multiple platforms.

Cons

Tokens do not create architecture alone.
Oversized vocabularies increase cognitive load.
Raw scales can weaken semantic intent.

Best fitEvery serious system—provided the token vocabulary remains small and semantic.

Defines finite component options, defaults, and compound combinations as a typed public API.

Build: Usually
Runtime: Low–none
Lock-in: Medium–high
Enforcement: High

Pros, cons, and best fit

Pros

Explicit supported component combinations.
Autocomplete and type checking.
Good for controls with finite sizes and tones.

Cons

Variant axes can multiply rapidly.
Can conflate state, responsiveness, and static options.
Often coupled to one styling tool.

Best fitButtons, badges, controls, and stable design-system primitives.

Organizes interface inventories into atoms, molecules, organisms, templates, and pages; it is not a cascade architecture.

Build: None
Runtime: None
Lock-in: Very low
Enforcement: Low

Pros, cons, and best fit

Pros

Shared vocabulary across design and engineering.
Encourages pattern inventories and composition.
Useful for design-system governance.

Cons

Classification debates can become unproductive.
Can encourage premature fragmentation.
Does not control CSS behavior or output.

Best fitPattern-library organization—not CSS class naming.

No matching patterns

Clear the search or choose a broader category.

Comparison matrix

The core trade-offs at a glance.

Higher enforcement usually requires more build coupling. Stronger isolation usually reduces the reach of global styling. Faster authoring often moves visual information closer to markup or code.

Approach	Primary job	Build	Runtime CSS	Isolation	Enforcement	Portability	Lock-in
Native layered CSS	Cascade architecture	No	No	Low	●●○○	●●●●	Very low
CUBE CSS	Responsibility model	No	No	Low	●○○○	●●●●	Very low
BEM-light	Semantic naming	No	No	Convention	●○○○	●●●●	Very low
Native `@scope`	Selector reach boundary	No	No	Medium	●●○○	●●●●	Very low
CSS component APIs	Portable inputs and state	No	No	Contract	●●○○	●●●●	Very low
CSS Modules	Local class scope	Yes	No	Medium	●●●○	●●●○	Low
Shadow DOM	Hard native boundary	Optional	Low	High	●●●●	●●●○	Low
Tailwind CSS	Utility authoring	Usually	No	Convention	●●●○	●●○○	Medium
Runtime CSS-in-JS	Dynamic styling	Yes	Yes	Medium	●●●○	●○○○	High
Vanilla Extract	Typed static CSS	Yes	No	Medium	●●●●	●●○○	Medium
StyleX	Atomic CSS at scale	Yes	No	Compiler	●●●●	●○○○	High
Panda CSS	Typed atomic recipes	Yes	No	Compiler	●●●●	●○○○	High
Token-first	Design decisions	Optional	No	N/A	●●○○	●●●●	Very low

Rating scale: one dot is low; four dots is high. “Isolation” describes selector or component boundaries, not application security.

Compatibility governance

Adopt capabilities through three explicit lanes.

Baseline is a portfolio policy, not a badge collection. Assign every feature to a dependency lane and preserve a usable fallback when the lane is not core.

Lane 1 · Core dependency

Safe as the normal architecture

@layer, custom properties, native nesting, :has(), Grid, Flexbox, and logical properties
Size container queries and container units
color-scheme, forced-colors, reduced motion, and semantic HTML

S03 S23 S27 S36

Lane 2 · Current-browser dependency

Adopt through a declared support floor

@scope for bounded selector reach
anchor-scope for anchored UI ownership
contrast-color() as an aid—not a replacement for a contrast audit

S24 S32 S35

Lane 3 · Progressive enhancement

Never required for task completion

CSS custom functions and if()
Scroll-state and anchored container-query behavior
Style queries beyond the interoperable custom-property subset

S28 S29 S30 S31

/* Core fallback */
.card__body {
  display: grid;
  gap: var(--space-4);
}

/* Current-browser enhancement */
@supports at-rule(@scope) {
  @scope (.card) to (.embedded-widget) {
    :scope { container-type: inline-size; }
  }
}

Required adoption record

Supported browser and embedded-webview floor
Fallback behavior when unsupported
Whether the feature affects completion or only presentation
Owner and review trigger

Recommended synthesis

Use a stack of complementary patterns.

The goal is not to select one ideology. It is to assign one clear responsibility to each layer.

Native CSS platform

Layers, custom properties, size container queries, logical properties, selectors, and a declared feature-maturity policy.

ITCSS-style order

Reset → vendor → tokens → base → layout → components → utilities → documented overrides.

CUBE-style composition

Reusable stack, cluster, grid, sidebar, switcher, and full-bleed relationships.

BEM-light ownership

Semantic block and element classes. No DOM mirroring. No location-based component names.

Policy-gated native scope

Use @scope for selector reach where supported, while retaining semantic classes as the durable ownership vocabulary.

Semantic state and variants

Native state first, then ARIA, data attributes, and only then static modifier classes.

@layer reset, vendor, tokens, base,
       layout, components, utilities,
       overrides;

@layer components {
  .signal-card {
    container: signal-card / inline-size;

    --card-padding: var(--space-4);

    padding: var(--card-padding);
  }

  .signal-card:where(
    [data-density="compact"]
  ) {
    --card-padding: var(--space-3);
  }

  @container signal-card (width >= 32rem) {
    .signal-card__header {
      grid-template-columns:
        minmax(0, 1fr) auto;
    }
  }
}

Architecture decision record

Default first. Deviate deliberately.

This turns the explainer into an operating decision rather than a catalog of options.

Status · Adopted default

Decision

New handcrafted CSS uses native cascade layers, semantic tokens, reusable layout compositions, BEM-light ownership, semantic attribute state, and size-container responsiveness. @scope is permitted by browser policy; limited-availability CSS remains progressive.

Decision drivers

Portable single-file and framework delivery
Direct source and DevTools inspectability
No styling runtime and low dependency risk
Stable semantics for human and AI-assisted maintenance
Progressive enhancement and print resilience

Approved deviations

Native @scope for current-browser targets with a non-scoped semantic fallback
CSS Modules for framework-local collision prevention
Typed static CSS for a multi-team TypeScript design system
Shadow DOM for components embedded in unknown hosts
Utility-first tooling where an existing platform standard requires it

Required evidence to deviate

The default cannot satisfy a measurable requirement
The added build or runtime cost is documented
Migration and exit strategy are understood
Theme, accessibility, CSP, SSR, and debugging impacts are reviewed

Review triggers

A limited feature reaches Baseline or the supported-browser floor changes
Organization-wide design-system or framework standard changes
Repeated class collision or stylesheet ownership failures
Measured bundle, rendering, or developer-experience constraints
Browser capabilities materially simplify the architecture

Operating rules

Architecture only works when its boundaries are explicit.

Components own internals.

Parents and composition primitives own external placement and spacing.

State stays semantic.

Prefer :disabled, aria-expanded, and data-state over generic state classes.

Components respond to space.

Use container queries for reusable components and media queries for application-shell decisions.

Tokens represent decisions.

Use foundation → semantic → component-local tokens. Avoid tokenizing every literal value.

Specificity stays weak.

One class by default. Use :where() for conditions. Let layers control precedence.

Tooling must earn its cost.

Adopt a compiler for enforcement, scale, or typed APIs—not merely to avoid naming classes.

Red-team checklist

Patterns that quietly erode the system.

Modifier explosion

Context, state, viewport, and layout encoded as a growing list of --modifier classes.

Unlayered patches

Normal unlayered author rules outrank normal rules in named layers, bypassing the intended cascade contract.

Deep native nesting

Nesting can hide selector depth. It does not turn DOM-coupled selectors into a sound architecture.

Utility sprawl

Arbitrary one-off utilities recreate inline styles with a custom naming tax and weak semantic traceability.

Token maximalism

Long aliases for every value create more indirection than design consistency.

Compiler without leverage

A build-time styling system adds migration and debugging cost unless scale or enforcement pays it back.

Provenance

Claims remain traceable to their source context.

This artifact prioritizes specifications and official project documentation. The comparison and recommendations are a reasoned synthesis rather than a vendor benchmark.

Artifact record

Updated: July 18, 2026 · 10:18 PM America/Bogota
Version: 2.0.0
Method: Comparative synthesis, feature-maturity analysis, architecture decision record, and accessibility validation
Scope: CSS architecture, scoping, authoring, design-system patterns, and delivery trade-offs
Authorship: Commissioned by the project owner; synthesized by OpenAI; source ownership remains with each publisher.
Validation: Static HTML structure, unique IDs, internal references, and interactive control hooks were checked.
Limits: Ratings are qualitative. Ecosystems and browser support may change after compilation.
Contrast audit: WCAG 2.2 AA text and non-text contrast review completed July 18, 2026. Minimum audited faint-text ratio: 4.84:1. Minimum interactive boundary ratio: 3.11:1.
Machine data: JSON-LD, claim-to-source provenance, and the contrast-audit record are embedded in the document head.

Methodology

Approaches were classified by the problem they solve and assessed against build cost, runtime cost, scope strength, enforcement, portability, lock-in, browser maturity, and delivery context. Standards and compatibility references are Evidence A. Official product documentation is Evidence B for intended capability. Recommendations are Evidence J architectural judgments.

Claim register

C01
BEM remains useful for semantic component ownership.
Evidence: S01, S02
C02
Native CSS now provides explicit cascade, contextual responsiveness, and bounded selector reach.
Evidence: S03, S23, S24
C03
Composition-first and broad-to-specific methodologies complement component naming.
Evidence: S04, S05, S18, S21
C04
CSS Modules, framework scoping, and Shadow DOM provide materially different isolation boundaries.
Evidence: S06, S08, S09, S10
C05
Utility, runtime, typed, and atomic systems trade portability for workflow or enforcement.
Evidence: S07, S11–S15
C06
Tokens and recipes define reusable design decisions and finite public variants.
Evidence: S16, S20, S22
C07
The recommended handcrafted default is a synthesis, not a direct vendor prescription.
Derived from C01, C02, C03, and C06
C08
Approved deviations depend on distribution boundary, scale, and required enforcement.
Architectural judgment informed by C04, C05, and C06
C09
Normal text targets 4.5:1 contrast; essential interface boundaries and graphics target 3:1.
Evidence: S25, S26

C08

@scope can be a current-browser selector boundary.Evidence A · S24 S27 S32

C09

Custom functions, if(), and advanced container-query forms remain progressive.Evidence A · S28 S29 S30 S31

Source registry

S01BEM methodology — Naming convention

Primary BEM documentation for block, element, and modifier naming and independence.

bem.info/en/methodology/naming-convention/

S02Get BEM — Naming

Widely used double-hyphen modifier and double-underscore element naming dialect.

getbem.com/naming/

S03MDN — @layer

Reference for declaring cascade layers and defining their precedence order.

developer.mozilla.org/.../@layer

S04CUBE CSS — Overview and principles

Primary explanation of Composition, Utility, Block, and Exception and its progressive CSS philosophy.

cube.fyi/

S05CUBE CSS — Composition and Exception

Primary documentation for skeletal layout compositions and data-attribute exceptions.

cube.fyi/composition cube.fyi/exception.html

S06CSS Modules — Official documentation

Defines local class mappings and the local-to-global export model.

github.com/css-modules/css-modules

S07Tailwind CSS — Styling with utility classes

Official description of utility-class authoring, variants, and source-driven generation.

tailwindcss.com/docs/styling-with-utility-classes

S08Vue — Single-file component CSS features

Framework documentation for scoped styles and CSS Modules in Vue single-file components.

vuejs.org/api/sfc-css-features.html

S09MDN — Using Shadow DOM

Native encapsulation model for reusable web component internals.

developer.mozilla.org/.../Using_shadow_DOM

S10MDN — CSS shadow parts

Reference for deliberately exposing selected shadow-tree elements through ::part().

developer.mozilla.org/.../Shadow_parts

S11Emotion — Introduction

Official runtime CSS-in-JS authoring model and framework integration overview.

emotion.sh/docs/introduction

S12Next.js — CSS-in-JS guide

Framework guidance for CSS-in-JS compatibility with Server Components, style registries, and server insertion.

nextjs.org/docs/app/guides/css-in-js

S13Vanilla Extract — Zero-runtime Stylesheets in TypeScript

Official description of type-safe local styles and static CSS generation at build time.

vanilla-extract.style/

S14StyleX — Introduction

Official compiler model for local JavaScript authoring and optimized collision-free atomic CSS.

stylexjs.com/docs/learn

S15Panda CSS — Getting started

Official overview of static analysis, typed styling primitives, and generated atomic CSS.

panda-css.com/docs/overview/getting-started

S16Panda CSS — Recipes

Official recipe and compound-variant model with ahead-of-time atomic class generation.

panda-css.com/docs/concepts/recipes

S17SMACSS — Categorizing CSS rules

Original taxonomy of base, layout, module, state, and theme rules.

smacss.com/book/categorizing/

S18ITCSS — Inverted Triangle CSS glossary

Concise documentation of the broad-to-specific layered architecture.

developer.helpscout.com/seed/glossary/itcss/

S19Atomic Design — Methodology

Primary description of atoms, molecules, organisms, templates, and pages.

atomicdesign.bradfrost.com/chapter-2/

S20Open Props — Token-first CSS

Framework-independent custom-property library demonstrating reusable design-token scales.

open-props.style/

S21Every Layout — Layout primitives

Intrinsic, reusable layout composition patterns for robust responsive interfaces.

every-layout.dev/

S22Design Tokens Community Group — Stable specification announcement

Vendor-neutral design-token specification milestone and cross-tool interoperability context.

w3.org/community/design-tokens/.../first-stable-version/

S23MDN — CSS container queries

Reference for styling components based on containing context rather than viewport alone.

developer.mozilla.org/.../Container_queries

S24MDN — @scope

Reference for limiting selector reach to a bounded DOM subtree.

developer.mozilla.org/.../@scope

S25W3C WAI — Understanding Contrast (Minimum)

Official WCAG 2.2 guidance for minimum luminance contrast of text and images of text.

w3.org/WAI/WCAG22/Understanding/contrast-minimum

S26W3C WAI — Understanding Non-text Contrast

Official WCAG 2.2 guidance for essential interface components, states, and graphical objects.

w3.org/WAI/WCAG22/Understanding/non-text-contrast

S27Web Platform Baseline — compatibility model

Evidence A. Defines Widely available, Newly available, and limited-availability compatibility categories.

Verified July 21, 2026 · Evidence A

web.dev/baseline

S28MDN — CSS custom functions and @function

Evidence A. Defines custom CSS functions and documents limited availability.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../@function

S29MDN — CSS if()

Evidence A. Defines conditional CSS values, fallback requirements, and limited availability.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../if()

S30MDN — Container size and style queries

Evidence A. Describes container-query types and current style-query limitations.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../Container_size_and_style_queries

S31MDN — Container scroll-state queries

Evidence A. Describes scrollable, scrolled, snapped, and stuck container-state conditions.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../Container_scroll-state_queries

S32MDN — anchor-scope

Evidence A. Documents Baseline 2026 support and subtree limits for anchor association.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../anchor-scope

S33Tailwind CSS v4.0

Evidence B. Official release documentation for CSS-first configuration and CSS theme variables.

Verified July 21, 2026 · Evidence B

tailwindcss.com/blog/tailwindcss-v4

S34StyleX v0.19 release

Evidence B. Official release documentation for compile-time inline atoms and current tooling direction.

Verified July 21, 2026 · Evidence B

stylexjs.com/blog

S35MDN — contrast-color()

Evidence A. Documents Baseline 2026 support and automatic contrasting color behavior.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../contrast-color()

S36MDN — Native CSS nesting

Evidence A. Documents the native nesting model and widely available nesting selector.

Verified July 21, 2026 · Evidence A

developer.mozilla.org/.../Nesting