31.05.2023 04:30 V pozvánce na WebExpo 2023 jsme soutěžili o jednu vstupenku a jednu knížku. Dopadlo to dobře, výherce už známe: Jakub Machač vyhrál vstupenku na WebExpo. Michaela Havlíková vyhrává knížku CSS: moderní layout. Soutěžících jsem se ptal, co je na webařině baví. A protože mě přišly zajímavé odpovědi, s jejich svolením některé z nich publikuji zde, na Vzhůru dolů. Antonín Zejda napsal: Nejvíc mě k webu táhne paradoxně to, co ještě neexistuje. Technologie a neomezené možnosti, které nám technologie nabízejí. Daniel Beránek napsal: Ačkoli teda nemám s webařinou velké zkušenosti, tak mě moc baví to, že zde mohu uplatnit svoji kreativitu. Žil jsem v klišé, že aby někdo mohl být ajťák, musí to být brutální analytická mašina s matematickým myšlením. Tento stereotyp se mi pomale daří odbourávat a více pronikám do IT světa. Lýdie Hemalová napsala: Testování webových aplikací je občas výzva. Na webu se dá řešit tolik zajímavých věcí od přístupnosti po performance. Proto mým nejoblíbenějším nástrojem jsou DevTools, kde stále objevuji nové a nové funkce. Andra Nistor napsala: Baví mě, když se můžu podílet na vývoji aplikací, které uživatelům pomáhají při jejich každodenní práci tím, že jim ulehčuji činnost . Michaela Havlíková napsala: Mám ráda pocit, že dokážu vytvořit něco, co je užitečné a mohu vidět výsledky své práce takřka okamžitě. Jakub Machač napsal: Nejvíc mě baví že s pár základními nástroji je člověk schopen udělat téměř cokoliv ho napadne. A navíc se na téhle cestě se dá objevovat a zdokonalovat do nekonečna. Hezké, že? A co na webařině baví vás? Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
31.05.2023 04:30 INP je nová metrika rychlosti webu, se kterou přichází Google v rámci své sady Core Web Vitals. V březnu 2024 má nahradit dnes už 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ší. Poznámky k nadcházející výměně FID za INP Lidé z Googlu oznámili, že metrika INP nahradí FID v Core Web Vitals už v březnu 2024. Prodlevy způsobené JavaScriptem budou více vidět. A pro některé vývojáře to může znamenat docela bolehlav. INP je totiž daleko přísnější. Například Tim Kadlec změřil, že z webů postavených na Reactu vyhovuje této metrice jen 17 %. Weby postavené na Next.js jsou na 12 % úspěšnosti. Tim Kadlec doslova píše, že INP bude pro javascriptové vývojáře „tvrdým budíčkem“. A já s ním souhlasím. Vzal jsem 100 nejnavštěvovanějších českých e-shopů z naší studie o rychlosti webů českých e-shopů. Je to mazec. Na mobilu jich novou metriku rychlosti reakce INP splňuje pouhých 17. To jsou důvody, proč mě oznámení o tom, že INP bude už za méně než rok metrikou Core Web Vitals, překvapilo. Google sice v rámci projektu Aurora pomáhá autorům javascriptových frameworků mimojiné s optimalizací INP, ale to je jen malá část problému. Velký balvan bude ležet na ramenou vývojářů konkrétních webů a já vím, že optimalizovat JavaScript pro ně nebude snadné. Pojďme si teď něco povědět o samotné metrice Interaction to Next Paint. 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 a probíhající dlouhotrvající úlohy , které zablokují vykreslovací vlákno prohlížeče. 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 na uživatelské interakce. 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 na interakce u webů, které jsou plné reklam nebo špatně postavené na moderních frontendových frameworcích, zde máme dlouhodobě. Ale FID žádné problémy ani u těchto webů neukazuje. Důvody, proč metrika FID už z dnešního pohledu 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 , nevybere se nejhorší hodnota, ale percentil, nejčastěji 98. 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á. Dále se nepočítá s dobou vykreslení. FID změří odhadem jen třetinu až polovinu 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. 3) Větší část webů přes INP neprojde Jak jsem psal, FID splní 93 % webů. Google deklaruje, že u INP to má spočteno zhruba na dvě třetiny splňujících webů. 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ě: V tabulce to pak vypadá následovně: Metrika Dobrá Vyžaduje zlepšení Špatná INP ≤ 200 ms 200 - 500 ms > 500 ms 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. Nová verze rozšíření Web Vitals umí změřit prodlevy jednotlivých interakcí uživatele. 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. Více o optimalizaci INP najdete jako vždy v materiálech přímo od Googlu 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. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
27.05.2023 01:00 Meta značka „viewport“ se používá hlavně pro mobily v responzivním designu. Slouží k tomu, aby mobily nepoužily výchozí viewport, optimalizovaný pro ne-responzivní weby, ale své přirozené rozlišení. Stačí uvést následující kus kódu do hlavičky HTML dokumentu: Toto HTML přesně řečeno nastaví šířku layoutového viewportu na velikost rozlišení v CSS pixelech. V mobilech se tedy stane to, co vidíte na obrázku: Z desktopového rozlišení se stane mobilní. Stačilo upravit viewport. Bez použití meta značky se totiž web vykreslí do výchozího layoutového viewportu, který má většinou šířku 980 pixelů. Web bude vypadat „jako na počítači, jen zmenšený“. Tohle by vám obvykle mohlo stačit. Dále pokračujte jen pokud jste hodně zvědaví, nebo pokročilí. Parametry meta značky pro viewport Do atributu content je možné dávat různé vlastnosti a jejich hodnoty. width Vlastnost width nastaví šířku layoutového viewportu. Nejčastěji využívaná hodnota device-width, což je 100vw neboli 100 % šířky viewportu. Sjednotí se tak šířka layoutového viewportu se šířkou ideálního viewportu, viz text o viewportech. Uživatel tak nebude muset zoomovat a vaši responzivní stránku uvidí jedna ku jedné. Pokud použijete hodnotu, např. width=400, nastavíte šířku layoutového viewportu na 400 pixelů. Nenapadá mě ale moc rozumných důvodů, proč to dělat. Snad jen v případě, že se vaši designéři zbláznili a navrhují pro jedno konkrétní rozlišení. Nedoporučuji to. Existuje samozřejmě i podobný atribut height, který nastavuje výšku layoutového viewportu. initial-scale Vlastnost initial-scale nastaví výchozí zoom, ale také šířku layoutového viewportu. Ve výsledku dělá zápis initial-scale=1 totéž jako width=device-width. Pokud chcete maximální kompatibilitu, uvádějte oba dva. Bez initial-scale=1 totiž některé prohlížeče renderují stránku do rozlišení, jako by bylo otočené na výšku, i když jej používáme na šířku. user-scalable Vlastnost user-scalable určuje, zda uživatel může zoomovat. Hodnota no zakazuje uživateli jakkoliv zoomovat. Prosím, nepoužívejte ji. Zoomování je na mobilních zařízení fakt potřeba. Ať už jde o zvětšení textu v horších světelných podmínkách, nebo jen touhu vidět detaily z nějakého obrázku, přibližování obsahu prostě potřebují všichni uživatelé. Safari na iOS 10 a novějších navíc zákaz zoomování úplně ignoruje. Pokud si však přejete, aby Safari nezoomovalo v textových polích , které mají menší velikost písma než 16px, pak je možné použít vlastnost user-scalable=no. Možnost zoomování celé stránky ale uživateli zůstane. minimum-scale/maximum-scale Vlastnosti minimum-scale a maximum-scale určují minimální a maximální možný zoom. maximum-scale=1 ruší možnost přiblížení stejně jako user-scalable=no. Opět naléhám – prosím, nepoužívejte to. interactive-widget Prostřednictvím vlastnosti interactive-widget můžete prohlížeči sdělit, jaké chování si přejete při otevření widgetu, což je většinou virtuální klávesnice. Možné hodnota pro interactive-widget jsou: resizes-visual – Změní velikost pouze vizuálního viewportu, ale ne layoutového viewportu. resizes-content – Změní velikost obou viewportů. overlays-content: Nezmění velikost žádného viewportu. Platí to od Chrome 108 na Androidu. Více je v článku Prepare for viewport resize behavior changes coming to Chrome on Android. shrink-to-fit Vlastnost shrink-to-fit už není relevantní. Na starší verzích iOS bylo problematické umístění prvků částečně mimo viewport , na zařízeních s iOS se vizuální viewport přepočítá tak, aby se zobrazil i onen pozicovaný element. Dnes už je toto chování standardní a není potřeba používat shrink-to-fit. Viz v textu Scotta O'Hary: scottohara.me/blog/2018/12/11/shrink-to-fit.html viewport-fit Relativně nová vlastnost, která řeší způsob zobrazování na zařízeních s jinou než hranatou obrazovkou. Jako příklad vezměme chytré hodinky nebo iPhone X a novější. Vlastnost může mít následující hodnoty : auto – výchozí stav, který vše nechává na prohlížeči. U iPhone X a novějších to například odpovídá hodnotě contain. contain – zmenší viewport pro stránku tak, aby byla vidět celá. Jakou barvu vykreslí po stranách, záleží na prohlížeči. U nových iPhonů je to background-color z body. cover – roztáhne viewport pro stránku tak, aby nikde „nevyčuhovaly“ neobarvené části rozhraní prohlížeče. S tím rizikem, že kulaté rohy nebo výčnělky na displeji zařízení některé části stránky překryjí. Pokud má stránka různobarevné pozadí, jako je to u Vzhůru dolů, hodí se do meta značky přidat viewport-fit=cover Více o tom píšu v článku o iPhone X. Stručné řešení pro vaše weby: Pro layout s jednobarevným pozadím si jen zkontrolujte nastavení background-color na body. Pro weby s různobarevnými prvky zabírajícími celou šířku si přidejte parametr do meta značky pro viewport: Tipy, triky, zajímavosti Meta viewport raději moc nenastavujte Javascriptem Hodí se to, jen když nemáte přístup do . Teoreticky jde Javascriptem meta značka pro viewport i měnit, ale nedělejte to. Je to náročné na překreslování stránky. Vyrobte raději normální responzivní web s jedním meta tagem pro viewport. Odstranění prodlevy mezi tapnutím a akcí trvající 300 ms Když budete mít viewport nastavený správně, s hodnotou width, aktuální prohlížeče postavené na jádrech WebKit a Blink samy odstraní prodlevu mezi tapnutím a akcí. Starší prohlížeče totiž po tapnutí prstem čekaly, zda nepřidáte prst druhý a nemáte tedy v úmyslu stránku zvětšovat. Toto už dnes ale také, pokud vím, není platné. Zavináčové pravidlo @viewport v CSS Instrukce pro způsob zobrazování by se měla dávat do CSS, že ano? S logičtěji umístěným zápisem @viewport přišlo W3C, ale moderní prohlížeče jej zatím nezvládají. Výjimkou byl Internet Explorer 11 a Edge, kde je to bylo potřeba zapnout. Teď už to to tedy podle mě k ničemu není. Psal jsem o tom ve starším článku. Weby na WatchOS – pokud máte web optimalizovaný pro viewporty menší než 320px Chytré hodinky od Applu vynucují zobrazení našich webových dílek na zápěstí uživatelů ve viewportu širokém 320 CSS pixelů. Pokud bychom tomu chtěli zabránit a zobrazit je ve výchozím CSS rozlišení , musíme si dupnout následujícím kódem: Vtipné je, že WatchOS ve výchozím režimu vynucují přepočítaný viewport uvnitř přepočítaného viewportu. Ale co už – my léta víme, že viewporty na mobilních zařízeních jsou jako teorie relativity: Víme, že existují, víme že jsou složité, ale skoro nikdo jim nerozumí. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.05.2023 07:15 Už po osmé vás na Vzhůru dolů zvu na každoroční konferenci WebExpo, sraz lidí z oblastí webového designu, vývoje a digitálního marketingu. WebExpo 2023 proběhne netypicky už 19. a 20. dubna, ale na typickém místě, v centru Prahy. Konferenci Šárky Štrossové a jejího týmu mám rád hlavně pro skvělé možnosti potkávání s kolegy a kolegyněmi. Velmi rád si sem také chodím rozšířit obzory mimo své hlavní zaměření . Vybral jsem pro vás několik přednášek, které mě v programu zaujaly, nebo si myslím, že by je čtenáři Vzhůru dolů neměli propást. Z frontendových luhů a hájů Futuristic UI: How to make users feel like they’re in a sci-fi movie, protože Filip Hráček, kterého znáte z podcastu. Authentication UX, protože Vitaly Friedman inspiruje, i když mluví o něčem, co zrovna nepotřebujete. Extending HTML with Web Components, protože mě zajímá, kdy už budou konečně Web Components široce použitelné. You might not need css-in-js, protože si myslím, že některé důvody pro CSS-in-JS už opravdu neplatí. Tak schválně…! Why local-first software fixes everything, protože sice nevěřím, ale i tak si moc rád Dana Steigerwalda poslechnu. More than words: Designing and building voice interfaces, protože ovládání hlasem bude s nástupem AI lidem ještě blíž. Supercharge your skills with creative coding, protože ano, v současném webdesignu je kreativita na ústupu a je to škoda. How to make and share more flexible UI components, protože po letech zase trochu více přemýšlím nad UI a design systémy mě znovu více zajímají. Shape Up Development Process, protože Honzovi Korbelovi věřím, že už pak nebudu muset číst knihu, na kterou se už léta chystám. Rychlost webu Harry Roberts jezdí na WebExpo často a rád. Jeho přednášky jsou vždy plné pokročilejších tipů, proto nevynechám jeho talk Optimising Largest Contentful Paint. Velmi doporučuji i Harryho páteční workshop. Letos dorazí i hvězdný Scott Jehl z WebpageTestu a bude povídat na téma Experimenting with performance at the edge. Z oblasti rychlosti ale toho na WebExpu můžete slyšet a vidět více – například microservices, Livesport News nebo invalidaci více keší od stejné firmy. Stopa Vzhůru dolů Po loňském podílnictví na tvorbě programu a krátké keynote mám letos více času a prostoru a tak se vám v přednášce Shift happens: Dealing with Cumulative Layout Shift během 20 minut pokusím předat návod na pochopení metriky CLS a tipy na její optimalizaci. Robin Pokorný bude diskutovat v bloku How to Become a Staff+ Engineer . Riki Fridrich vás ve Write testable code naučí psát lepší kód. Soutěž o vstupenku a knížku pro juniorní vývojáře Od organizátorů jsem dostal vstupenku navíc a rád bych ji věnoval někomu, kdo ji opravdu ocení. Pojďme si proto zasoutěžit o jednu vstupenku a jednu knížku s e-bookem, jako cenu útěchy. Podmínky jsou tyto: Soutěž je určená pro juniorní vývojářky a vývojáře, kteří v oboru nepracují více než 3 roky. Do komentáře pod článkem nebo do e-mailu martin@vzhurudolu.cz pošlete odkaz na váš LinkedIn profil a odpovězte na otázku: „Co vás na webařině nejvíc baví?” Z odpovědí vylosuji dva lidi, jeden dostane knížku a druhý vstupenku na WebExpo. Uzávěrka soutěže je v neděli 26. 3. 2022 o půlnoci. Pro vás ostatní tady od WebExpa mám slevičku: Hodně štěstí a na viděnou na WebExpu!
16.05.2023 01:30 V březnovém vydání podcastu se můžete těšit na vám už velmi dobře známého Rikiho Fridricha . Zabýváme se JavaScriptem a aktuálním stavu navazujícího ekosystému. Zdrojem inspirace byla tradičně anketa State of JS 2023, ale tentokrát jsme se podívali daleko nad její rámec. Přibývají do samotného jazyka jen irelevantní věci a děje se to podstatné právě v ekosystému? Podcast V diskuzi se objevila otázka, zda se do jazyka JavaScript přidávají jen irelevantní věci, a zda by měl mít lepší standardní knihovnu. Dalším tématem bylo převládající používání TypeScriptu a jeho výhody oproti nativnímu JavaScriptu, včetně diskuse o novinkách v TypeScriptu 5 a moduleResolution Bundleru. Kenn C. Dotts začal psát ukázky kódu ve vzdělávacích materiálech v TypeScriptu, namísto čistého JavaScriptu, a vyvolalo to velké kontroverze. Diskutovali jsme také se o JS frameworcích a odklonu od SPA v rámci „renderovacích” frameworků. Zazněla i otázka, zda je vůbec budoucnost backendu v JavaScriptu. Museli jsme probrat také tooling kolem JS, jako je například balíčkovací nástroj Vite a Turbopack. Host Riki Fridrich píše JavaScript ve firmě Outreach. Učí ostatní, jak psát Javascript. Přednáší na konferencích a setkáních. Většinou o Javascriptu. Riki je z Ládví. Web – Twitter – Github – LinkedIn O čem mluvíme? Robinův tip: Kniha The Staff Engineer’s Path Martinův tip: Firefox 110 a plná podpora Container Queries Představení Rikiho Fridricha z Ládví Anketa State of CSS JavaScript jako jazyk: přidávají se tam jen irelevantní věci? Chybí v JavaScriptu lepší standardní knihovna? TypeScript vyhrál a typování v nativním JavaScriptu TypeScript 5 a moduleResolution Bundler Nejčastěji adaptované vlastnosti JS jako top level Await WebSpeech API a používaní prohlížeče k mluvení Kenn C. Dotts a všechny ukázky v TypeScriptu JS frameworky a „renderovací” frameworky, odklon od SPA Budoucnost backendu není v JS? Nástup nových JS enginů Tooling kolem JS a balíčkovací nástroj Vite, plus Turbopack Video: Diskuze o hlasovém ovládání počítače Děkujeme za spolupráci: Honza Michálek . Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Líbil se vám tento díl? Prosíme vás o zhodnocení podcastu na vaší oblíbené platformě. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo do komentářů.
14.05.2023 16:15 Vítejte u 44. epizody podcastu ze Vzhůru dolů! Natočili jsme ji tak, aby vám byla průvodcem po záznamech přednášek z letošního WebExpa. Ano, záznamy už jsou veřejně a zdarma dostupné. Co se nám líbilo? Samozřejmě kromě networkingu, setkávání a parties… Podcast O čem se bavíme? Robin, Martin a WebExpo: historie jednoho vztahu Local First od Daniela Steigerwalda AI: „Shift Happens“ a prompty pro copywritery od Vladany Bačové Robinův nový podcast o Engineering Leadership Voice Interfaces, zvukové značky a přednáška Leonie Watson Nepřednášková část WebExpa, ta nejlepší Pozvánka na WebExpo 2024 Bonus: To nejlepší z WebExpa 2023 Top 3 přednášky Vladana Bačová: AI text generators – are they a threat or benefit for content writers? – pokud jste copík je to must, pokud vývojář, nudit se nebudete. Léonie Watson: More than words: Designing and building voice interfaces – překvapivé možnosti CSS, které ale zatím prohlížeče nepodporují. Harry Roberts: Optimising Largest Contentful Paint – vše o metrice LCP. Pokud řešíte rychlost, Harryho asi asi už stejně žerete. Co mě dále zaujalo a kde jsem byl duchem alespoň chvíli přítomen? Filip Hráček: Futuristic UI – moc pěkné a v nejlepším smyslu slova inspirativní. Dmitry Belyaev: You might not need css-in-js – Dmitrij pokryl sice jen malou část problematiky z názvu, ale velmi dobře JS vývojářům přiblížil výhody Custom Properties v CSS. Daniel Steigerwald: local-first software – aplikace Apple se výborně synchronizují nejspíš právě proto, že jsou local first. Architektura client-server je špatná z pohledu DX, i proto je local-first zajímavý směr. Ondřej Čermák: How to make sure your system doesn’t blow – škálování i performance nemusí vždy pomoci. Základ je dobře měřit. Přesně tak! Je super, že to občas řekne i někdo jiný než já. Jhey Tompkins: Supercharge your skills with creative coding – zajímavé ukázky kreativních rozhraní s HTML a CSS. Jen strašně, ale strašně malinké písmo v ukázkách kódu. Server-Side: The newest website tracking concept: Pavel Šabatka - pěkně podané argument proč zvážit serverové GTM, jak to zhruba udělat a co to stojí. Je to jednodušší než jsem si myslel. Rowdy Rabouw: Extending HTML with Web Components – výborně podaný tutoriál, jak začít namísto komponent JS frameworků používat nativní Web Components. Pořád ale nevím, proč to vývojáři nepoužívají více. Scott Jehl: Experimenting with performance at the edge – po dlouhém obecném úvodu Scott ukázal Experiments ve WebpageTestu, které vám umožňují otestovat vliv změny kódu na rychlost přímo na produkčním webu. To je velmi zajímavé. Když už v tom budete, pusťte si i moji přednášku Shift happens: Dealing with Cumulative Layout Shift . Je prý bezva, říkali lidi. Ahoj za rok na WebExpu 2024! Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Nápad? Chyba? Připomínka? Pochvala? Pište nám na e-mail podcast@vzhurudolu.cz nebo do komentářů.
06.05.2023 12:15 To, co Media Queries dělají pro celou stránku, my většinou potřebujeme jen pro její část, pro konkrétní komponentu. A právě to nám snad brzy poskytnou Container Queries. Media Queries, tedy dotazy na média , poskytují metodu dotazování na parametry zařízení, ve kterém se zobrazuje celý dokument. S jejich pomocí se ptáme na rozměry zobrazení v okně prohlížeče nebo uživatelské preference. Container Queries, dotazy na kontejner , umožňují testovat parametry jednotlivých prvků v dokumentu. S jejich pomocí se ptáme na rozměry nebo vypočtené styly. Container Queries cílí jen na konkrétní část stránky. Říkáte „hurá“? My taky. Skeptik by se mě na tomto místě zeptal, jaký to má háček. Ano, mělo to háček. Ale už nemá. Container Queries nepodporoval Firefox, což se od února 2023 a verze 110 změnilo. Container Queries jsme odjakživa chtěli a mysleli si, že je nikdy nedostaneme V roce 2017 se této technologii říkalo „Element Queries“, což dávalo smysl. Šlo o dotazy na rozměrové parametry konkrétního prvku stránky, konkrétního elementu. Lidé přemýšleli, jak tuto technologii dostat do prohlížečů, a já k tomu napsal: Je to věc, kterou ve webdesignu opravdu hodně chci. A věřte mi, že vy taky. Pořád si to myslím, ale tehdy to tak jednoduché nebylo: Zatím je Element Queries možné jen emulovat javascriptovými knihovnami. A bohužel není jisté, že se standardu, natož nějaké nativní implementace v dohledné době dočkáme. Proč to tehdy vypadalo, že tahle technologie se do prohlížečů nedostane? Lidé ze standardizační organizace W3C tehdy nad Container Queries přemýšleli a zdálo se jim, že je to špatně implementovatelné v prohlížečích. Pak debata na mnoho let utichla a zůstalo jen u javascriptových knihoven, které problém sice vyřešit uměly, ale z pohledu rychlosti vykreslení nikdy nebyly hodné doporučení. Pokud by vás to jako exkurze do minulosti zajímalo, zde je ten můj článek: vrdl.in/eq. Ale zpět k současnosti. Jen odbočím. Máte raději video? Podívejte se na moji přednášku „Container Queries: krátká přednáška o velké věci“. YouTube: youtu.be/vXaeIlXLCUY Implementace Container Queries z roku 2020 S novým návrhem přišla v prosinci 2020 Miriam Suzanne. Její příspěvek ale byl jen jakýmsi vrcholem pyramidy postaveným na letité práci mnoha dalších. Tento návrh se skládá ze dvou kroků. První je definování kontejneru, což se v aktuální verzi specifikace udělá takto: .container Hodnota inline-size říká, že půjde o kontejner s rozvržením na řádkové ose, tedy v případě evropských jazyků vodorovně. Filozofie zápisu inline vychází z takzvaných logických hodnot a proměnných v CSS. Celé Container Queries pak staví na takzvaném „containmentu“ v CSS. To je způsob jak během vykreslování stránky izolovat její část od zbytku. Prohlížeči pak stačí počítat s překreslováním malé části stránky. Druhý krok je samotný dotaz na kontejner, tedy Container Query: @container Tohle je asi zřejmé. Pokud bude šířka rodičovského prvku alespoň 30em , aplikují se pravidla uvnitř. A teď už prakticky, na příkladech. Příklad: naše komponenta v Container Queries Pojďme si to poskládat dohromady na konkrétním příkladu „Media Objectu“. Jde to velmi často používanou komponentu s obrázkem a textem. HTML: David franků… CSS: .container @container .item-image .item-text } Rodičovskému prvku nejprve nastavíme kontejner pro šířku . V dotazu @container pak máme dotaz na šířku prvku .container. Zde už řešení netrpí problémy, které by způsobovaly Media Queries. Při nastavování hodnoty bodu zlomu se můžeme soustředit na samotný obsah. Ne na celou stránku nebo na vnější či vnitřní okraje kolem komponenty. Prostě se zaměříme jen na danou komponentu a podmínky připravíme přímo pro ni. Příklad: více komponent v jedné stránce Ještě více Container Queries oceníme v případě, že layout stránky obsahuje více stejných komponent vedle sebe. Já: „Mám dvě komponenty vedle sebe a chci nastavovat breakpointy podle jejich obsahu.“ Media Queries: „Ufff!“ Container Queries: „Podrž mi to pivo…“ Zde bychom už byli bez Container Queries namydlení. První možností řešení by bylo složitě nastavovat Media Queries pro různé případy výskytu komponenty ve stránce. Další možností, která by se nabízela, by bylo obejít se úplně bez dotazů. To ale nechceme. V druhém demu jsou naše dvě komponenty vloženy vedle sebe pomocí následujícího layoutu. HTML: CSS: .page Pomocí display:grid, vlastnosti grid-template-columns a gap definujeme dvousloupcovou mřížku s mezerou mezi sloupci o šířce 1em. Příklad: pojmenované kontejnery Rozšiřme nyní předchozí demo se dvěma kontejnery pro jednu komponentu. Nová podmínka je, že první i druhý kontejner budou mít trošku jiný layout. Konkrétně chceme, aby se rozvržení zalomilo na jiném bodu zlomu. Svoje kontejnery si pojmenujeme dvěma třídami, první bude container--one a druhá container--two: Jméno kontejneru můžeme definovat buď pomocí vlastnosti container-name nebo pomocí zkratky container: .container--one .container--two Zápisem container:layout-one/inline-size říkáme: Vytvářím kontejner pojmenovaný layout-one, který je definovaný jako měnící šířku . Nyní mohu přímo v Container Queries definovat různé podmínky pro oba prvky. Mohl jsem změnit rozvržení, ale vystačil jsem si se změnou bodu zlomu: @container layout-one @container layout-two Upravil jsem zde ještě jednu věc. V dotazu jsem namísto tradičního použil . Dělá to to samé, ale je to obecnější a pro někoho možná i matematicky elegantnější zápis. Nejlépe si to opět vyzkoušejte na živé verzi kódu. Referenční příručka k vlastnostem Přesuňme se nyní od konkrétních příkladů k vlastnostem, se kterými se pojí specifikace Container Queries. Vlastnost container-type Vlastnost container-type definuje prvek jako kontejner do dotazy Container Queries. Hodnota Co dělá? size Zřizuje kontejner pro dotazy na velikost po obou osách . inline-size Zakládá kontejner pro dotazy na velikost po inline ose kontejneru. normal Prvek není kontejnerem pro dotazy na velikost kontejneru. Zajímavé na hodnotě normal je, že se prvku sice nemůžete dotazovat na velikost, ale zůstává kontejnerem pro dotazy na styl. To obstarávají takzvané Style Queries. Jednou o nich něco napíšu, jsou velmi zajímavé, ale zatím nemají podporu v prohlížečích. Ve výchozím nastavení jsou všechny prvky kontejnerem pro účely Style Queries. Kontejnery pro Style Queries lze přetvořit v kontejnery pro Container Queries zadáním typu kontejneru pomocí vlastnosti container-type . Vlastnost container-name Pomocí container-name určíme seznam názvů kontejnerů. Ty mohou být použity pravidly @container k filtrování, na které kontejnery se mají zaměřit. Hodnota Co dělá? none Kontejner nemá žádné jméno. Kontejner má jméno . Zkratka container Zkratka container definuje hodnoty pro container-name i container-type. .container .container-2 V případě uvedení jen jedné hodnoty se počítá s container-name: .container Vlastnost container-type pak má výchozí hodnotu normal. Pravidlo @container Pravidlo @container uvozuje Container Query. Máme několik možností, jak Container Query definovat. Nejprve jednoduše: @container my-component Dále také kombinací více podmínek, ve kterých je možné používat logické operátory and, or nebo not: @container my-component and Vlastnosti, na které je možné se dotazovat, jsou následující: Šířka: width. Výška: height. Řádková velikost: inline-size. Velikost bloku: block-size. Poměr stran: aspect-ratio. Orientace: orientation. Styly: funkce style . V jednom dotazu na kontejner sice nelze zadat dotaz na více pojmenovaných kontejnerů, ale lze toho dosáhnout vnořením více dotazů: @container my-component } Dobře, ale jak je to tedy s podporou v prohlížečích a praktickou využitelností Container Queries? Podpora v prohlížečích Na Container Queries se těším jako malý Jarda, a tak po očku vývoj už léta sleduji. Od zkušební implementace v Chrome v roce 2021 uběhl nějaký čas, během kterého autoři rychle reagovali na měnící se specifikaci. Od Chrome verze 106 je podpora dotazů na kontejner v nejrozšířenějším prohlížeči úplně plnohodnotná. A co další prohlížeče? Safari se v poslední době probralo a plná implementace Container Queries dorazila už v září 2022, konkrétně do verze 16.0. vrdl.in/cqsaf Edge od Microsoftu je na tom s podporou aktuálně stejně jako Chrome. Od října 2022 to je bezva. Klíčenku posíláme do Redmondu. Firefox Container Queries podporuje od února 2023 a verze 110. Viz také CanIUse.com. Možná náhradní řešení Řekněme, že v cílové skupině máte hodně uživatelů starších prohlížečů bez podpory Container Queries. Znamená to, že v takové chvíli tuto skvělou věc použít ještě nemůžete? Záleží na situaci, ale je nutné si i zde zopakovat základní mantru webových technologií. Pomocí postupného vylepšování bude možné dodat lepší řešení podporujícím prohlížečům a to horší těm nepodporujícím. Ale přemýšlejme i nad možností, že bychom postupné vylepšení nezvolili. Například v případě nepodpory ze strany starších verzí Safari by naše komponenta vypadala následovně. Prohlížeč, který neumí Container Queries: „Klid. Nějak to zobrazím.“ Na mobilu nemusí vadit, že podmínku @container prohlížeč neumí. Tam layout často nepotřebujeme. Na větších obrazovkách dostane uživatel jiný vzhled komponenty. Vadí to? Nemusí. Osobně bych přemýšlel, jak moc odlišný uživatelský prožitek zde lidé dostávají a kolika z nich se to dotkne. Rozhodování, zda se vám vyplatí dělat náhradní řešení nebo zda vůbec Container Queries použít, je už na vás, milí čtenáři. Polyfill neurazí Samozřejmě se i pro Container Queries se objevily polyfilly, čili javascriptové emulace dané vlastnosti. Za běžných okolností bych vás z důvodu pomalé rychlosti takových řešení od využívání odrazoval. Jenže v tomto případě jde o rozchození vlastnosti ve starších prohlížečích, jen pro pár procent uživatelů. Zase tak strašně moc proti tomu tedy protestovat nebudu. Obzvlášť v případech, kdy jej použijete pro obsah mimo první zobrazenou obrazovku. vrdl.in/cqpol Něco pro alternativce: krkavčí technika Pro pořádek ještě zmíním, že existují pokusy dosáhnout funkce Container Queries za pomoci přiohnutí už existujících vlastností. Vezměme například „The Raven Technique“ popsanou Mathiasem Hülsbuschem na CSS-Tricks v roce 2020. Její výhodou je podpora ve všech moderních prohlížečích. Na závěr ještě přidávám odkaz na aktuální verzi specifikace „CSS Containment Module Level 3“. vrdl.in/46rac Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
02.05.2023 08:45 Sotva jsme na svět praktického CSS přivítali výborné Container Queries, přichází další novinka. CSS Style Queries umožňují ptát se v na vypočtené hodnoty CSS vlastností a podle toho změnit styl elementu. Podobně jako Container Queries, Style Queries jsou v současné době ve fázi návrhu a ještě není jasné, jak se bude jejich implementace a podpora v prohlížečích vyvíjet. Container i Style Queries vycházejí ze specifikace CSS Containment Module Level 3, která je ovšem v definici Style Queries zatím trochu skoupá. Někdy stačí jenom se zeptat. Style Queries nám snad už brzy odpoví. Jisté je, že jednu část dotazů na styl právě teď implementovali autoři Chrome. Proto o téhle novince také píšu. Příklad Zkusme si to popsat na možná ne úplně praktickém, ale o to více jednoduchém příkladu: .box @container style } Výsledkem je, že element s třídou .box bude mít šedou barvu pozadí. Ale to jen v případě, že je vlastnost font-weight nastavena na tučné, tedy bold. Co byste o Style Queries měli vědět? V úvodním odstavci jsem zmiňoval vypočtené hodnoty CSS vlastnosti. To je důležité a taky odlišné od Container nebo Media Queries: Dotazem @container se ptáte na vykreslovanou velikost. Dotazem @container style se ptáte na vypočtenou hodnotu. Není to to samé, protože do vypočtené hodnoty promítá také dědičnost nebo další vlastnosti kaskády v CSS, což činí Style Queries ještě zajímavějšími. Syntaxe a logika kombinování prvků do dotazu na styl je stejná jako u dotazů na podporu vlastností CSS, viz @supports. Dále platí, že Style Queries teoreticky vznikají při základním typu containmentu v CSS, takže nebudete muset definovat container-type, jako to děláte u Container Queries. Podpora a aktuální implementace v Chrome O možné podpoře ze strany Firefoxu a Safari se mi nic moc zjistit nepodařilo. Šance na brzkou implementaci není malá, protože prohlížeče se snaží domlouvat a tedy lze předpokládat, že i dotazy na styly patří do dohodnotých priorit. V době psaní tohoto textu lidé z Googlu oznámili, že Style Queries přistanou do Chrome 111. Dobrou zprávou je, že implementaci uvidíme rovnou v produkčním prohlížeči, nikoliv jen Canary verzi. Horší zprávou je, že implementace se zaměřuje jen na určitou část Style Queries, a to dotazy na hodnoty autorských vlastností neboli proměnných. Příklad s autorskými vlastnostmi Toto je jediná ukázka, která mi aktuálně v prohlížeči funguje. Řekněme, že se snažím o stylování boxů podle hodnoty custom property --theme. Řekněme, že to dělám tímto způsobem právě proto, že bych rád využil dědičnosti v CSS a autorskou vlastnost --theme chci měnit na různých místech kódu. HTML vypadá takto: Lorem ipsum… Lorem ipsum… Důležitá část CSS je pak tahle: @container style } Omluvte jednoduchost ukázky, snažím se tady totiž hlavně ukázat, jak to funguje. A že to funguje. Stačí si otevřít aktuální Chrome Canary nebo běžný Chrome od verze 111. K čemu to může být dobré? Nestačí pro tyhle účely prostě přidat třídu a je to? Ano, někdy by to šlo vyřešit třídou, ale znovu připomínám, že trik je v dotazu na vypočtenou hodnotu vlastnosti. A ta může být změněná v rámci CSS kaskády libovolným způsobem. Další příklady a další zdroje Tenhle text berte jako úvodní výkop. V jeho dalších iteracích to popíšu podrobněji, ale raději si počkám na další rozvoj specifikace a podpory v prohlížečích. Jsme prostě zase na začátku a asi bychom měli být spíše opatrní. Pro inspiraci přidávám asi nejzajímavější text o Style Queries od Uny Kravets. Jsou tam velmi zajímavé ukázky praktického využití dotazů na styl: Přenos nedědičných vlastností na potomka. Seskupování vlastností pro určitý stav do jednoho místa. Interaktivní změna vzhledu pomocí Style Queries. Kombinování více dotazů na styl. Myslím, že Style Queries budou dalším střípkem do mozaiky snadnějších řešení některých specifických situací. Těším se na další vývoj. Co vy? Napište mi svůj názor do komentářů. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
