A CSS új korszaka: a natív nesting és a változók forradalma

A régi világ: amikor a CSS „kevés volt”

A 2010-es évek frontend fejlesztésében a CSS-t sokan egy szükséges rossznak tartották. A nyelv rendkívül egyszerű volt, de ez az egyszerűség hamar korláttá vált. Nem léteztek változók, nem volt nesting, nem lehetett függvényeket írni, hiányzott a moduláris gondolkodás, és a nagyobb projektek stíluslapjai gyakran teljesen kezelhetetlenné váltak.

Ekkor érkeztek meg a preprocesszorok. A LESS, a Stylus és végül az SCSS gyakorlatilag újradefiniálta a frontend styling világát. A fejlesztők végre írhattak ilyen struktúrákat:

.card {
    background: white;

    .title {
        font-size: 2rem;
    }

    .content {
        padding: 1rem;
    }
}

Ez akkoriban óriási előrelépésnek számított. A nesting természetesebbnek, olvashatóbbnak és karbantarthatóbbnak érződött, mint a hosszú selector-láncok.

Az SCSS emellett változókat is adott:

$primary-color: #4f46e5;
$spacing: 1rem;

Sőt, mixineket, függvényeket, partialokat és import rendszert is. A frontend fejlesztés hosszú időre összefonódott a build pipeline-okkal. Webpack, Gulp, Vite, Parcel — minden projekt része lett valamilyen fordítási folyamat.

A CSS lassú, de brutális evolúciója

Miközben a frontend világ preprocesszorokkal próbálta „megjavítani” a CSS-t, maga a CSS sem állt egy helyben.

A böngészőgyártók fokozatosan elkezdtek olyan funkciókat implementálni, amelyek korábban elképzelhetetlenek voltak natív CSS-ben. Először megjelentek a CSS custom property-k:

:root {
    --primary-color: #4f46e5;
    --spacing: 1rem;
}

Sokan eleinte legyintettek rájuk. „Ez csak egy gyengébb SCSS variable.” A valóság azonban ennél sokkal érdekesebb lett.

A CSS változók ugyanis runtime-ban működnek. Nem build time-ban fordulnak le, hanem valóban élnek a böngészőben. Ez olyan lehetőségeket nyitott meg, amelyeket SCSS-ben nem lehetett natívan megoldani.

Például:

.theme-dark {
    --background: #111;
    --text-color: #fff;
}

.theme-light {
    --background: #fff;
    --text-color: #111;
}

Vagy akár:

.card {
    background: var(--background);
    color: var(--text-color);
}

És mindez azonnal frissülhet JavaScriptből, media query-ből vagy container query-ből.

A natív CSS nesting megérkezése

A valódi fordulópont azonban a natív CSS nesting támogatás volt. Hosszú éveken keresztül úgy tűnt, hogy ez a funkció talán soha nem érkezik meg. A CSS Working Group rengeteg vitát folytatott arról, hogyan nézzen ki a szintaxis, milyen edge case-ek legyenek támogatva, és hogyan lehet mindezt visszafelé kompatibilisen implementálni.

2026-ra viszont a modern böngészők már stabilan támogatják a nestinget.

.card {
    background: white;

    & .title {
        font-size: 2rem;
    }

    & .content {
        padding: 1rem;
    }

    &:hover {
        transform: translateY(-2px);
    }
}

A frontend fejlesztők jelentős része számára ez egészen szürreális élmény. Amit korábban kizárólag SCSS-ben lehetett megvalósítani, az most közvetlenül működik a böngészőben.

Ráadásul nem valamilyen polyfill vagy fordító segítségével, hanem natívan.

A scope-olt változók ereje

A CSS custom property-k egyik legfontosabb tulajdonsága, hogy scope-olhatók.

Ez elsőre talán nem tűnik forradalmi ötletnek, de valójában elképesztően erős architektúrát tesz lehetővé.

.dialog {
    --dialog-background: white;
    --dialog-padding: 2rem;

    background: var(--dialog-background);
    padding: var(--dialog-padding);
}

Majd:

.dialog.danger {
    --dialog-background: crimson;
}

És kész is a lokális theming.

SCSS-ben a változók statikusak voltak. A fordítás után eltűntek. A CSS variable viszont öröklődik, él, változik, reagál.

Ez teljesen új szemléletet hozott a komponens alapú fejlesztésbe. React, Vue, Angular vagy Web Components környezetben a CSS custom property-k gyakorlatilag natív design token rendszerré váltak.

Container query-k és a modern CSS reneszánsza

Mintha mindez nem lett volna elég, a modern CSS további olyan képességeket kapott, amelyek korábban kizárólag JavaScriptes hackekkel voltak megoldhatók.

A container query-k például lehetővé teszik, hogy egy komponens saját mérete alapján reagáljon, ne csak a viewport szélessége alapján.

.card-wrapper {
    container-type: inline-size;
}

.card {
    padding: 1rem;

    @container (min-width: 500px) {
        padding: 2rem;
    }
}

Ez radikálisan megváltoztatta a reszponzív tervezést. A komponensek valóban izolált egységekké váltak.

És itt kezdett igazán érdekes lenni a kérdés: ha a CSS már tud nestinget, tud változókat, tud scope-olást, tud container query-t, tud color-mixet, tud calcot, tud cascade layer-eket, akkor pontosan mi maradt az SCSS kizárólagos előnye?

Az SCSS még mindig erős

Természetesen az SCSS nem tűnt el. Rengeteg enterprise projekt használja továbbra is, és sok fejlesztő számára a mixinek, loopok és függvények még mindig komoly produktivitási előnyt jelentenek.

@for $i from 1 through 12 {
    .col-#{$i} {
        width: calc(100% / 12 * #{$i});
    }
}

Az ilyen dinamikus generálás továbbra sem része a natív CSS-nek.

Emellett sok projekt build pipeline-ja már eleve tartalmaz SCSS fordítást, így különösebb oka sincs az átállásnak.

Sok csapatnál az SCSS egyszerűen megszokásból maradt meg. A fejlesztők szeretik, ismerik, és az évek alatt kialakított architektúrák is erre épülnek.

De valami megváltozott

A különbség inkább pszichológiai.

2016 körül az SCSS szinte kötelező eszköznek számított. A natív CSS túl gyenge volt.

2026-ban viszont egyre több fejlesztő teszi fel ugyanazt a kérdést:

„Valóban szükségem van preprocesszorra?”

Egy kisebb vagy közepes projekt esetén ma már teljesen reális döntés kizárólag natív CSS-t használni.

A nesting működik. A változók működnek. A scope-olás működik. A design tokenek működnek. A theming működik.

Sőt, sok esetben a natív CSS rugalmasabb, mert runtime-ban képes reagálni a környezetre.

Az elmúlt években a frontend világ megszokta, hogy minden problémára újabb tooling a válasz. Build step. Plugin. Compiler. Transformer.

De talán most először történik meg az, hogy maga a platform kezd felzárkózni.