Use now
Features LSCSS already treats as part of a modern evergreen baseline. Check your own matrix, but these should not need defensive ceremony in current projects.
Apply
Native CSS features
Modern CSS removes a lot of old defensive code, JavaScript styling hooks, and build-time tricks. This page is the LSCSS view of that surface: what to use confidently, what to gate or transform, and what to watch because it may change the methodology later.
This is a recommendation guide, not a live compatibility database. Check Baseline, MDN, Can I Use, and your own browser support matrix before a feature becomes a project requirement.
How to read this page
LSCSS cares less about novelty than about safe defaults. A native feature earns its place when it reduces maintenance cost without weakening accessibility, performance, or support policy.
Gate or build
Features worth using when they solve a real problem, but only with the delivery mode, fallback, or rule ordering documented beside the component.
Watch
Features that could simplify LSCSS defaults or remove old workarounds later. Track them, prototype safely, but do not make them required without a project decision.
Treat each row as a project decision prompt. The support label is a starting point; the project matrix and real user data decide whether that feature is required, progressive, build-only, or still off the table.
Use now
Features LSCSS already treats as part of a modern evergreen baseline. Check your own matrix, but these should not need defensive ceremony in current projects.
| Feature | Support | Delivery | LSCSS recommendation | Fallback and review | Sources |
|---|---|---|---|---|---|
Cascade layers@layer | Baseline widely available | Native CSS | The architectural backbone for predictable override order. Use a single declared layer order and keep each file imported into its owning layer. | No useful runtime fallback. If a project must support engines without layers, document that as a major architecture constraint. Last reviewed: | |
Custom properties and design tokens--token | Baseline widely available | Native CSS | The safest way to share colour, spacing, type, radius, and component contracts. Use semantic tokens in settings and consume them from components instead of hard-coding values. | Do not emit legacy duplicate declarations by default unless a product matrix explicitly needs them. Last reviewed: | |
Registered custom properties@property | Baseline newly available | Native CSS | Typed custom properties make tokens safer and allow custom values to animate predictably. Use for important typed tokens, animation values, and component contracts where validation, inheritance control, or interpolation adds clear value. | Use ordinary custom properties first; rely on registration for enhancement unless the project matrix confirms support. Last reviewed: | |
| Logical properties and values | Baseline widely available | Native CSS | Flow-relative spacing, sizing, and borders reduce left/right assumptions. Prefer logical properties for layout, spacing, and borders; keep physical properties for genuinely physical directions. | Use physical properties only when your support matrix or visual requirement demands them. Last reviewed: | |
Low-specificity selector helpers:is() / :where() / :not() | Baseline widely available | Native CSS | Selector tools that reduce repetition without adding architecture by themselves. Use :where() to keep specificity low, :is() to remove repetition, and :not() for simple exclusions. | Use longer explicit selectors if a legacy browser target cannot parse the helper. Last reviewed: | |
Size container queries@container | Baseline widely available, with subfeatures to check | Native CSS | Components can respond to their container instead of guessing from viewport width. Use size queries for portable components; name containers only when the name improves review clarity. | Use viewport media queries or a simpler layout when the component can still work without container awareness. Last reviewed: | |
Scheme-aware token valueslight-dark() | Project target dependent | Native CSS | A concise way to make semantic tokens resolve across light and dark schemes. Use inside semantic tokens when your browserslist supports it, paired with an explicit color-scheme. | Use explicit theme overrides or a build transform if older targets cannot parse the function. Last reviewed: |
Use with care
Features worth using when they solve a real problem, but only with the delivery mode, fallback, or rule ordering documented beside the component.
| Feature | Support | Delivery | LSCSS recommendation | Fallback and review | Sources |
|---|---|---|---|---|---|
Custom media queries@custom-media | Limited natively | Build transform | Named breakpoints and preference queries are excellent for maintainability, but not natively dependable yet. Use in the settings layer only when every CSS delivery path expands it before shipping. | Ship ordinary @media rules, or keep a simpler responsive pattern for projects without a build step. Last reviewed: | |
| CSS nesting | Project target dependent | Native or build transform | Good for grouping related rules, risky when it recreates deep selector chains. Allow shallow nesting only when it improves ownership; do not nest your way around unclear architecture. | Write flat selectors, which remain the easiest code to review in LSCSS. Last reviewed: | |
Relational selectors:has() | Baseline widely available | Native CSS, often gated | Can remove JavaScript styling hooks when parent or sibling state is already in the DOM. Use for progressive styling and non-critical relational states; gate critical UI with @supports selector(:has(*)) when fallback matters. | Keep a state class or simpler DOM hook when the selector decides a critical journey. Last reviewed: | |
Scoped component selectors@scope | Baseline newly available | Native CSS | A native boundary that can reduce naming ceremony inside contained component subtrees. Use where agreed for production, but keep layers, state rules, tokens, and component ownership intact. | Use ordinary semantic component roots and shallow child selectors. Last reviewed: | |
Entry transition start values@starting-style | Baseline newly available | Native CSS, usually gated | Defines the starting values for elements that become visible after initial render. Use in the owning component and preserve required rule order when selectors have equal specificity. | Skip the entry transition; the component should still open, close, and expose state correctly. Last reviewed: | |
Discrete transition controltransition-behavior | Check support before critical use | Native CSS, gated for interaction polish | Allows discrete values such as display, overlay, and content-visibility to transition at the right point. Use for progressive interaction polish only after the fallback state change works without animation. | Discrete values should change immediately without breaking the control. Last reviewed: | |
Native popoverpopover | Baseline newly available | Native HTML and CSS | Useful top-layer behaviour without a full custom dialog stack. Use for suitable menus and lightweight popovers, but keep focus, dismissal, and accessible names explicit. | Use an always-available disclosure, navigation pattern, or carefully tested JavaScript fallback. Last reviewed: | |
Customisable selectappearance: base-select | Limited or evolving | Native CSS behind @supports | Promising native form styling, but still too uneven for default design-system assumptions. Use only as progressive enhancement; the plain select must remain usable and recognisable. | Classic native select styling. Last reviewed: | |
Disclosure content pseudo-element::details-content | Check current support | Native CSS behind @supports | Enables native details content animation without replacing details behaviour. Use for optional disclosure animation only; never make the animation required for comprehension. | Native details open and close instantly. Last reviewed: | |
Intrinsic size interpolationinterpolate-size / calc-size() | Syntax and support still sensitive | Native CSS behind @supports | Can reduce JavaScript height measurement for disclosure and panel motion. Use conservatively in progressive animation examples and verify syntax against current platform docs. | Instant intrinsic size change, or a simpler fixed-size transition when appropriate. Last reviewed: |
Watch list
Features that could simplify LSCSS defaults or remove old workarounds later. Track them, prototype safely, but do not make them required without a project decision.
| Feature | Support | Delivery | LSCSS recommendation | Fallback and review | Sources |
|---|---|---|---|---|---|
Native custom media@custom-media | Watch for native Baseline movement | Not required natively yet | Would let LSCSS named breakpoints work without PostCSS expansion. Keep using the build transform today; revisit when native support is broad enough for your matrix. | Build-expanded @media queries. Last reviewed: | |
| Anchor positioning | Limited or evolving | Prototype only unless matrix allows | Could replace a lot of fragile tooltip, flyout, and anchored overlay positioning code. Track for menus, tooltips, and contextual UI; do not require it for core controls yet. | Use simpler static placement or a well-tested positioning helper. Last reviewed: | |
Scroll-driven animationsscroll-timeline | Limited or evolving | Progressive enhancement | May remove JavaScript scroll listeners for decorative and progress-driven motion. Use only when reduced-motion handling and no-animation fallbacks are already designed. | No scroll-linked animation; content and controls remain usable. Last reviewed: | |
| View transitions | Check current support by transition type | Progressive enhancement | Can improve continuity between pages and states, but motion has accessibility and support costs. Track for navigation polish; respect reduced motion and avoid hiding real loading or focus changes. | Ordinary navigation or state change. Last reviewed: | |
Style and scroll-state container queries@container style() / scroll-state() | Subfeatures vary | Prototype and gate | Could make components react to local state without extra classes in some patterns. Track carefully; size queries are ready, but style and scroll-state queries need separate decisions. | Use existing state classes, data attributes, or size queries. Last reviewed: | |
Field sizingfield-sizing | Check current support | Progressive enhancement | Could reduce JavaScript for auto-growing form controls. Track for textareas and compact form controls; keep normal field sizing as the baseline. | Fixed or manually controlled form control sizing. Last reviewed: | |
| CSS custom functions and mixins | Experimental | Do not rely on for production LSCSS yet | Could replace some preprocessor-only patterns without giving up plain CSS. Watch the specification and tooling; avoid designing architecture around it for now. | Use custom properties, plain declarations, or build-time tooling where already approved. Last reviewed: | |
Subgrid adoption patternssubgrid | Ready to evaluate per project | Native CSS | Support has improved, but the LSCSS question is where it belongs in layout/component ownership. Use when parent-child grid alignment is genuinely shared; do not let layout concerns leak through every component. | Duplicate only the small grid structure needed, or simplify alignment. Last reviewed: |
Sources and review
Keep this page curated. Do not copy full support tables into LSCSS; link to the live data, record the review date, and write the project recommendation in plain language.
# Native CSS feature note
Feature: @scope
Last reviewed: 2026-07-01
Support source: MDN + Baseline
Delivery: native CSS where the project matrix allows it
LSCSS decision: optional for contained component subtrees
Fallback: ordinary component roots and shallow child selectors remain the baselineCore sources to check when adding or changing a row:
If the support story is unclear, write “watch list” first. A feature can move up later; over-promising is harder to unwind.
Adoption checklist
- Does the feature improve maintainability, accessibility, performance, or review clarity?
- Is the support source current, and does it match the project browser matrix?
- Is delivery native, build-transformed, gated with
@supports, or deliberately not used? - Does the baseline experience still work when the feature is missing?
- Does the component own the enhancement, fallback, and any required source order?
- Is the last-reviewed date recent enough for a support-sensitive feature?