Az új CSS-funkciók, amelyek már itt vannak: @function, if(), light-dark(), corner-shape és a többi

Évekig íratlan szabály volt a webfejlesztésben, hogy ha egy weboldalnak kicsit is okosan kellett viselkednie, például sötét módra váltania, a gomb szövegszínét a háttérhez igazítania vagy görgetésre animálnia, akkor valaki írt hozzá egy adag JavaScriptet. A Google I/O 2026 után ez a munkamegosztás látványosan átrendeződött. Az új CSS-funkciók közül a natív egyéni függvények (@function), a feltételes if() és a képekkel is működő light-dark() a Chrome 150-ben, a border-shape és a text-box a Chrome 149-ben érkezett meg, a kontrasztos szövegszínt automatikusan kiválasztó contrast-color() pedig már a 146-os verzió óta elérhető. Ami nemrég még külön szkript volt, az ma néhány sor a stíluslapban.

Egy cégvezetőnek ebből nem a szintaxis az érdekes, hanem az, amit a számlán és a látogatói élményen lát: kevesebb kód, amelyet karban kell tartani, gyorsabb oldal, mert a böngészőnek kevesebb szkriptet kell letöltenie és futtatnia, végül olcsóbb módosítás, amikor két év múlva új arculatot kap a cég. A 2026. szeptember 22-i állapot szerint végigvesszük, melyik funkció használható már nyugodtan élesben, melyik még kísérleti, hogyan adj biztonságos tartalékmegoldást (fallbacket) a régebbi böngészőknek, végül azt is, mennyit spórolhat mindezzel egy KKV honlapja. A rövid kódrészletek a fejlesztőknek szólnak, a szöveg nélkülük is követhető.

Röviden

• A Chrome fejlesztői blogjának 2026. július 1-jei összefoglalója szerint a Chrome 146 és 150 közötti kiadásai hozták el az egyéni CSS-függvényeket (@function), a feltételes if() függvényt, a képekkel is működő light-dark() függvényt, a border-shape és a text-box tulajdonságot, a stabil Chrome pedig szeptember közepén már a 154-es verziónál tart.
• A színekre használt light-dark() az MDN szerint 2024 májusa óta, a contrast-color() 2026 áprilisa óta Baseline, vagyis minden nagy böngésző friss verziója ismeri őket, így a sötét mód és az automatikus kontrasztszín ma már JavaScript nélkül, biztonságosan megoldható.
• Az if() és a corner-shape az MDN szerint még korlátozottan elérhető, ezért ezeket csak progresszív fejlesztésként érdemes használni: a régebbi böngésző a sima, megszokott változatot kapja, az újabb pedig a szebbet.
• A görgetésre induló animációkhoz többé nem kell külön JavaScript-könyvtár, mert a scroll-driven animáció a görgetéshez köti a mozgást, a Chrome 146 óta elérhető scroll-triggered animáció pedig egy határ átlépésekor magától elindul.
• Egy KKV-nak akkor éri meg átállni, ha úgyis újraépíti vagy felújítja a honlapját, egy jól működő oldal teljes átírását viszont pusztán az új CSS kedvéért ritkán tudjuk javasolni.

Mik azok az új CSS-funkciók és miért érdekelnek egy cégvezetőt?

Az új CSS-funkciók olyan stíluslap-képességek, amelyekkel a böngésző maga old meg korábban JavaScriptet igénylő feladatokat, például a sötét módot, a kontrasztos szövegszínt, a feltételes értékeket vagy a görgetésre induló animációkat. A cégvezető ebből kevesebb karbantartandó kódot, gyorsabb oldalt és olcsóbb későbbi módosítást nyer.

A CSS (Cascading Style Sheets, magyarul lépcsőzetes stíluslapok) az a nyelv, amely leírja, hogyan nézzen ki egy weboldal: milyen színű a gomb, mekkora a címsor, mennyi levegő marad két bekezdés között. Évtizedekig viszonylag egyszerű nyelvnek számított, amely remekül tudott színt és méretet adni, dönteni, számolni vagy a látogató viselkedésére reagálni viszont csak nagyon korlátozottan. Ahol logika kellett, ott belépett a JavaScript, a weboldalak programozási nyelve, a maga letöltendő, futtatandó és rendszeresen frissítendő kódjával.

A Chrome for Developers blogon Bramus és Una Kravets 2026. július 1-jén foglalták össze a Google I/O 2026-on bemutatott webes felületi újdonságokat. A lista több mint harminc tételből áll, a közös nevező pedig az, hogy a böngésző egyre több olyan feladatot vállal át, amelyhez eddig külön szkript vagy külső könyvtár kellett. Három okból érdemes ezt üzleti szemmel is végiggondolni.

Az első és legkézzelfoghatóbb ok a sebesség: minden JavaScript-fájlt a látogató telefonjának le kell töltenie, fel kell dolgoznia és le kell futtatnia, jellemzően ugyanazon a fő szálon (main thread), amelyen a kattintásokra és a gépelésre is reagálnia kellene. A Google Core Web Vitals mérőszámai közül az INP (Interaction to Next Paint, vagyis a kattintás és a következő képkocka megjelenése között eltelt idő) éppen ezt a fajta túlterhelést teszi láthatóvá. A sebességről külön cikkben írunk, itt elég annyi, hogy amit a CSS old meg, azt a böngésző saját, erősen optimalizált motorja végzi, nem egy utólag betöltött és a többi szkripttel versengő program.

A második ok a karbantartás, amely egy honlap élettartama alatt könnyen többe kerül, mint maga az elkészítés. Minden külső JavaScript-könyvtár egy újabb függőség: frissíteni kell, követni kell a biztonsági javításait, egy nagyobb keretrendszer-váltásnál pedig gyakran kiderül, hogy a kedvenc animációs csomag már nem működik az új verzióval. A böngészőbe épített CSS-funkciónak ezzel szemben nincs külön frissítendő verziója, a webes platform alapelve ráadásul az, hogy ami ma működik, az a jövőbeli böngészőkben is működni fog.

A harmadik ok a rugalmasság, amely az arculatváltásnál és az akadálymentességnél jön elő igazán. Ha a honlap színeit, árnyalatait és kontrasztját néhány központi szabály számolja ki, akkor egy új márkaszín bevezetése nem kétnapos keresgélés a stíluslapban, hanem egyetlen érték átírása. Ugyanez igaz a sötét módra és a gyengénlátó látogatók igényeire: amit a böngésző automatikusan kezel, azt a következő kampányoldalnál sem lehet elfelejteni.

A cikkben többször visszatérő fogalom a Baseline, a webes platform közös jelölése, amely megmutatja, hogy egy funkciót már minden nagy böngésző (a Chrome, az Edge, a Firefox és a Safari aktuális verziója) támogat-e. A „newly available” (újonnan elérhető) státusz azt jelenti, hogy a legfrissebb verziók mind ismerik, a „widely available” (széles körben elérhető) pedig azt, hogy ez az állapot már legalább 30 hónapja fennáll. Amelyik funkció egyik címkét sem kapta meg, azt az MDN „limited availability”, vagyis korlátozott elérhetőség jelzéssel mutatja.

Öt funkció, amely tényleg kevesebb kódot jelent

A címadó sztárokról, a @function és az if() függvényről a következő szakaszban lesz szó, a mindennapi munkában azonban az alábbi öt csendesebb újdonság spórolja meg a legtöbb felesleges kódot.

sibling-index() és sibling-count(): a sorszám, amelyet eddig kézzel írtunk be

A sibling-index() függvény megmondja, hányadik egy elem a testvérei között (egytől kezdve számozva), a sibling-count() pedig azt, hány testvér van összesen. A Chrome I/O-összefoglalója szerint mindkettő a Chrome 150-ben érkezett. Elsőre apróságnak hangzik, de gondolj a klasszikus effektre, amikor egy szolgáltatásoldalon a kártyák kicsit egymás után, lépcsőzetesen úsznak be: eddig minden kártya külön osztályt vagy JavaScript által beírt késleltetést kapott, így nyolc kártyához nyolc szabály kellett. Mostantól ennyi is elég:

.szolgaltatas-kartya {
  animation: beuszas 0.4s ease-out both;
  animation-delay: calc(sibling-index() * 0.05s + 0.2s);
}

A késleltetés képlete a Chrome blogjának példájából való: az első kártya 0,25, a második 0,3 másodperc múlva indul, a többi pedig ugyanígy, öt század másodpercenként követi. Ha jövő héten kilencedik szolgáltatást vesz fel a marketinges a tartalomkezelőben, a stíluslaphoz senkinek sem kell hozzányúlnia. A sibling-count() akkor hasznos, ha a darabszámhoz akarod igazítani például a kártyák szélességét vagy egy színátmenet lépéseit.

@starting-style és allow-discrete: be- és kiúszó elemek trükközés nélkül

A felugró értesítések, a sütisáv és a lenyíló menük elegáns eltüntetése régóta a webfejlesztés egyik kis szégyenfoltja. A display: none ugyanis nem animálható, ezért aki szépen el akarta halványítani az elemet, annak JavaScripttel kellett kivárnia az animáció végét és csak utána elrejtenie. A transition-behavior: allow-discrete (a Chrome összefoglalója a 146-os verzióhoz köti) átmenetet enged az olyan diszkrét, vagyis csak ugrásszerűen váltó tulajdonságokon is, mint a display vagy az overlay, így az elem látható marad, amíg a kilépő animáció le nem fut. A párja, a @starting-style azt adja meg, honnan induljon az átmenet, amikor az elem először megjelenik az oldalon.

.sutisav {
  opacity: 1;
  transition: opacity 0.3s, display 0.3s allow-discrete;
}
.sutisav.rejtett {
  display: none;
  opacity: 0;
}
@starting-style {
  .sutisav {
    opacity: 0;
  }
}

A sütisáv elrejtéséhez továbbra is kell egy kattintáskezelő, amely a rejtett osztályt ráteszi az elemre, az időzítés és a várakozás körüli bűvészkedés viszont teljesen kikerül a szkriptből. A böngésző pontosan tudja, mikor ér véget az animáció, így senkinek sem kell ezredmásodpercre egyeztetnie a CSS-t és a JavaScriptet.

A closedby attribútum: bezárás kattintásra és Esc-re

A modális ablak (a tartalom fölé ugró párbeszédablak) bezárása a háttérre kattintva vagy az Esc billentyűvel olyan elvárás, amelyet a látogatók észre sem vesznek, amíg nem működik. Eddig ehhez eseménykezelőket kellett írni, amelyek figyelik a kattintás helyét és a billentyűzetet. A Chrome 147-ben megjelent closedby attribútum any értékkel a Chrome blogja szerint deklaratívan, egyéni JavaScript nélkül adja meg ezt a „light dismiss” néven ismert viselkedést:

<dialog closedby="any">
  <p>Köszönjük, megkaptuk az ajánlatkérésedet.</p>
</dialog>

Az ablak megnyitásához továbbra is kell egy gomb és egy sornyi szkript, a bezárás logikája viszont már a böngészőé. Ez az akadálymentességnek is jót tesz, mert a billentyűzettel navigáló látogatók minden ablaknál ugyanazt a kiszámítható viselkedést kapják.

text-box: a gomb felirata végre tényleg középen van

Aki dolgozott már grafikussal, ismeri a jelenetet: a tervezőprogramban tökéletesen középre igazított gombfelirat a böngészőben egy-két képponttal lejjebb csúszik. Ennek oka a betűtípusba épített sorköz, amely a betűk fölött és alatt is láthatatlan helyet foglal. A Chrome 149-ben érkezett text-box (a text-box-trim és a text-box-edge rövidített formája) levágja ezt a sávot, így például a text-box: trim-both cap alphabetic beállítással a szöveg doboza a nagybetűk tetejétől az alapvonalig tart. A fejlesztőnek nem kell többé betűtípusonként bűvös negatív margókat írnia, amelyek egy betűcsere után azonnal elromlanak.

Gap decorations: elválasztó vonalak a rácsban

Az árlistákban, a csapatbemutatókban és a logófalakon gyakori igény, hogy a cellák között vékony elválasztó vonal fusson. Hasábos szövegnél erre régóta ott a column-rule tulajdonság, a Grid és a Flexbox elrendezésben azonban eddig szegélyekkel, álelemekkel és negatív margókkal trükköztünk, amelyek a sor végén rendszeresen rossz helyre kerültek. A Chrome 149-ben megjelent gap decorations a Chrome összefoglalója szerint kiterjeszti a column-rule-t a Gridre és a Flexboxra, a sorközökhöz pedig bevezeti a row-rule tulajdonságot. Két sor CSS váltja ki a korábbi trükközést, amely ráadásul reszponzív nézetben sem esik szét.

Mit tud a CSS @function és az if() függvény?

A CSS @function egyéni, újrahasznosítható függvényt definiál közvetlenül a stíluslapban, amely paramétereket kap és a result leíróval ad vissza értéket. Az if() egy tulajdonság értékén belül dönt: stílus-, média- vagy támogatási feltételt vizsgál, majd az első igaz ág értékét használja. Mindkettő a Chrome 150-ben jelent meg.

A @function-t úgy képzeld el, mint egy receptet, amelyet egyszer leírsz, utána pedig bárhol elővehetsz. Aki ismeri a Sass nevű előfeldolgozót, annak ismerős lehet az ötlet, a különbség azonban lényeges. A Sass-függvények a weboldal építésekor, egyetlen alkalommal futnak le, az eredményük pedig kőbe vésett szám vagy szín. A CSS @function ezzel szemben a böngészőben, a látogató gépén dolgozik, így reagál a CSS-változók (custom properties) aktuális értékére, a sötét módra, a konténer méretére és minden olyan feltételre, amely az oldal betöltése után változik.

Vegyünk egy képzeletbeli kecskeméti asztalosüzemet, amelynek honlapján a márkaszínből kell kiszámolni a gombok világosabb hover-változatát (az egérrel föléjük állva megjelenő színt) és a halvány kiemelősávok hátterét:

@function --arnyalat(--szin, --mertek: 20%) {
  result: color-mix(in oklch, var(--szin), white var(--mertek));
}
.gomb:hover {
  background: --arnyalat(var(--marka));
}
.kiemelt-sav {
  background: --arnyalat(var(--marka), 85%);
}

A függvény a márkaszínt a megadott arányban fehérrel keveri, alapértelmezetten 20%-kal. Ha jövőre új arculatot kap az üzem, a fejlesztő egyetlen változót (--marka) ír át, a hover-színek, a sávok és minden más, ebből számolt árnyalat pedig magától követi.

Az if() a másik oldalról közelít: nem új értéket számol, hanem választ a lehetőségek közül. Az MDN leírása szerint háromféle feltételt ismer. A style() az adott elemen beállított CSS-változókat vizsgálja, a media() a képernyő vagy az eszköz jellemzőit (ugyanúgy, mint egy médialekérdezés), a supports() pedig azt, hogy a böngésző ismer-e egy adott CSS-funkciót. Az ágak közül az első igaz nyer, ha pedig egyik sem teljesül, az else ág értéke lép életbe.

.fejlec {
  padding-block: if(
    media(max-width: 600px): 12px;
    else: 28px;
  );
}

Ugyanez eddig egy külön @media blokkban élt, gyakran a stíluslap egészen más részén, így aki a fejléc térközét módosította, könnyen elfelejtette a mobilos változatot. Az if() használatával a döntés ott marad, ahol az érték, így a kód olvasója egy helyen látja az egész logikát. A style() ágakkal pedig egy tartalomkezelőből érkező beállítás, például egy „kiemelt ajánlat” jelölő is közvetlenül vezérelheti a megjelenést: a sablon csak egy CSS-változót állít be a kártyán, a szín, a keret és a címke pedig ebből dönt.

Két dolgot viszont érdemes szem előtt tartani. Az MDN 2026. szeptember 4-én frissített oldala szerint az if() még nem Baseline, hanem korlátozottan elérhető funkció: a legelterjedtebb böngészők közül nem mindegyik ismeri. Ha pedig egyik feltétel sem teljesül és else ág sincs, a függvény az MDN szerint garantáltan érvénytelen értéket ad, ami a gyakorlatban az örökölt vagy az alapértelmezett értékre ejti vissza a tulajdonságot. A tanulság egyszerű: az else ágat mindig írd ki, a @function és az if() pedig maradjon a finomhangolás eszköze, ne a tartószerkezet.

Egy cégvezetőnek mindez annyit jelent, hogy a honlap design rendszere (a színek, méretek és komponensek szabálygyűjteménye) kisebb és átláthatóbb lesz, egy új kampányoldalnál pedig a fejlesztő a meglévő függvényekből dolgozik ahelyett, hogy kódrészleteket másolgatna.

Sötét mód és kontraszt JavaScript nélkül: hogyan működik a light-dark() és a contrast-color()?

A light-dark() két értéket kap, egyet a világos, egyet a sötét módhoz, a böngésző pedig a color-scheme beállítás alapján választ közülük, a Chrome 150-től már képeknél is. A contrast-color() egy háttérszínhez automatikusan fekete vagy fehér szövegszínt ad. Mindkettőhöz néhány sor CSS elég, JavaScript egyikhez sem kell.

A sötét mód eddigi, tipikus megvalósításához kellett a színek teljes, duplikált készlete egy prefers-color-scheme médialekérdezésben, egy kis JavaScript, amely a logót és a világos háttérre tervezett ikonokat cserélte, végül gyakran egy kapcsoló, amely osztályt tett a lap gyökerére. Ha a szkript kicsit később futott le, a látogató egy pillanatra vakító fehér oldalt látott, mielőtt minden besötétült. A light-dark() ezt egyetlen deklarációba sűríti:

:root {
  color-scheme: light dark;
}
body {
  color: light-dark(#1f2328, #e8e6e3);
  background-color: light-dark(#ffffff, #14171a);
}
.fejlec-logo {
  background-image: light-dark(url("logo-vilagos.svg"), url("logo-sotet.svg"));
}

Az MDN kiemeli, hogy a függvény csak akkor működik, ha a color-scheme értéke light dark, amit jellemzően a :root szinten állítunk be. A színekre vonatkozó light-dark() az MDN szerint 2024 májusa óta Baseline, vagyis az összes nagy böngésző aktuális verziója ismeri, így nyugodtan használható élesben. A képes változat újabb: a Chrome I/O-összefoglalója szerint a Chrome 150-ben érkezett, az MDN pedig már dokumentálja a függvény második formáját, amely két képértéket (url(), linear-gradient() vagy none) fogad.

Egy korlátot azért őszintén ki kell mondani: ha a látogató egy kapcsolóval a rendszerbeállítástól függetlenül is választhat témát, a választás megjegyzéséhez továbbra is kell pár sor JavaScript, amely a gyökérelem color-scheme értékét átállítja. A színek, a képek és az ikonok cseréje viszont már a CSS dolga.

contrast-color(): olvasható szöveg bármilyen háttéren

A contrast-color() egy másik, régi bosszúságot old meg. Tegyük fel, hogy egy képzeletbeli debreceni webshop minden termékkategóriának saját színt ad, a kategóriacímkéket pedig a tartalomkezelőben bárki átszínezheti. Eddig vagy a fejlesztő gyártott le kézzel minden színhez egy olvasható szövegszínt, vagy egy JavaScript-függvény számolta ki a háttér fényességét. A Chrome blogja szerint a contrast-color() a WCAG AA kontrasztkövetelményei alapján automatikusan feketét vagy fehéret ad vissza, az MDN szerint pedig döntetlen esetén a fehér nyer.

.kategoria-cimke {
  background: var(--kategoria-szin);
  color: contrast-color(var(--kategoria-szin));
}

A jó hír, hogy a contrast-color() az MDN szerint 2026 áprilisa óta Baseline, tehát minden nagy böngésző legfrissebb verziójában működik. A kevésbé jó hír az, hogy nem csodaszer. Az MDN kifejezetten figyelmeztet, hogy a WCAG AA szerinti 4,5:1-es kontrasztarány sem ad minden esetben jól olvasható szöveget, a középtónusú hátterek pedig sem feketével, sem fehérrel nem adnak elég kontrasztot. Az MDN példájában egy királykékes (#2277d3) háttéren a függvény fekete szöveget választ, amely kis betűméretnél nehezen olvasható. A gyakorlati tanács ezért az, hogy a márkaszíneket előre teszteld, a contrast-color() függvényt pedig kifejezetten világos vagy sötét hátterekkel használd.

Az akadálymentességhez tartozik még egy apró, de hasznos HTML-újdonság, a text-scale nevű meta címke, amely a Chrome 150-ben jelent meg. A Chrome blogja szerint ezzel az oldal engedélyezi, hogy a gyökérelem kezdő betűmérete arányosan kövesse az operációs rendszer és a böngésző szövegméret-beállítását. Idősebb célcsoportnál ez egyetlen sorral teszi olvashatóbbá az oldalt, ha az elrendezés relatív egységekben (rem, em) készült.

Mire jó a corner-shape, a border-shape és a shape()?

A corner-shape a lekerekített sarkok formáját változtatja meg (squircle, bevel, scoop, notch), a border-shape a clip-path szintaxisával ad nem téglalap alakú keretet, a shape() pedig összetett alakzatot ír le közvetlenül a CSS-ben. Mindhárom díszítő képeket és SVG-trükköket vált ki, a corner-shape viszont még kísérleti.

A lekerekített sarok (border-radius) két évtizede a webdesign alapeleme, de mindig ugyanazt tudta: egy negyed kör- vagy ellipszisívet. Aki ennél többet akart, például az okostelefonos alkalmazásikonokról ismert, lágyabb „squircle” formát, levágott sarkú kártyát vagy jegyszerű, befelé ívelő sarkot, annak háttérképhez, SVG-maszkhoz vagy clip-path-hoz kellett nyúlnia. Ezeknél a keret, az árnyék és a fókuszjelző körvonal jellemzően nem követte a formát.

A corner-shape erre ad egyszerű választ. Az MDN leírása szerint a round az alapértelmezés (a megszokott lekerekítés), a squircle a négyzet és a kör közötti lágy átmenet, a bevel egyenes vonallal vágja le a sarkot, a scoop befelé ívelő, homorú sarkot rajzol, a notch befelé mutató bevágást, a square pedig gyakorlatilag visszaállítja a derékszöget. A corner-shape csak border-radius mellett hat, cserébe a háttér, a keret, a körvonal, az árnyék, a túlcsorduló tartalom levágása és a backdrop-filter is követi az új formát.

.ajandekutalvany {
  border-radius: 20px;
  corner-shape: scoop;
}
.csapat-foto {
  border-radius: 40px;
  corner-shape: squircle;
}

Egy képzeletbeli balatoni panzió így CSS-ből rajzolhatja meg a kuponszerű, homorú sarkú ajándékutalvány-kártyát, a csapatfotók pedig ugyanazt a lágy formát kaphatják, amelyet a látogató a telefonja ikonjain lát. A legszebb az egészben a fallback: amelyik böngésző nem ismeri a corner-shape tulajdonságot, egyszerűen figyelmen kívül hagyja, így a látogató a szokásos lekerekített sarkot látja. Semmi sem törik el, az oldal legfeljebb egy fokkal kevésbé különleges.

Óvatosságra ettől függetlenül szükség van, mert a Chrome I/O-összefoglalója kísérletiként mutatja be a corner-shape-et, az MDN pedig 2026. augusztus 27-i frissítésében korlátozottan elérhető, kísérleti technológiaként jelöli. Díszítésre tökéletes, az arculat lényegét viszont ne bízd rá.

border-shape és shape(): formák, amelyek nem vágnak, hanem rajzolnak

A Chrome 149-ben érkezett border-shape a Chrome blogja szerint ugyanazzal az alakzat-szintaxissal ír le nem téglalap alakú szegélyt, mint a clip-path, a döntő különbség azonban az, hogy nem levág, hanem rajzol: a keret, a körvonal és az árnyék a formához igazodik. A szintén a 149-es verzióhoz kötött shape() függvény összetett geometriai útvonalakat ír le közvetlenül a CSS-ben, amelyeket a clip-path, a border-shape vagy a shape-outside is felhasználhat. Hullámos szekcióhatár, beszédbuborék alakú idézetdoboz, ferde fejléc: ami eddig egy grafikus által exportált SVG-fájl volt, az ma egy sor a stíluslapban, amely reszponzív nézetben is együtt nyúlik az elemmel.

A kísérleti listán szerepel még a betűméretet a konténer szélességéhez igazító text-fit, valamint a HTML-in-Canvas, amely origin trial, vagyis regisztrációhoz kötött próbaidőszak formájában érhető el. Ezekkel ma még kár tervezni.

Animáció görgetésre: scroll-driven és scroll-triggered animációk

A scroll-driven animáció a görgetés mértékéhez köti az animáció állását, így készül például az olvasási csík vagy a parallax hatás. A scroll-triggered animáció ezzel szemben egy hagyományos, időalapú animációt indít el, amikor a görgetés átlép egy határt. Az utóbbi a Chrome 146 óta elérhető, JavaScript-könyvtár egyikhez sem kell.

A görgetésre reagáló effektusok a céges honlapok kedvencei: beúszó számok a „rólunk” oldalon, fokozatosan előtűnő referenciák, a képernyő tetején kúszó olvasási csík egy blogcikknél. Eddig mindegyikhez szkript kellett, jellemzően az IntersectionObserver nevű böngészős felület vagy egy animációs könyvtár, például a GSAP könyvtár ScrollTrigger bővítménye, ami letöltendő kódot, frissítendő függőséget és egy gyengébb telefonon akár akadozó görgetést is jelentett.

Scroll-driven animáció: a mozgás a görgetéshez kötve

A scroll-driven animációnál a Chrome blogja szerint az animáció előrehaladása közvetlenül a görgető konténer pozíciójához kötődik. Egy olvasási csík, amely a cikk tetején mutatja, hol tart az olvasó, így néz ki:

.olvasasi-csik {
  transform-origin: left;
  animation: toltes linear;
  animation-timeline: scroll(root);
}
@keyframes toltes {
  from { transform: scaleX(0); }
  to { transform: scaleX(1); }
}

A csík hossza pontosan követi a görgetést, egyetlen sor JavaScript nélkül. Ha a scroll() helyett view() idővonalat használsz, az animáció az elem saját láthatóságához kötődik, így egy kép fokozatosan a helyére csúszhat, miközben a látogató elgörget mellette. A sorrendre figyelni kell: az animation rövidítés visszaállítja az idővonalat, ezért az animation-timeline mindig utána következzen.

Scroll-triggered animáció: indítás egy határ átlépésekor

A scroll-triggered animációt a Chrome 146 hozta el. Itt nem a görgetés mértéke mozgatja az animációt: a Chrome blogja szerint egy hagyományos, időalapú CSS-animáció indul el, amikor a görgetés átlép egy meghatározott határt. A timeline-trigger tulajdonság jelöli ki, melyik görgetési sávban aktiválódjon az elem, az animation-trigger pedig ehhez a kioldóhoz köti az animációt. A különbség üzletileg is számít: a scroll-driven animáció megáll, ha a látogató abbahagyja a görgetést, a scroll-triggered viszont a megszokott tempóban végigfut, ami egy beúszó referenciablokknál vagy egy kiemelt ajánlatnál természetesebb hatást kelt.

Görgetésfüggő fejléc és magától kiemelt tartalomjegyzék

Két további újdonság a navigációt teszi okosabbá. A Chrome 148-ban érkezett scroll-state lekérdezésekkel (scroll-state queries) a Chrome blogja szerint egy konténer görgetési állapotától függően formázhatod a benne lévő elemeket (a konténer ehhez a container-type: scroll-state beállítást kapja). Így például egy fejléc összehúzódhat vagy árnyékot kaphat, miután a látogató elkezdett lefelé görgetni, amihez eddig görgetési eseményfigyelő kellett.

Hosszú szolgáltatásoldalakon és blogcikkekben gyakori a tartalomjegyzék, amelynek aktuális pontja kiemelődik, ahogy a látogató halad lefelé. Ezt eddig scrollspy néven ismert szkriptek oldották meg. A Chrome 149-ben érkezett scroll-target-group: auto a Chrome blogja szerint automatikusan kiemeli a görgetési pozícióhoz tartozó navigációs linket, a böngésző aria-current attribútumot tesz rá, a formázáshoz pedig a :target-current pszeudoosztály használható. A képernyőolvasót használó látogató így ugyanúgy tudja, hol tart az oldalon, ami egy kézzel írt szkriptnél gyakran kimarad.

A mozgás ne szédítsen

Minden görgetési animációhoz tartozik egy figyelmeztetés: a látogatók egy része a rendszerbeállításaiban kérte, hogy az oldalak kevesebb mozgást mutassanak, mert a nagy, görgetéshez kötött mozgásoktól szédülhetnek. Ezt a prefers-reduced-motion médialekérdezéssel kell tiszteletben tartani:

@media (prefers-reduced-motion: reduce) {
  .olvasasi-csik,
  .szolgaltatas-kartya {
    animation: none;
  }
}

Az oldalak közötti animált átmenetek szintén ebbe a családba tartoznak: a Chrome 146-tól a dokumentumok közötti, a 147-től pedig az egyetlen elemre szűkített View Transitions érhető el. Ezekről és az alkalmazásszerű navigációról külön cikkünkben írunk részletesen.

Mennyit spórolhat egy KKV az új CSS-funkciókkal?

Egy 30 aloldalas KKV-honlap újraépítésekor saját, szemléltető becslésünk szerint az új CSS-funkciók nagyjából 18 fejlesztői órát spórolhatnak meg, ami 10 000 Ft-os óradíjjal 180 000 Ft. A nagyobb és tartósabb nyereség azonban a kevesebb függőségben és az olcsóbb karbantartásban jelentkezik.

Az alábbi táblázat nem mérés, hanem szemléltető becslés egy képzeletbeli, 30 aloldalas szegedi fogászati rendelő honlapjára, amelyet idén újraépítenek. Az órákat egy tapasztalt frontend-fejlesztő feltételezett munkaidejével számoltuk, a régi oszlop a megszokott, JavaScript-alapú megoldást, az új a böngészőbe épített CSS-t jelenti.

A táblázat oldalra húzható ↔

A különbség 31 − 13 = 18 óra. Mondjuk 10 000 Ft-os nettó óradíjjal számolva ez 18 × 10 000 = 180 000 Ft megtakarítás az építéskor, 15 000 Ft-os óradíjnál pedig 18 × 15 000 = 270 000 Ft. Szándékosan beleszámoltuk a fallbackre és a tesztelésre fordított három órát is, mert az új CSS nem ingyenebéd: aki kihagyja ezt a lépést, az a megtakarítást a régebbi böngészőkben megjelenő hibák javítására költi el.

A karbantartásnál az előny kevésbé látványos, de tartósabb. Tegyük fel, hogy a régi megoldás három külső JavaScript-könyvtárra épült (animáció, tartalomjegyzék, felugró ablak), ezek frissítése, a kompatibilitás ellenőrzése és az időnkénti hibajavítás pedig könyvtáranként negyedévente egy órát visz el. Ez évi 3 × 4 = 12 óra, 10 000 Ft-os óradíjjal tehát évi 120 000 Ft, amely az új CSS-megoldásnál nagyrészt eltűnik, hiszen a böngészőbe épített funkciót nem kell frissíteni. Három év alatt ez már 360 000 Ft, ami egy kisebb cég marketingkeretében komoly tétel.

A sebességnyereséget szándékosan nem forintosítjuk, mert oldalanként nagyon eltérő, a tényleges hatást a Google PageSpeed Insights és a Search Console Core Web Vitals jelentése mutatja meg az átállás előtt és után mérve.

Kisebb oldalnál más a helyzet: egy ötoldalas bemutatkozó honlapon, ahol sem sötét mód, sem görgetési animáció nincs, a megtakarítás néhány óra, ami önmagában nem indokolja a hozzányúlást. Az új CSS akkor hoz valódi pénzt, ha úgyis új oldal vagy nagyobb felújítás készül, illetve ha a honlap sok hasonló komponensből áll, ahogy egy több száz termékes webshopnál jellemző.

Böngészőtámogatás Chrome 146-tól 150-ig és a fallback

A cikkben tárgyalt funkciók többségét a Chrome 146 és 150 közötti kiadásai hozták el, a stabil Chrome pedig 2026. szeptember 16-án már a 154-es verzióhoz ért, így a frissített Chrome-ot használó látogatók mindegyiket megkapják. A többi böngészőnél funkciónként eltér a helyzet, ezért a fallback, vagyis a tartalék megjelenés nem választható extra, hanem a munka része.

A táblázat oldalra húzható ↔

Az MDN szerint a színekre használt light-dark() és a contrast-color() Baseline, vagyis a Chrome, az Edge, a Firefox és a Safari aktuális verziója egyaránt ismeri, míg az if() és a corner-shape korlátozottan elérhető. A Chromium-motorra épülő böngészők, például a Microsoft Edge, jellemzően ugyanezeket a funkciókat kapják meg, a pontos verziót azonban érdemes a saját kiadási jegyzékükben ellenőrizni. A többi funkciónál a döntés előtt nézd meg az MDN böngészőkompatibilitási táblázatát, mert a helyzet hónapról hónapra változik.

A fallback alapszabálya és a var()-csapda

A fallback a CSS egyik legrégebbi szabályára épül: amit a böngésző nem ért, azt csendben átugorja. Ha tehát egy tulajdonságot kétszer adsz meg, először a régi, biztos értékkel, utána az újjal, a régebbi böngésző az elsőnél marad, az újabb pedig a másodikkal felülírja. Ezt a szemléletet progresszív fejlesztésnek (progressive enhancement) hívják: az alap mindenkinek működik, a modern böngészők pedig egy réteggel szebb vagy kényelmesebb élményt kapnak.

Van azonban egy csapda, amelybe tapasztalt fejlesztők is belesétálnak. Ha az új függvényen belül CSS-változó (var()) szerepel, a böngésző a deklarációt betöltéskor érvényesnek fogadja el, mert a változó értékét csak később helyettesíti be. Mire kiderül, hogy magát a függvényt nem ismeri, a korábbi, biztos értéket már eldobta, a tulajdonság pedig az örökölt vagy az alapértelmezett értékre esik vissza. A contrast-color(var(--kategoria-szin)) tehát egy régebbi böngészőben nem a tartaléknak szánt fehéret adja, hanem a szülőelem szövegszínét, ami rosszabb esetben sötét szöveget jelent sötét háttéren. Ilyenkor a @supports feltétel a biztos megoldás:

.kategoria-cimke {
  color: white;
}
@supports (color: contrast-color(red)) {
  .kategoria-cimke {
    color: contrast-color(var(--kategoria-szin));
  }
}
@supports at-rule(@function) {
  /* ide kerülnek a @function-re épülő szabályok */
}

A @supports at-rule() a Chrome 150 újdonsága. A Chrome blogja szerint egy-egy at-szabály, például a @function támogatását lehet vele ellenőrizni, a leírókat vagy a teljes szabályblokkokat viszont nem.

A görgetési animációknál pedig az a legfontosabb szabály, hogy az elem alapállapota a végleges, látható állapot legyen, az animáció pedig csak ott lépjen életbe, ahol a böngésző támogatja. Ha fordítva csinálod, tehát a referenciák alapból átlátszók és csak az animáció teszi őket láthatóvá, akkor egy régebbi böngészőben a látogató üres foltokat lát ott, ahol a legjobb ügyfeleid logóinak kellene lenniük.

Hogyan vezesd be az új CSS-t lépésről lépésre egy meglévő honlapon?

Kezdd a látogatóid böngészőinek felmérésével, utána gyűjtsd össze, melyik szkript váltható ki CSS-sel, elsőként pedig a Baseline-funkciókat vezesd be. A kísérleti funkciók csak fallbackkel kerüljenek élesbe, a kiváltott JavaScriptet pedig töröld is, különben a sebességnyereség elmarad.

• Nézd meg, milyen böngészőkkel jönnek a látogatóid. A Google Analytics 4 technológiai jelentése megmutatja a böngészők és a verziók megoszlását. Ha sok a Safari vagy a Firefox, a Baseline-funkciók élvezzenek elsőbbséget.
• Készíts leltárt a kiváltható JavaScriptről. Nézd végig, mely szkriptek felelnek a sötét módért, a görgetési animációkért, a felugró ablakok bezárásáért, a tartalomjegyzék kiemeléséért és a színszámításokért. Ez a lista lesz a munka gerince és egyben az árajánlat alapja.
• Rangsorold a listát a támogatottság szerint. Első körben a Baseline-funkciók jöjjenek (a színekre használt light-dark() és a contrast-color()), utána a Chrome-ban már elérhető, de máshol is elegánsan visszaeső újdonságok (sibling-index(), closedby, scroll-target-group), a kísérleti funkciók pedig csak díszítésként.
• Írd meg először a fallbacket, csak utána a fejlesztést. Minden új függvény mellé tartozzon egy biztos alapérték, a var()-t tartalmazó deklarációk pedig kerüljenek @supports blokkba.
• Teszteld több böngészőben és beállításban. A Chrome fejlesztői eszközeinek (DevTools) Rendering paneljén emulálható a sötét mód és a csökkentett mozgás, de a Safari, a Firefox és egy valódi, középkategóriás androidos telefon is kerüljön be a tesztkörbe.
• Töröld a kiváltott JavaScriptet. Ez a leggyakrabban elfelejtett lépés: ha a régi szkript bent marad, a böngésző továbbra is letölti, a nyereség pedig csak papíron létezik.
• Mérd a hatást. Az átállás előtt és után futtass PageSpeed Insights-mérést a legfontosabb oldalakon, néhány héttel később pedig a Search Console Core Web Vitals jelentésében a valós felhasználói adatokon is ellenőrizd az INP alakulását.
• Dokumentáld a megoldást. Egy rövid belső leírás arról, melyik funkciót mire és milyen fallbackkel használjátok, megóvja a következő fejlesztőt attól, hogy a régi szkriptet jó szándékkal visszaépítse.

Mikor ne használd még az új CSS-funkciókat?

Ne építs kísérleti vagy korlátozottan elérhető funkcióra (corner-shape, if()) olyan megjelenést, amely nélküle használhatatlan. Óvatosnak kell lenned akkor is, ha a látogatóid jelentős része régebbi, központilag frissített céges böngészőből érkezik, vagy ha a stíluslapot útközben egy régebbi eszköz dolgozza fel.

Ha a funkció nélkül eltörik az oldal

A kísérleti és a korlátozottan elérhető funkciók (a corner-shape, a text-fit, az if() vagy a HTML-in-Canvas) a díszítés és a finomhangolás eszközei. Ha a navigáció, a kosárgomb vagy az ajánlatkérő űrlap megjelenése múlik rajtuk, akkor a látogatók egy része hibás oldalt kap, amit a konverziós adatokban csak hetekkel később veszel észre, ha egyáltalán feltűnik.

Ha a közönséged régebbi céges böngészőből jön

A B2B-cégek látogatói gyakran nagyvállalati gépekről érkeznek, ahol a böngészőfrissítést az informatikai részleg központilag, késleltetve engedi. Ha a Google Analytics szerint a látogatók jelentős része több verzióval lemaradva böngészik, a Chrome 150-es újdonságokból náluk csak a fallback látszik. Ez rendben van, ha a fallback gondosan elkészült, csak ne várd, hogy a befektetett munka a célközönséged nagy részénél azonnal látható legyen.

Ha a build-eszközöd vagy a bővítményed nem ismeri az új szintaxist

A weboldalak CSS-ét útközben gyakran tömörítők, előfeldolgozók és gyorsítótárazó bővítmények alakítják át. Mielőtt élesbe kerül egy @function vagy egy if(), ellenőrizd a tesztkörnyezetben, hogy a lánc minden eleme érintetlenül továbbítja-e, mert egy régebbi eszköz csendben kihagyhatja vagy elronthatja az ismeretlen szabályt.

Ha a mozgás öncélú

A görgetési animációk könnyen túlzásba vihetők, főleg ha már alig kerülnek fejlesztési pénzbe. Egy ajánlatkérő oldalon a látogató a telefonszámot és az árat keresi, nem a beúszó ikonokat, a mozgásérzékeny látogatóknak pedig a túl sok animáció kifejezetten kellemetlen. Tapasztalatunk szerint a legjobb görgetési effekt az, amelyik egy információt emel ki (például egy folyamat lépéseit), nem pedig az, amelyik mindent megmozgat.

Mit kérdezz meg a fejlesztődtől, mielőtt rábólintasz?

Kérdezd meg, melyik JavaScript-részt váltják ki CSS-sel, mi a fallback a nem támogató böngészőkben, hogyan tesztelnek Safarin és Firefoxon, végül hogy mérik-e a sebességet előtte és utána. A jó válasz konkrét funkciókat és méréseket nevez meg, nem csak annyit, hogy „modern technológiát használunk”.

A táblázat oldalra húzható ↔

Ha a fejlesztő vagy az ügynökség ezekre magabiztosan válaszol, jó eséllyel olyan honlapot kapsz, amely ma gyorsabb és olcsóbban tartható karban, a következő arculatváltásnál pedig nem kell újraírni a stíluslap felét. A honlapkészítés további ellenőrzőpontjait egy külön cikkben gyűjtöttük össze.

Miben segít a Convergo?

Ha új honlap készül vagy a meglévő felújítása van napirenden, a webdesign és weboldalkészítés szolgáltatásunkban eleve a böngészőbe épített CSS-megoldásokkal és gondosan megírt fallbackkel dolgozunk, a honlapkészítés díja 299 000 Ft weboldalanként. Meglévő oldalnál a programozás és egyedi fejlesztés keretében (10 000 Ft/óra) átnézzük, mely szkriptek válthatók ki CSS-sel és mennyi munkát jelentene az átállás. A support, üzemeltetés és tárhely csomagunk (30 000 Ft/hó, benne 3 fejlesztői óra) a folyamatos karbantartást is leveszi a válladról. Az első lépés egy ingyenes egyeztetés, amelyen megnézzük a honlapod kódját és a látogatóid böngészőadatait, utána konkrét, óraszámmal becsült javaslatot kapsz tőlünk.