30.10.2022 14:00 Priority Hints jsou prostředkem k úpravě prioritizace stahování souborů do prohlížeče. Lidsky řečeno to znamená, že s jejich pomocí můžete zrychlit načtení webu jen pomocí přidání pár řádků kódu. Je to ale obecně už dost pokročilá metoda, takže ji nedoporučuji používat pokud přesně nevíte, co děláte. Priority Hints zatím navíc podporují jen prohlížeče postavené na jádře Chromium, což používání sice neznemožňuje, ale trošku omezuje. Tím končí část textu plná varování a teď už k věci. S Priority Hints v kapse prohlížeči doporučíte, aby zvýšil nebo snížil pořadí prvku ve frontě stahování. Nic víc, nic míň. Specifikace Priority Hints zavádí atribut fetchpriority, který lze použít s prvky HTML, jako jsou img, link, script a iframe: Dále zavádí atribut priority do nastavení při stažení prvků JavaScriptem pomocí funkce fetch : No a jako poslední možnost je vám k dispozici vložení doporučení do HTTP hlavičky: Link: ; fetchpriority=high Link: ; fetchpriority=low Z výše uvedeného je asi už jasné, že pořadí ve frontě stahování můžeme zvyšovat i snižovat. Měníme tak výchozí nastavení priority prvků, například v případě, že se nám jich stahuje až moc najednou. Zmiňuji to proto, že se při čtení můžete ptát, proč se zabývat věcí jako prioritizace v době protokolu HTTP/2, kdy se prvky stahují skoro najednou a rychle. Problém je v tom „najednou“. Například při úvodním vykreslení stránky chceme rezervovat dostupné datové připojení jen pro pár nejdůležitějších prvků a ostatní trošku odložit. Atribut fetchpriority versus přednačtení Vy zkušenější víte o existenci instrukce k přednačtení – . Priority Hints preload nenahrazují, ale doplňují. „Doporučení k upřednostnění“ umožňují jemnější ladění prioritizace. Preload se používat uvnitř v HTML nebo hlavičce HTTP odpovědi. Preload nelze použít např. uvnitř skriptu pro Fetch. Preload neumí snížit prioritu. Preload má podporu v Safari, kdežto atribut fetchpriority zatím jen v prohlížečích Chromium. Volně cituji podle specifikace Priority Hints: Preload je povinné načtení prostředku, který je nezbytný pro aktuální stav stránky. Priority Hints mohou napovědět, že priorita prostředku by měla být nižší nebo vyšší než jeho výchozí priorita, a mohou být také použity k poskytnutí podrobnějšího určení priority. V praxi budeme nejspíš potřebovat obojí, preload i fetchpriority, přičemž tipuji, že někdy bude stačit vhodné použití preloadu a většinou ani to ne. Prostě jde o doplněk pro nás, hračičky s rychlostí webu. Jen na okraj: Specifikace původně mluvila o atributu importance a ten byl také propagovaný na různých místech, ale nakonec se vše změnilo právě na fetchpriority. Pár příkladů do praxe Na praktických příkladech to bude všechno jasnější. Příklad s karuselem Tohle je docela evergreen všech článků o Priority Hints a já jej nevynechám, protože je to velmi dobrý příklad. Vezměme, že na homepage e-shopu máme karusel. To si asi umíme představit, protože e-shop bez karuselu se hledá fakt špatně. Bohužel. Nevýhodou většího počtu obrázků v úvodním HTML ale je to, že všechny mají stejnou prioritu načítání. Z toho pak vyplývá, že se budou stahovat najednou. Líné načtení pomocí atributu loading="lazy" se sem úplně nehodí, protože to by se mělo aplikovat ideálně až na prvky mimo první viewport. Právě k tomuto účelu zde ale je atribut fetchpriority: Tento příklad jsem si rozpracoval do malého demíčka na CodePenu, abyste viděli vliv Priority Hints na vlastní oči. V prvním CodePenu je vidět, že jsem se s implementací nepáral. Do hlavičky dokumentu jsem prostě frnknul styly Bootstrapu a Bento Carouselu tak, jak mně to autoři frameworků doporučili. V horní části obrázku zde pak uvidíte, jak má tento copy/paste přístup neblahý vliv na priority stahování v prohlížeči: Jak atribut fetchpriority změní pořadí stahování prvků ve stránce. Dolní část pobrázku to ukazuje už po optimalizaci. Stačilo rozumně přeskupit prvky v hlavičce a atribut fetchpriority použít pro snížení přednosti načítání pro JavaScript Bootstrapu a všechny obrázky v karuselu kromě prvního. Však si to vyzkoušejte na výsledném CodePenu. Zvýšení priority async skriptu nebo jeho závislosti Pokud do stránky potřebujete vložit asynchronní JS, což obvykle potřebujete, musíte s překousnout fakt, že takovéto skripty se vkládají s nízkou prioritou. Většinou to nevadí, někdy ale jo. Docela dost jo. S pomocí atributu fetchpriority je ale možné takovýto skript popostrčit ve frontě stahování nahoru: Pokud má script závislost, která není vidět v HTML, asi byste pro jeho popostrčení použili preload. I preload bude ovšem vyhodnocen jako s nižší prioritou, proto můžete i ten nechat předběhnout jiné prvky ve frontě stahování: Změnit pořadí prvků stahovaných pomocí Fetch API Opět pěkný příklad ze specifikace. Vezměme, že pro potřeby frontendové apky stahujeme dva JSON soubory s obsahem. V jednom je podstatný obsah, ve druhém něco méně podstatného. I zde je možné pomoci si vlastností fetchpriority: // Články musíme načíst hned fetch .then // Související články chvilku počkají fetch .then Na závěr ještě upozornění: Pokud si s tímto budete hrát, opravdu s nastavováním priorit šetřete a dávejte to jen tam, kde to má opravdu přínos. Stejně jako se na každém druhém webu špatně používá preload, a ve výsledku pak škodí rychlosti, očekávám vlnu pokažené rychlosti webů s pomocí atributu fetchpriority. Ve specifikaci k tomu vyloženě píší: Označení všeho v dokumentu jako vysoce prioritního pravděpodobně zhorší uživatelský prožitek. Já vím, vy to víte. To jen pro jistotu. Podpora v prohlížečích V článku rozebírám vlastnost, která je sice zajímavá a podporovaná všem prohlížeči postavenými na jádře Chromium, ale zatím to není standard a Safari a Firefox k ní zatím nenašli cestu. Pokud fetchpriority budete používat rozumně, jako Progressive Enhancement, pak vám poslouží a nebude moc vadit, že uživatelé Safari a Firefoxu neuvidí benefity vaší optimalizace. V konkrétních prohlížečích vypadá podpora následovně: Chrome od verze 101. Edge také od verze 101. Firefox: probíhá diskuze a hledání pozice k draftu specifikace. Safari: zatím bez signálů o úvahách na implementaci. Více hledejte na CanIUse.com. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
25.10.2022 03:00 Přečtěte si, jak jsem se stal sazečem své vlastní knihy. Stalo se tak s pomocí webových technologií, knihovny Paged.js a několika přesně mířených ručních zásahů do výstupního PDF v Adobe Acrobatu. CSS je kam se podíváš. Proč ne v sazbě knih? CSS je všude. Vytváříme s jeho pomocí weby a webové aplikace. Fajn. Například také ale aplikace, které na první pohled vypadají jako nativní, jako třeba Spotify. Vývojáři je tvoří pomocí webových technologií, což umožňuje framework Electron. CSS to ale dopracovalo už i do vesmíru. Uživatelské rozhraní v kosmické lodi Dragon od SpaceX je dělané pomocí HTML, JS a CSS. „Houstone, máme problém. Vyskočila na nás cookie lišta.“ Pro mě je podstatné, že CSS hraje velkou roli v mé publikační činnosti. Skoro vše píšu v Markdownu a pak pomocí transformací převádím – jednou na blog Vzhůru dolů, jednou do e-booků… Populární formát pro e-knihy EPUB je jen přejmenovaný ZIP archiv, ve kterém opět najdete HTML a CSS soubory. Já mám tedy kaskádové styly skoro úplně všude. Ale co tištěné knížky? Když jsem vydával knihu „Vzhůru do webdesignu", štvalo mě, že sazečům musím kvůli tisku exportovat Word. Sazeči pak CSS opíší do vlastního systému designu v InDesignu. To se nedá automatizovat a je to náchylné na chyby. A navíc se mi to vůbec nelíbí. Schéma distribuce obsahu: Na web a do EPUB to jde dobře. Ty shluky křivek reprezentují procesy, kterým říkám „WTF 1“ a „WTF 2“. Nesrozumitelnou a podivnou činnost sazečů, jejichž vstupem je Word a výstupem tištěná kniha. CSS je přitom navrženo pro tvorbu designu a vzhledu čehokoliv, ne jen webů. Proč s ním tedy nesázet i knihy? Když vezmeme zjednodušené schéma vrstvení CSS vycházející z metodiky ITCSS, zjistíme, že se to hodí i na knížky: Text, komponenty a layout. Čirou náhodou je máme i v knížkách. Text Stylování textu v knížkách pomocí CSS? Jasně, to dává smysl . Komponenty Komponenty máme na webu. Existují i v knížkách? No jasně, třeba každý obrázek s popiskem je vlastně komponenta. V knížkách si umím představit celé design systémy, například pro vydavatelství. I tady se CSS, jako systematický zápis designu a vzhledu, hodí. Layout Layout je v knížkách přítomen na spoustě míst, v té mé třeba v předělu kapitol. I v tom je CSS samozřejmě dobré. Takže ano, CSS se obecně pro tvorbu knížek náramně hodí. Jak se ale dostaneme z prohlížeče do tiskárny? První věc, kterou potřebujeme, je umět vytvořit PDF, hlavní zdroj pro tisk čehokoliv. mPDF a další tradiční metody tvorby PDF Existuje řada knihoven, jako mPDF, které se spouští v PHP. Ty sice CSS používají, ale většinou je to specifická verze stylů, upravená autory knihovny. Specifikace CSS poměrně silně ohnutá také v knihovně mPDF. Přidali si tam nové vlastnosti , jiné odebrali a ty, které v mPDF podporují, mají všelijaká omezení. Prostě a jednoduše – abyste mPDF a podobné knihovny mohli používat, musíte se naučit styly prosazované těmito knihovnami. Znalost CSS vám stačit nebude. Celou dobu si při používání knihoven jako mPDF pak budete trošku ťukat na čelo, protože víte, že v CSS existuje řada vlastností určených vyloženě pro sázení tiskových dokumentů. Asi je vám jasné, že touto cestou jsem se vydat nechtěl. Naštěstí se na obzoru objevila naděje. Skvělý Paged.js V posledních letech se vyrojila celá řada nových knihoven, které fungují na základě webových standardů a principu polyfillu – pomocí JavaScriptu emulují podporu vlastností, které zatím prohlížeč nezvládá. Paged.js, javascriptová spása. Knihovna Paged.js je asi nejjednodušší z nich, ale vysázel jsem s její pomocí docela tlustou knížku, takže leccos zvládne. Paged.js je možné použít pro generování jakýchkoliv výstupů do PDF. Já sázím knížky, vy můžete chtít generovat reporty nebo doklady typu faktur. Knihovnu použijete buď jako NPM balíček na příkazové řádce… npm install -g pagedjs-cli pagedjs pagedjs-cli index.html -o result.pdf … nebo jako polyfill v prohlížeči. Stačí tohle přidat do svého HTML: V tu chvíli v prohlížeči uvidíte náhled v podobě tištěné stránky: Debuguji knížku v DevTools Chromu. Možnost vidět zdrojáky v DevTools prohlížeče je naprosto fantastická! Vy, kteří rádi „designujete v browseru“, víte o čem mluvím. Když Paged.js používáte jako polyfill, výstupem je PDF, které ukládáte z prohlížeče: „Save as PDF“ a je hotovo. Skoro. Nebo vlastně ještě vůbec. Asi vás nepřekvapím sdělením, že Paged.js je psaný v JavaScriptu. To je velká výhoda, protože si běžný webař může pohrát s výstupy. Pokud programování není vaše silná stránka, existuje řada hotový řešení – například pro obsah knihy nebo rejstřík. Já jsem si s těmito předpřipravenými kousky kódu vystačil. Teď už tedy víme, že máme nástroj, který nám ze standardní trojice HTML, CSS a JS dokáže vytvořit PDF. Otázka ale zní, zda si vystačíme s těmi samými kaskádovými styly, které používáme na webech. Nevystačíme. Musíme svou znalost stylů rozšířit o další, již standardizované, ale málo známé vlastnosti. CSS vlastnosti pro tisk CSS Paged Media. Tato část kaskádových stylů existuje již dlouhá léta a vcelku bez povšimnutí se pomalu ale jistě sune vpřed. Samotného mě překvapilo, že jsme se už dostali do stavu, kdy je to možné používat v praxi při sázení tiskových výstupů. Podpora vlastností pro tisk je v prohlížečích vcelku dobrá. Důležité je ale říct si, že občasné nedokonalosti nevadí. Používám totiž polyfill, který chybějící vlastnosti emuluje. I tak ale navíc tvůrci Paged.js doporučují pro tvorbu PDF využít Chrome. Teď už k samotným vlastnostem. Vlastnosti break-* Pomocí vlastností break-inside, break-after a break-before je možné zakázat, vynutit nebo jinak ovládnou rozdělení určité části textu nebo komponenty na dvě stránky. Hodí se to například pro zákaz rozdělení nadpisu na dvě stránky: h1, h2, h3 Více: MDN, CanIUse. Pravidlo @page Tímto pravidlem definujeme vzhled stránky k tisku, například její velikost nebo vnější okraje: @page V případě knihy „CSS: moderní layout“ jde o formát V8, ale můžete si zde nastavit samozřejmě i A4 nebo něco jiného. Více: MDN, CanIUse. Pravidla pro oblasti stránky Platí, že si můžeme pojmenovat určité části dokumentu. Každá stránka pak má své oblasti mimo hlavní obsahovou část, do kterých můžeme umísťovat různé servisní prvky. Zde je vidět například deklarace pro umístění stránkování: @page pageContentMain } Vysvětlím to: Deklarace cílíme na stránky pojmenované pageContentMain a oblast @bottom-right . Umístíme tam obsah v podobě počítadla stránek ). Vdovy a sirotci Jedna ze základních typografických pouček praví, že na posledním řádku odstavce by nemělo zůstat jedno slovo a na začátku stránky by neměl být jediný řádek textu předchozího odstavce . Touto deklarací tomu zamezíme: h1, h2, h3, p, li, blockquote Je to podporované všude, kromě Firefoxu. CanIUse. MDN: widows, orphans. Sazba do bloku a rozdělovníky Sazbu do bloku jsme si ve webdesignu už zhruba před dvaceti lety zakázali, ale v knižní sazbě se vesele používá dál. Proč? Vysvětlení je jednoduché – prohlížeče neumějí automaticky rozdělovat slova, takže sazba do bloku je možná jen tam, kde slova rozdělíme ručně, takže skoro nikde. V knize mám ale toto pravidlo: p Zarovnání do bloku samozřejmě rozumím všechny prohlížeče, ale pro automatické zalamování slov je potřeba mít polyfill jako Paged.js. Na webu bych to ale polyfillem určitě nedělal, to by bylo docela peklo pro performance. Rozdělovníky prohlížeče už ale umí , tak proč tolik povyku? Zakopaný pes je v tom, že kromě Safari nemají browsery odpovídající slovníky pro češtinu . Tolik k základům CSS pro tisk. Takhle vypadá finální knížka v PDF: Layout knihy „CSS: moderní layout“. Následně stačí exportovat z prohlížeče do PDF. A je to. A je to…? PDF máme, tak šup do tiskárny Tiskárna PBtisk, kterou jsem si pro tisk knih vybral, dělá docela velké zakázky a na malé vydavatele jako jsem já nemají zase tolik času. Když jsem jim poslal své první PDF, odpověď zněla stručně a jasně: Pro ofsetový tisk naprosto nevhodné. Trošku jsem to ale očekával, to víte, že ano. PDF z prohlížeče nesplňuje požadavky tiskárny, minimálně v tom, že je v barevném režimu RGB. Tiskárna potřebuje samozřejmě CMYK. PDF je ale možné s pomocí několika úprav v placené verzi Adobe Acrobatu doladit: Převod z RGB do CMYK je možné udělat automaticky. Ano, pro některé typy publikací by to bylo nevhodné, ale pokud se s tím předem počítá u obrázků, vyjde to dobře. Ořezové značky se řeší tak, že v Paged.js nadefinujeme o 3 mm větší stránky a pak v Acrobatu přidáme 3 mm ořezové značky. Prohlížeč nám při exportu do PDF bohužel trošku pokazí barvy, takže je nutné některé automaticky nahradit. Například ze směsi CMY barev je potřeba udělat černou . Tři kroky na půl hodiny práce, na které jsem přicházel zhruba dva měsíce. A nebýt lidí jako Petr Raist Šťastný, Dan Střelec nebo Jirka Kosek, asi bych to nikdy nedokázal. Nakonec je tiskárna spokojená a pustí se do tisku. Je to vysázené pomocí HTML a CSS a je to vytištěné. Jupí! Knížka je hotová, je krásná a má se čile k světu. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
18.10.2022 05:30 Na letošním WebExpu jsem uvedl program dodávaný naší komunitou Frontendisti.cz krátkou keynote o zásadních změnách, které se aktuálně dějí ve vývoji prohlížečů. Zde je její obsah v textové podobě, ale můžete se také podívat na prezentaci nebo video. Frontendová keynote na WebExpo 2022. Nějaký pán tam něco tlachal o prohlížečích. Chci dnes mluvit o našich milovaných prohlížečích. Chci mluvit o tom, co se na nich v posledním roce tolik změnilo. Můj vztah s prohlížeči začal v roce 1996. Když jsem přišel na vysokou školu, většina uživatelů tehdejšího internetu používala Netscape Navigator. Nesnášel jsem ho, byl plný chyb. Na trhu se ale objevil nový a progresivní prohlížeč – Internet Explorer od společnosti Microsoft. V té době nám to ještě připadalo skvělé. Éra dominance jednoho prohlížeče Vysokou školu jsem dokončil v roce 2000. V té době už s prohlížeči bylo všechno jinak. Většina trhu patřila Microsoftu jeho prohlížeči. O čtyři roky později to bylo ještě horší. V té době se zdálo, že na světě existuje jen jeden prohlížeč. Internet Explorer. Vývojáři začali na své stránky umisťovat takovéto ikony jako „Optimalizováno pro Internet Explorer”. Bylo to však zvláštní, protože Microsoft se nepodílel na webových standardech, ale vytvářel své vlastní. Měli jsme tak dvě verze standardů – teoretické oficiální od W3C a pak ty od Microsoftu, které prakticky válcovaly trh. 2022: Co se mění? Přejděme do letoška. Situace už je úplná jiná. Všechny velké technologické společnosti včetně Microsoftu pracují na webových standardech v rámci konsorcia W3C. Máme tu však jiný problém. Různé prohlížeče mají různé priority z pohledu práce na podpoře některých webových standardů. Takže na některé nové funkce čekáme dlouho. Prohlížeče v roce 2022. Zdroj: Statcounter.com. Máme dva hlavní prohlížeče – Chrome a Safari – a několik menších. Internet Explorer už prakticky neexistuje . Jako vývojáři si ale tím pádem nemáme na co stěžovat. Můžeme mluvit o štěstí, že roli Exploreru převzalo Safari, jak říkají mnozí zlí jazykové na adresu prohlížeče od Apple? Ne, ne. Zlí jazykové se už dnes pravděpodobně mýlí. V roce 2021 se začal Apple o věc zajímat na Safari více pracovat. Najali spoustu vývojářů a věci se začaly měnit. Compat 2021 a Interop 2022 Ještě před rokem bylo Safari z hlediska přidávání nových HTML a CSS vlastností nejhorším prohlížečem. Letos však začalo být plně srovnatelné s Chromem a Firefoxem. Chrome a Firefox: „Safari, co blbneš?“ Graf mám od iniciativy Compat 2021. Je to skupina lidí, kteří se snaží sjednotit přidávání podpory webových standardů do prohlížečů. Určují, které funkce jsou nejdůležitější. Díky nim máme v moderních prohlížečích řadu nových funkcí. Například odstranili chyby ve flexboxu a gridu. Přidali také funkci position:sticky nebo vlastnost CSS aspect-ratio. Letošní iniciativa se jmenuje Interop 2022. Jejím cílem je zaměřit se na nové funkce a dostat je do prohlížečů. Díky tomu jsme mohli na WebExpo 2022 prezentovat novinky, jako jsou kaskádové vrstvy v CSS nebo dialogové okno v HTML. A těšíme se na další novinky – například CSS color functions, subgrid a další… Interop 2022 dashboard. Jsou na tom dobře. Všichni. Konečně! Toto je aktuální stav. Jak vidíte, menší prohlížeče nyní z pohledu přidávání vlastností ze standardů mohou konkurovat Chromu a vývoj nových CSS a HTML vlastností se odehrává v režimu kooperace mezi prohlížeči. Myslím si, že to je pro nás jako webové vývojáře skvělé. Děje se to poprvé v historii, buďme za to rádi. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
12.10.2022 17:45 Subgrid umožní vytvořit zanořenou mřížku, která zároveň podědí layout rodičovského gridu. Je to velmi praktické, ale zatím podporované jen ve Firefoxu a Safari. Subgrid je součástí specifikace CSS gridu. Grid je skvělý, ale dříve či později se s ním dostaneme do situace, kdy potřebujeme jeden grid zanořit do druhého. V takové situaci si pak pochopitelně přejeme, aby vnitřní grid dokázal podědit vnější layout. Jak vidíte na obrázku níže, subgrid mám to pomůže zařídit. Vnitřní části položek budou lícovat, i když mají různě velký obsah. Grid a subgrid. Táta a syn. Můžeme to samozřejmě zajistit i bez subgridu: Nastavit prvkům fixní rozměry na výšku nebo použít JavaScript . Staré páky mezi kodéry si vzpomenou na složité tabulkové layouty, kterými se toho dalo dosáhnout, ale ve kterých se nikdo nevyznal… Příklad s kartou produktu Víte vy co? Ukážu vám to na jednoduchém příkladu. Na obrázku výše totiž vidíte layout podobný tomu, který používám na Vzhůru dolů. Mám seznam položek, říkejme jim karty produktu. Každá karta má složitější strukturu, ve které najdete nadpis, obrázek, text a tlačítko: Text… Tlačítko… Vnější rozvržení, tedy to, které se týká vodorovného umístění karet, udělám gridem. To žádný problém nebude: .container Umísťuji zde dvě položky ). Přeji si, aby nebyly užší než 250px a širší než 400px. Mezera mezi položkami je 4rem. To bude asi bez problémů, že? Ale když já chci, aby nadpisy, obrázky, texty i tlačítka jednotlivých karet byly vždy ve stejné výšce. Přidáváme layout pro jednotlivé karty Nejprve musíme změnit rodičovský layout. Uděláme to tak, že přidáme řádky pomocí vlastnosti grid-template-rows. .container Jak vidíte, nemáme příliš velké ambice položky layoutu nějak omezovat. Víme jen, že budou čtyři . A hodláme je pouze zarovnávat mezi sebou navzájem. A teď kouzlo, subgrid Zápis pro vnitřní mřížku u jednotlivých položek, který řešíme podmřížkou , bude: .item Prohlížeči dáváme tyhle instrukce: Budiž grid ! Umísti tuto položku do čtyř buněk gridu . Svislý směr mřížky nechť je subgridem, takže po gridu zdědí vnější mřížku . Je to jasné? Výsledek uvidíte na obrázku, který vám snad pomůže s pochopením celé věci, což je opět možné zkoušet na živé ukázce. Zelená podmřížka si hoví v modré mřížce a je spokojená. My také, protože vnitřní položky karet jsou navzájem zarovnané. Živá ukázka vám řekne více. Poznámky k subgridu Vzhledem k tomu, že v době aktualizace textu subgrid umí jen dva menší prohlížeče, Firefox a Safari, nepůjdu u této části CSS gridu úplně do hloubky. Pár poznámek zde ale uvedu: Vícerozměrnost sugridu V ukázce jsme pro podmřížku využili jen svislý směr rodičovského layoutu. Je ale samozřejmě možné využít i vodorovný nebo prostě oba směry najednou. Pak se z toho stává jeden velký tabulkový layout, jako z roku 2002. Dělám si legraci, je to samozřejmě daleko, daleko lepší než layout v . Dědění mezer Vlastnost gap se z rodičovského gridu samozřejmě dědí i na ten vnitřní. Je ale možné si mezery ve vnitřním layoutu změnit novou deklarací gap. Žádné přidávání implicitních řádků nebo sloupců V běžném gridu je možné pomocí vlastností grid-auto- definovat rozvržení pro řádky či sloupce. Ty se automaticky přidají, když se rozšíří obsah v HTML. Je asi pochopitelné, že toto v subgridu možné není. Vždy se jen umísťuje do mřížky, která je zděděná shora od rodičovského gridu. Podpora v prohlížečích Subgrid je součástí specifikace CSS Grid Layout Module již od Level 2, která se datuje do roku 2018. Zde je stav k únoru 2022: Firefox podporuje subgrid od verze 70 z prosince 2019. Safari subgrid přidalo v září 2022 do verze 16, od iOS 16 a v aktualizaci pro macOS Monterey a Big Sur. V Chromu se na subgridu – zdá se – docela hodně pracuje. Subgrid má tedy opravdu dobrou šanci, že se ujme a bude nám dobře sloužit už v blízké budoucnosti. Aktuální informace od podpoře hledejte na CanIUse.com/css-subgrid Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
11.10.2022 08:15 Vítejte v referenční příručce pro pseudotřídy v CSS! Pseudotřídy pomáhají obyčejným selektorům při snadnějším vybírání prvků pro stylování. Díky specifikaci Selectors Level 4 a spolupráci tvůrců prohlížečů můžeme dnes, my webaři, používat pseudotřídy, o kterých se nám dříve nesnilo a pomohou nám psát styly jednodušeji a efektivněji. Příkladem takových pseudotříd je :where a další kombinační pseudotřídy. Projdeme si zde ale všechny. Prakticky použitelných pseudotříd je dnes už přes 40 a vsadím se, že některé z nich neznáte. Související „Problémy“ CSS Kaskáda a specificita Dědičnost v CSS Selektory v CSS Pseudotřídy v CSS Rozcestník typů pseudotříd Podívejme se nejprve na roztřídený seznam všech pseudotříd v CSS. Je jich opravu hodně. Odkazy a kotvy Pseudotřídy odkazů a kotev umožňují vybrat různé typy odkazů ve stránce nebo část stránky, která je cílem kotvy. Pseudotřída Zápis Odkaz :any-link Nenavštívený odkaz :link Navštívený odkaz :visited Cíl kotvy :target Uživatelské akce Pseudotřídy uživatelských akcí vybírají aktivní prvky podle jejich stavu vovolaném uživatelem, například najetím kurzorem nebo zaměřením při ovládání z klávesnice. Pseudotřída Zápis Najetí kurzoru :hover Aktivace prvku :active Zaměření prvku :focus Indikované zaměření :focus-visible Zaměření na rodiče :focus-within Uživatelské vstupy Pseudotřídy uživatelských vstupů umožňují vybrat formulářové prvky podle nastaveného očekávání uživatelského vstupu. Příkladem je povinný prvek nebo zvolené zatržítko . Pseudotřída Zápis Povolený prvek :enabled Zakázaný prvek :disabled Možnost zápisu :read-write Nemožnost zápisu :read-only Zobrazený zástupný text :placeholder-shown Použití automatického vyplnění :autofill Výchozí prvek :default Vybraná hodnota :checked Platnost zadání :valid Neplatnost zadání :invalid Povinnost zadání :required Volitelnost zadání :optional Pořadí potomků Pseudotřídy pořadí potomků vybírají prvek podle jeho pořadí v sadě libovolných prvků nebo v sadě prvků stejného typu. Pseudotřída Zápis N-tého prvku :nth-child N-tého prvku od konce :nth-last-child Prvního potomka :first-child Posledního potomka :last-child Jediného potomka :only-child N-tého prvku stejného typu :nth-of-type N-tého prvku typu od konce :nth-last-of-type Prvního potomka typu :first-of-type Posledního potomka typu :last-of-type Jediného potomka typu :only-of-type Kombinace Kombinační pseudotřídy nejsou až tak zaměřené na konkrétní prvky, ale umožňují zjednodušit selektory, snížit specificitu nebo zavádějí nové možnosti jako selektor rodiče. Pseudotřída Zápis Výběru libovolného prvku :is Nulové specificity :where Negace :not Vztahu :has Ostatní Do ostatních pseudotříd řadím prostě to, co se mi jinam nevešlo. Pseudotřída Zápis Směr :dir Jazyk :lang Celá obrazovka :fullscreen Kořenový prvek :root Prázdný prvek :empty Pojďme se teď jednotlivým pseudotřídám podívat na zoubek. Nesnažil jsem se zde o podrobný popis každé pseudotřídy, to by vydalo na knížku. Alespoň jsem všude doplnil nějaký příklad, aby se vám to lépe představovalo. Odkazy a kotvy Tyto pseudotřídy umožňují vybrat různé typy odkazů ve stránce nebo část stránky, která je cílem kotvy. Pseudotřída hypertextového odkazu – :any-link Pseudotřída :any-link v selektoru představuje jakýkoliv prvek , nebo s atributem href. Podpora v prohlížečích je plná . Pseudotřídy pro historii odkazů – :link a :visited Pseudotřídy cílící na historii prohlížení poskytují možnost vybrat navštívené a nenavštívené odkazy: Pseudotřída :link se vztahuje na odkazy, které ještě nebyly navštíveny. Pseudotřída :visited se uplatní, jakmile byl odkaz uživatelem navštíven. Jak je známo, po určité době mohou prohlížeče vrátit navštívený odkaz do nenavštíveného stavu. Podpora v prohlížečích je plná, včetně MSIE – viz :link a :visited. Pseudotřída cíle – :target Adresa URL dokumentu může odkazovat na konkrétní prvky v dokumentu prostřednictvím fragmentu adresy . Prvky, na které se takto odkazuje, jsou pak „cílovými prvky dokumentu“, jinak též kotvami. Právě aktivní cíle pro kotvy můžeme stylovat díky pseudotřídě :target: Ahoj h1:target V případě URL example.cz/#kotva se pak prvek podbarví žlutou. Podpora v prohlížečích je plná . Uživatelské akce Existuje několik pseudotříd uživatelských akcí pro výběr prvku, na který kliká nebo se kterým jinak pracuje uživatel. Prvek může odpovídat několika takovým pseudotřídám současně. Například stav navštíveného odkazu po najetí myši stylujeme tímto způsobem: :visited:hover Pojďme teď na ty pseudotřídy uživatelských akcí. Pseudotřída najetí ukazatelem – :hover Pomocí :hover vybíráme prvky, na které uživatel najede ukazatelem myši nebo jejich potomky. V moderních prohlížečích to je použitelné jak pro odkazy, tak pro běžné prvky. .box:hover Pseudotřída aktivace prvku – :active Umožňuje vybrat prvky, na které uživatel klikne nebo je aktivuje na klávesnici. Selektor je ale platný jen v čase mezi okamžiky, kdy uživatel stiskne a pak uvolní aktivační tlačítko . Pseudotřídu :active standard HTML omezuje jen na interakční prvky typu nebo , ale v moderních prohlížečích funguje na všech prvcích. .box:active Pseudotřída zaměření prvku – :focus Pseudotřída :focus platí, dokud je prvek zaměřený a přijímá vstupy z klávesnice nebo myši. Toto funguje jen na takzvaně zaměřitelných prvcích, tedy těch, které mohou vyvolávat akci nebo mají roli v navigační struktuře . V ukázce níže platí: Pokud na prvek dojdu navigací pomocí klávesy Tab nebo na něj kliknu, trvale zežloutne. .box:focus Pseudotřída indikovaného zaměření – :focus-visible Pseudotřída :focus-visible platí, když platí :focus a zároveň prohlížeč usoudí, že je vhodné tento prvek při zaměření zvýraznit. Prakticky vzato: :focus vám prvek zvýrazní jak při klikání myši, tak při najetí pomocí klávesy Tab. :focus-visible je výhodnější v tom, že u některých prvků vynechá zvýraznění při najetí myši. CodePen vám to snad pomůže pochopit. Máme dva odkazové boxíky: .box-1:focus .box-2:focus-visible Používat pseudotřídu :focus-visible je výhodné proto, že v uživatelských rozhraních často nechceme razantně zvýrazňovat při klikání, ale pro lepší přístupnost chceme prvky zvýrazňovat při navigaci klávesou Tab. Podpora v prohlížečích je plná . Pseudotřída zaměření na rodiče – :focus-within Pseudotřída :focus-within se vztahuje na jakýkoli prvek, pro který platí pseudotřída :focus, ale také na prvek jehož potomek podmínky pro přiřazení :focus splňuje. .container:focus-within V tomto příkladu bude mít rodič červenou outline , pokud je focus na potomka. Vím, že se to používá pro uchování otevření navigace jen s pomocí CSS a tak dále. Podpora je plná . Uživatelské vstupy Sem patří :disabled, :read-only a další pseudotřídy, jež pomáhají vybírat vstupní prvky, které mají nějaký konkrétní stav. Většinou se aplikují na formulářové prvky. Pseudotřídy povolení a zakázání – :enabled a :disabled V HTML můžeme některé aktivní prvky zobrazit, ale zakázat jejich používání. V uživatelském rozhraní se pak objeví „zašedlé“: Enabled Button Disabled Button Pomocí pseudotříd můžeme vybrat takto povolené nebo zakázané prvky: :enabled :disabled Samozřejmě je toto možné aplikovat jen na prvky, se kterými může uživatel interagovat. Podpora :enabled a :disabled je plná ve všech prohlížečích, včetně prehistorických ještěrů. Pseudotřídy proměnlivosti – :read-only a :read-write Některé aktivní prvky mohou sloužit jen pro čtení. Nejsou tedy zakázané, disabled, ale readonly: Read/Write Textarea Read/Only Textarea Pomocí pseudotřít proměnlivosti je pak možné přistupovat k těmto prvkům a stylovat je: :read-write :read-only Za pozornost stojí, že všechny neaktivní prvky, např. i div jsou samozřejmě readonly. Můžete to ale změnit přidáním atributu contenteditable. Podpora je plná. Pseudotřída zobrazeného zástupného textu – :placeholder-shown Některé prvky, zejména ty vstupní, mohou obsahovat zástupný text : Pseudotřída v CSS jménem :placeholder-shown je tu proto, abychom mohli stylovat prvek, který placeholder obsahuje. :placeholder-shown Podpora je plná, v MSIE s prefixem. Pseudotřída použití automatického vyplnění textu – :autofill Pseudotřída :autofill představuje vstupní prvky, které byly automaticky vyplněny prohlížečem a uživatel je následně nezměnil. Podpora je plná s výjimkou MSIE. Pseudotřída výchozího prvku – :default Pseudotřída :default se vztahuje na prvky uživatelského rozhraní, které jsou výchozí ze sady podobných prvků. Příkladem je výchozí tlačítko mezi sadou tlačítek: Default Button Another Button Styly: :default První ze sady tlačítek bude vždy pro odeslání formuláře výchozí a proto se rámeček obarví. Jiným příkladem je stylování výchozí možnosti z vyskakovací nabídky . Pseudotřída vybrané hodnoty – :checked Aplikuje se na vybraná zatržítka, přepínače nebo vybranou hodnotu ze seznamu hodnot. :checked Samotné obarvení nebo jiné stylování vybrané hodnoty zase tak užitečné není, ale v kombinaci s dalšími selektory to začne být zajímavé: input:checked + label input :not Podpora pseudotřídy :checked je plná. Pseudotřída neurčitých hodnot – :indeterminate Pseudotřída :indeterminate se vztahuje na prvky uživatelského rozhraní, jejichž hodnota je v neurčitém stavu. Například přepínač a zatržítko lze přepínat mezi stavy zaškrtnuto a nezaškrtnuto, ale někdy jsou v neurčitém stavu, tedy ani zaškrtnuto, ani nezaškrtnuto. Podobně může být v neurčitém stavu ukazatel průběhu , když není známo procento zbývající k dokončení. Neurčitou hodnotu přidává buď prohlížeč, nebo ji můžete vynutit atributem indeterminate. Následující pseudotřídy, totiž pseudotřídy kontroly vstupních hodnot, umožňují dát uživateli zpětnou vazbu, pokud něco zadá do formulářového prvku. Patří sem možnost stylovat povinná políčka nebo označení špatného vstupu . Pseudotřídy platnosti – :valid a :invalid Pseudotřída :valid v CSS představuje jakýkoli prvek nebo jiný formulářový prvek, jehož obsah se úspěšně validuje. Je tak možné buď stylovat validní, či nevalidní prvky nebo je označit textem pomocí content: input:invalid input:invalid + label::before input:valid + label::before Ukázku jsem převzal z MDN, kde si ji můžete zkoušet. Na některé prvky není možné platnost aplikovat. Je rozdíl mezi prvkem, který nemá žádná omezení, a byl by tedy vždy :valid, např. , a prvkem, který nemá vůbec žádnou sémantiku platnosti dat, např. , a není tedy ani :valid, ani :invalid. Podpora pro :valid i :invalid je plná. Pseudotřídy rozsahu – :in-range a :out-of-range Těmito pseudotřídami se v CSS představuje prvek , jehož aktuální hodnota se nachází nebo nenachází v rozmezí určeném atributy min a max. Viz výše uvedený příklad: input:out-of-range input:out-of-range + label::before input:in-range + label::before Podpora je plná, MSIE ovšem trucuje. Pseudotřídy volitelnosti – :required a :optional Pseudotřída :required v CSS označuje jakýkoliv vstupní prvek , posledního , několikátého nebo n-tého ) potomka určitého prvku. Pseudotřída n-tého prvku – :nth-child Velmi užitečná pseudotřída, která umožní vybrat prvek na základě opakujícího se pořadí – sudé, liché, n-té nebo prostě několikáté prvky. Obsah v závorce se zapisuje podle vzoru An+B a tedy např. 2n+1 bude každý druhý plus jedna. n je cyklus začínající vždy nulou, takže toto splní každý lichý prvek: první, třetí, pátý… Příklady: tr:nth-child tr:nth-child tr:nth-child tr:nth-child li:nth-child li:nth-child li:nth-child Podpora základní syntaxe je plná. Horší byste to měli, pokud máte v úmyslu takto stylovat prvky v , což nyní funguje jen v Safari. Pseudotřída n-tého prvku od konce – :nth-last-child Pseudotřída :nth-last-child funguje stejně jako :nth-child , jen se pořadí počítá od konce: li:nth-child li:nth-child tr:nth-child Základní podpora je plná. Pseudotřída prvního potomka – :first-child Pseudotřída :first-child představuje prvek, který je první mezi svými sourozenci. Je to totéž jako :nth-child . .content > p:first-child Podpora je plná. Pseudotřída posledního potomka – :last-child Pseudotřída :last-child představuje prvek, který je poslední mezi svými sourozenci. Je to totéž jako :nth-last-child . .content > p:last-child Podpora je plná. Pseudotřída pvku bez sourozenců – :only-child Pseudotřída :only-child představuje prvek, který nemá žádné sourozence. Je to mimochodem totéž jako :first-child:last-child nebo :nth-child :nth-last-child , jen to má nižší specifičnost. Podpora je plná. Pojďme dál. Pod kostrbatým názvem „pseudotřídy indexu potomků stejného typu“ se ve specifikaci nachází další kategorie pseudotříd, která stejně jako ta předchozí umožňuje vybrat n-té prvky ze sady sourozenců. V tomto případě je ale výběr omezený na prvky stejného typu, takže shodné HTML značky, jako například img, p nebo jiné. Pseudotřída n-tého prvku stejného typu – :nth-of-type Umožní vybrat prvek stejného typu na základě opakujícího se pořadí. Od pseudotřídy :nth-child se liší v tom, že umožňuje zaměření jen na prvky stejného typu. Příklady: img:nth-of-type img:nth-child Další pseudotřídy pořadí Selektor Vysvětlení :nth-last-of-type Pseudotřída posledního prvku stejného typu. Podobné jako :nth-last-child, jen vybere poslední n-tý prvek stejného typu, takže stejné HTML značky. :first-of-type Pseudotřída prvního prvku stejného typu. Podobné jako :first-child, jen vybere první prvek stejného typu, takže stejné HTML značky. :last-of-type Pseudotřída prvního prvku stejného typu. Podobné jako :last-child, jen vybere poslední prvek stejného typu, takže stejné HTML značky. :only-of-type Pseudotřída prvku stejného typu bez sourozenců. Pseudotřída :only-of-type představuje prvek, který nemá žádné sourozence stejného typu. Jde o obdobu konstrukce pseudotříd :first-of-type:last-of-type. V závěrečné části tohoto dlouhého textu se podíváme na zoubek pseudotřídám, které zatím nenašly podporu v prohlížečích. To, abychom se měli na co těšit. Kombinace Kombinační pseudotřídy nejsou až tak zaměřené na konkrétní prvky, ale umožňují zjednodušit selektory, snížit specificitu nebo zavádějí nové možnosti jako selektor rodiče. Pseudotřída výběru jakéhokoliv prvku – :is Pseudotřída :is kontroluje, zda prvek na pozici ve vnějším selektoru odpovídá některému ze selektorů v seznamu selektorů. Je to užitečný syntaktický cukr, který umožňuje vyhnout se ručnímu vypisování všech kombinací jako samostatných selektorů: .header h2, .footer h2, .side h2 :is h2 Specifičnost pseudotřídy :is je nahrazena specifičností jejího nejkonkrétnějšího argumentu. Ve specifikaci je k nalezení tento příklad. Zaměřme se v něm na prvek ol: :is > ul > , ol > , .list > , Vysvětlím: V prvním příkladě máme jednu pseudotřídu a jeden atributový selektor. Je to stručnější, ale je zde silnější specificita o hodnotě . V druhém je jedna třída a jeden element. Je to ukecanější, ale má to slabší specificitu . Podpora je plná . Pseudotřída nulové specificity – :where Na rozdíl od :is nepřispívá pseudotřída :where ani žádný z jejích argumentů ke specifičnosti selektoru. Specifičnost :where je vždy nulová. .header h2, .footer h2, .side h2 :is h2 :where h2 Od Stephanie Eckles jsem si půjčil následující příklad: :where :where :where má vždy nulovou specifičnost. To znamená, že jej můžeme použít k nastavení rozumných výchozích hodnot, které lze přepsat. Výchozí hodnoty v demonstrovaném příkladu můžete přepsat pomocí ul nebo ol . Není třeba uvádět také atributový selektor kvůli zvýšení specificity. Podpora selektoru :where je plná s tradiční výjimkou MSIE. Pseudotřída negace – :not Pseudotřída, která vybere prvek, který není reprezentován jejím argumentem: :is h2 :not h2 Specifičnost pseudotřídy :not je nahrazena specifičností nejspecifičtějšího selektoru v jejích čárkou oddělených argumentech. Podpora pseudotřídy :not je plná . Pseudotřída vztahu – :has O relační pseudotřídě :has jsem už dříve psal. Bez ohledu na specifikaci lidsky řečeno je pro nás důležité, že je :has je použitelný jako selektor rodiče… a:has … nebo také jako selektor přechozího sourozence: h1:has Podpora je v Safari a koncem srpna 2022 bude v Chrome. Na Firefox se zatím čeká. Ostatní Pomocí jazykových pseudotříd je možné stylovat prvky podle směru textu ) nebo nastavení jazyka ). Pseudotřída směru ) Pseudotřída :dir umožňuje webařům napsat selektory, které reprezentují prvek na základě směru určeného jazykem dokumentu. Selektor Vysvětlení h1:dir prvek jehož směr vykreslení podle jazyka je nastavený jako ltr, tedy zleva doprava . h1:dir prvek jehož směr vykreslení podle jazyka je nastavený jako rtl, tedy zprava doleva . Podporu pseudotřídy směru dir v době psaní textu zatím implementoval pouze Firefox. Zajímá vás rozdíl mezi pseudotřídou :dir a selektorem atributu ? Je tam. Selektor atributu se týká pouze daného atributu, pokud je přítomný. Pseudotřída :dir by měla využívat k znalosti sémantiky dokumentu ze strany prohlížeče, takže fungovat, i pokud není jazyk nastavený přímo na HTML prvcích. Například v HTML se směr jazyka prvku dědí, takže potomek bez atributu dir bude mít stejnou směrovost jako jeho nejbližší předek s platným atributem dir. To by samozřejmě atributový selektor nefungoval. Pseudotřída jazyka – :lang Pseudotřída :lang umožňuje psát CSS selektory citlivé na jazyk dokumentu. Selektor Vysvětlení h1:lang prvek , který má nastavený český jazyk. :lang > h1 prvek uvnitř dokumentu v belgické francouzštině. Podpora v prohlížečích je plná . Mimochodem, v HTML je možné jazyk pro dokument nebo prvky dokumentu nastavit kombinací atributu lang, informací ze značek meta a případně také v hlavičkách HTTP. Rozdíl mezi pseudotřídou :lang a atributovým selektorem spočívá v tom, že atributový selektor provádí pouze porovnání s atributem lang u elementu, zatímco pseudotřída :lang se opět snaží zjistit nastavení jazyka jakýmkoliv způsobem. Další rozdíl je v tom, že atributový selektor funguje jako wildcard a umí tedy rozpoznat všechny jazyky začínající na en. Pseudotřída běhu přes celou obrazovku – :fullscreen Pseudotřída :fullscreen se asi nejlépe využije pro stylování stránky zobrazující video nebo samotnou stránku přes celou obrazovku. Hezký příklad jsem našel na MDN, kde různě stylují tlačítko na zobrazení videa přes celou obrazovku: #fs-toggle:not #fs-toggle:fullscreen Další pseudotřídy umožňují výběr na základě informací, které se nacházejí ve stromu dokumentu, ale nelze je reprezentovat jinými selektory. Pseudotřída kořenového prvku – :root Ve DOMu odpovídá pseudotřída :root kořenovému prvku objektu Document. V HTML to bude standardně element , což se ale může javascriptem změnit. V praxi se pseudotřída díky své vyšší specificitě používá pro deklaraci autorských vlastností : :root Podpora je plná. Pseudotřída prázdného prvku – :empty Pseudotřída :empty zastupuje prvek, který nemá žádné potomky. Jen pro pořádek: Potomkem může být buď další prvek nebo text . Potomky naopak nejsou komentáře nebo CSS deklarace. Podpora je plná. Nepodporováno Mezi pseudotřídami je řada takových, které nemají podpory mezi prohlížeči ani co by se za nehet vešlo. Alespoň v době psaní tohoto textu. Všechny je už ale najdete ve čtvrté verzi specifikace CSS Selectors. Pseudotřída kontejneru cíle – :target-within Podobně jako :target vybere cíl kotvy a navíc také každý prvek, jehož potomek je cíl kotvy a tedy splňuje podmínky výběru pro :target. Pseudotřída místního odkazu – :local-link Představuje odkaz, jehož cílová absolutní adresa URL se shoduje s adresou URL vlastního dokumentu. Odkazuje tedy sám na sebe. Zápis nav :local-link by pak umožnil zakázat podtržení odkazu, který vede na aktuální URL. Časové pseudotřídy – :current, :past, :future V některých kontextech konzumace obsahu se může hodit označení prvku, který je časově aktuální, předchozí a následující. Specifikace jako příklady uvádí konzumaci dokumentu pomocí audia a prohlížení videa obsahujícího titulky tvořené technologií WebVTT. Pseudotřídy stavu zdrojů – :playing, :paused, :buffering Ve specifikaci též najdete velmi zajímavé pseudotřídy, pomocí kterých by bylo možné vybrat zdroj stánky jako obrázek nebo video, který se přehrává , je pozastavený nebo se ukládá do mezipaměti . Ve specifikaci je těchto pozoruhodných tříd více, jen zatím pražádnou podporu nemají. Pseudotřídy stavu zobrazení prvků – :modal, :picture-in-picture Opět jde velmi zajímavá skupina pseudotříd, například pro element ve stavu modálního okna nebo zobrazení elementu v režimu PiP , tedy překrývající obsah . Funguje z nich jen :fullscreen. U ostatních si zatím musíme počkat na implementace v prohlížečích. Pseudotřída prázdných hodnot – :blank Umožní nastylovat prázný textový vstup nebo víceřádkový vstup: textarea:blank I zde je podpora v době psaní textu bohužel nulová. Pseudotřídy interakce s uživatelem – :user-valid a :user-invalid Tyto pseudotřídy zvolí prvky, které mají správný nebo nesprávný vstup, takže se podobají pseudotřídám platnosti . Rozdíl je v tom, že :user-valid a :user-invalid platí až poté, co s ním uživatel významně interagoval. Pseudotřídy :valid a :invalid se na prvek aplikují, i když jej uživatel nijak nevyplnil, což je bohužel většinou vcelku nepraktické. Nepraktické na pseudotřídách interakce s uživatelem zase je, že v době psaní textu je podporuje pouze Firefox. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
07.10.2022 05:00 INP je nová metrika rychlosti webu, se kterou přichází Google. Zatím je považována za experimentální, ale všeobecně se očekává, že po doladění nahradí v rámci metrik Web Vitals.) zhruba v horizontu jednoho roku poměrně neuspokojivou metriku FID . Tato změna se dotkne celé řady z vás, protože INP je metrika daleko přesnější a k webům přísnější. Metrika rychlosti odezvy Metrika Interaction to Next Paint zaznamenává prodlevu veškerých interakcí v průběhu celého životního cyklu stránky. Interaction to Next Paint je podobně jako právě FID metrikou interaktivity. Stránka se vám načte a vykreslí, vy můžete provádět interakce z myši, z dotykové obrazovky nebo z klávesnice, ale stránka nereaguje. Hlavní příčinou bývá samozřejmě JavaScript. Metriky jako INP a FID se snaží tyto nepříjemnosti v uživatelském prožitku změřit a tím nám umožnit je odstranit. Odezva vpravo je dobrá, protože indikátor načítání se zobrazí okamžitě po vstupu uživatele, který chce zobrazit obrázek. Autoři z Googlu v případě INP namísto pojmu „interaktivita“ používají pojem „responsiveness“, tedy víceméně schopnost rychle reagovat. Zjednodušeně řečeno je INP metrikou rychlosti odezvy. Ukazuje na to i samotný název. Interaction to Next Paint by se dalo přeložit jako „od interakce do dalšího vykreslení“. Překládat do češtiny se tento název bude špatně, a ani já o to tentokrát nebudu usilovat. Nicméně – v původním názvu se přesně odráží fungování tohoto nového ukazatele. Co INP měří a jak se liší od FID? Metriku First Input Delay už dlouho považuji za nevyhovující. Problém s odezvou u webů, které jsou plné reklam nebo špatně postavené na moderních frontendových frameworcích, zde máme dlouhodobě. Ale FID to ani u těchto webů neukazuje. Důvody, proč FID nevyhovuje, jsou tři: Měří jen prodlevu při první interakci, nikoliv celou dobu pobytu uživatele na stránce. Neměří celou prodlevu, ale jen její první část. FID je málo přísné, podle dat Googlu metriku splňuje 95 % webů. Asi nikoho nepřekvapím, když napíšu, že INP toto všechno řeší: 1) Měří se celou dobu pobytu na stránce INP měří odezvu všech interakcí až do změny URL a vybere tu nejhorší odezvu se všech interakcí. Pokud je interakcí více než 50 , vybírají se percentily, nejčastěji to bude 98. percentil. Měřením po celou dobu pobytu na URL se řeší velká slepota metriky FID, protože podle propočtů Googlu zhruba 90 % interakcí probíhá až po úvodním načtení stránky. INP si tak můžete připodobnit k metrice Cumulative Layout Shift , která se také měří po celou dobu pobytu na stránce. 2) Počítá se celá prodleva FID měří jen první část prodlevy reakce – než reakce probublá do JavaScriptu, který ji musí zpracovat. Vůbec se ale nepočítá s dobou zpracování v samotném JS kódu, která může být opravdu dlouhá a nepočítá se s dobou vykreslení. Odhadem FID změří jen třetinu a poloviny reálného zpoždění po akci uživatele. Metrika INP a tři části, kde může nastat průšvih Na schématu vidíme tři části možného zpoždění interakce: Zpoždění vstupu – to, co nyní měří FID. Zpracování vstupu – události, ale hlavně zpracování JS. Zpoždění prezentace – většinou bývá v pohodě, mohou ale pokazit špatné CSS animace atd. Už z tohoto je jasné, že weby, které dříve v pohodě procházely přes metriku FID, teď projít nemohou. A opravdu, troufnu si tvrdit, že INP bude pro spoustu provozovatelů webů docela postrachem. 3) Větší část webů přes INP neprojde Jak jsem psal, FID splní 95 % webů. Google deklaruje, že u INP to má spočteno zhruba na dvě třetiny splňujících webů. Od doby, co je možné INP změřit, namátkou kontroluji hodnoty metriky pro weby klientů PageSpeed.cz i neklientů, u kterých bych osobně tipoval, že budou mít problémy. No a co myslíte? Skoro vždycky to tam je. :) Hodnoty metriky INP a jak je změřit? Interaction to Next Paint má, stejně jako jiné Web Vitals, od výroby nastavené třístupňové hodnoty, kdy stránka vyhovuje více či méně: Projděme to ještě slovně: Hodnota INP nižší nebo rovna 200 milisekundám = stránka má dobrou odezvu interakcí. INP nad 200 ms a pod 500 ms nebo na této hodnotě = odezva interakcí vyžaduje zlepšení. INP nad 500 ms = stránka má špatnou odezvu interakcí. Měření INP Hodnoty nové metriky odezvy interakcí můžete pro své weby získat už teď, protože Google ji už nějakou dobu pro uživatele Chrome sbírá v rámci svého Chrome UX Reportu a poskytuje ve svých měřících nástrojích. Podobně jako u CLS nebo FID bude složitější ji naměřit pomocí syntetických měření typu Lighthouse, protože metrika se sbírá až na základě uživatelských akcí. Ale je zde světlo na konci tunelu, totiž nové režimy fungování právě u nástroje s majákem ve znaku. Takže jak novou metriku změřit? Data od uživatelů vašeho webu získáte například z PageSpeed Insights: pagespeed.web.dev. Můžete použít knihovnu web-vitals nebo extension Web Vitals . V Lighthouse je možné INP změřit v novém režimu Time Span . Optimalizace INP Asi byste ode mě rádi dostali rovnou návod, jak tuto metriku snadno optimalizovat. Ale bohužel, tak jednoduché to nebude. Z praxe pro klienty vím, že obecné rady u jakékoliv metriky málokdy zafungují, vždy je potřeba analyzovat konkrétní web a konkrétní stránky. U této metriky to bude ještě složitější. Samozřejmě vás ale zkusím alespoň trochu navést. Zaměřte se na TBT Metriky jako FID nebo nově INP jsou velmi citlivé na takzvané long tasks v JavaScriptu. Pokud má totiž prohlížeč práci s dlouhým zpracováním JS kódu, nemůže reagovat na vstupy od uživatele. Zaměřit byste se tedy měli na optimalizaci metriky TBT , kterou jde změřit snadno všemi možnými nástroji. Podle údajů Googlu koreluje TBT dvakrát lépe s INP než s FID, což je dobrá zpráva, protože optimalizace FID byla často docela peklíčko. Obecná rada? Optimalizujte JavaScript Obecně samozřejmě pomáhá mít ve stránce co nejméně JS, který něco provádí: odstraňovat nevyužitý kód, správně bundlovat, odkládat stahování a spouštění kódu, který v daném uživatelském kontextu není potřeba. Dávat pozor na třetí strany. Důležitá v případě INP může být také volba JS frameworku. Např. weby běžící na Next.js na mobilu splňují metriku jen z 20 %. Lidé z Googlu sice deklarují, že s autory těchto knihoven budou pracovat na zlepšení, ale tipuji, že některé autory webů běžících na těchto frameworcích čekají zajímavé časy. Co s tím teď? Pokud vám můžu poradit, zatím si INP pro své weby změřte hlavně změřte. Jestliže vám vyjdou velmi špatná čísla a chcete-li do budoucna Web Vitals splňovat a hlavně mít rychlý web, pak raději začněte připravovat plán na nápravu . Z mé zkušenosti je totiž právě optimalizace JavaScriptu jedna z nejsložitějších a nejdéle se táhnoucích prací na rychlosti webu. Pokud INP splňujete, nezbývá než vám gratulovat. Ale i tak pozor – jde o novou, zatím experimentální metriku, která se ale může časem měnit, takže vám doporučuji sledovat její vývoj. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
