31.01.2023 21:30 Dark mode je mezi uživateli, ale i ve webařské komunitě velmi populární. Hodí se na weby, kde uživatelé čtou nebo prostě tráví více času. V textu ukazuji svou cestu k tmavému režimu na Vzhůru dolů a sdílím některé nečekané zkušenosti. Dark mode na Vzhůru dolů. Pěkné to je, ale člověk se zapotí. Hlavní překvapení? Automatizovat to jde jen velmi málo. Proč mít dark mode? Tmavý režim se v poslední době stal velmi populárním, protože jej většina uživatelů miluje. Jsou zde ale i racionální důvody: Ušetří baterii na mobilního telefonu, hlavně u OLED/AMOLED displejů. Nevyzařuje tolik modré složky světla, která může ovlivnit spánek. Šetří baterii displeje, protože se výrazně snižuje jeho jas. Pomáhá lidem se zvýšenou citlivostí např. světloplachostí a přecitlivělostí na světlo. A navíc: je to cool. Jak na webu udělat tmavý režim? U webů je to dnes velmi jednoduché. Podpora v prohlížečích a v operačních systémech je prakticky stoprocentní. Dotaz prefers-color-scheme Prohlížečů se můžeme na preferenci uživatele snadno zeptat v CSS použitím dotazu na vlastnost média prefers-color-scheme: @media V JavaScriptu se dotážeme pomocí vlastnosti MediaQueryList.matches: window.matchMedia ").matches V JavaScriptu je samozřejmě možné rozchodit i ruční přepínání mezi světlým a tmavým režimem, které řada webů zavedla. Píše se o tom na JeČas.cz. U Vzhůru dolů se tmavý režim zapne automaticky, po přepnutí na úrovni systému. CSS proměnné Pro nastavení barev se velmi hodí použít CSS proměnné . Nejprve v CSS definujeme základní variantu barev: :root Následně tyto barvy upravíme pro tmavý režim: @media } Velmi se tudíž hodí mít alespoň základní barevné schéma uložené v autorských vlastnostech . O výhodách autorských vlastností pro tvorbu dark mode dobře psal Adam Kudrna. Ladění v prohlížečích V prohlížečích můžete mezi režimy barev přepínat pomocí vývojářských nástrojů. V Chrome DevTools to je v sekci Rendering. Ve vývojářských nástrojích Firefoxu k tomu slouží tlačítko Toggle Dark Mode. V Inspectoru Safari to dle mého nastavit nejde, ale zase je v systému macOS velmi snadné přepnout do tmavého režimu. Pojďme se podívat, jak přemýšlet o samotné tvorbě barev. Tvorba barev pro dark mode Když jsem na tmavém režimu začal pracovat, poněkud naivně jsem se domníval, že vezmu stávající barvy uložené v SCSS proměnných, proženu je nějakým automatickým převodníkem do tmavého režimu a mám hotovo. Ne, takhle jednoduché to nebylo. Méně barev je více kodérovy radosti První problém byl v množství barev, které jsem na Vzhůru dolů používal. Do mého barevného schématu bylo potřeba opravdu hodně říznout. Tohle je současné barevné schéma ukládané do autorských vlastností, které obsahuje zhruba polovinu původních barev: :root ; --vd-text-color: rgb ); --vd-text-color-lighter: rgba , 0.8); --vd-text-color-lightest: rgba , 0.5); --vd-background-color: # ; --vd-content-bg-color: # ; --vd-border-color: rgba ); --vd-border-color-light: rgba , 0.5); --vd-highlight-bg-color: # ; --vd-highlight-neutral-bg-color: # ; --vd-link-color: # ; --vd-heading-color: # ; --vd-code-color: # ; --vd-code-color-1: # ; --vd-code-color-2: # ; --vd-code-color-3: # ; --vd-code-color-4: # ; --vd-bg-hover: rgba , 0.1); --vd-box-bg-color: # ; --vd-interactive-bg-color: # ; --vd-badge-color: # ; } @media ; --vd-background-color: # ; --vd-content-bg-color: # ; --vd-highlight-bg-color: # ; --vd-highlight-neutral-bg-color: # ; --vd-heading-color: # ; --vd-code-color: # ; --vd-code-color-1: # ; --vd-code-color-2: # ; --vd-code-color-3: # ; --vd-code-color-4: # ; --vd-box-bg-color: # ; --vd-interactive-bg-color: # ; --vd-badge-color: # ; } } Všimněte si, že některé barvy přebírám z SCSS proměnných, jiné se tvoří automaticky, například pomocí barevného schématu rgba . Aktuální počet používaných barev je oproti původnímu stavu výrazně menší. Web je teď barevně o něco jednodušší a snad i přehlednější a kontrastnější. Automatika nefunguje Druhý problém jsem si uvědomil záhy. Barvy není možné jen automaticky převést na světelné složky. Tvorba barev pro dark mode do určité míry odpovídá tvorbě zcela nového barevného schématu, které by pak mělo mít stejný „feeling“ jako původní schéma. O barvách toho zase tolik nevím, takže je možné, že se mi to zase tak nepovedlo. Ale věřím, že to není úplně špatné. Pokud jste na tom podobně, velmi doporučuji nastudovat pár zdrojů o tvorbě barevného schématu: Jak tvořit systematické barvy pro digitální produkty Funkce barev v designu 6 Simple Tips On Using Color In Your Design HSL barvy, planá naděje Pro automatické počítání tmavého režimu se jako možnost nejčastěji uvádí HSL barvy. Ty jsou vyjádřeny v modelu, kde je barva definována třemi hodnotami: Hue je úhel v kruhu barev. Hodnoty jsou v rozmezí 0–360°. Saturation je procentuální hodnota, která určuje jak moc je barva sytá. Hodnoty jsou v rozmezí 0–100%. Lightness je procentuální hodnota, která určuje jak světlá je barva. Hodnoty jsou v rozmezí 0–100%. Může se zdát, že stačí převést barvy světlého schématu do HSL… :root …a pak je automaticky překlopit do tmavého režimu tak, že invertujeme světlost: :root Vypadá to pak tak jako na obrázku: HSL by mohlo bylo super. Ale není to super. Pro některá jednodušší barevná schémata to může fungovat. Já to častečně použil například pro barev u ukázek kódu Jinde to je nepoužitelné, protože barvy vypadají špatně. Najednou máte pocitově jiné schéma než původní. Problém je totiž v tom, že HSL barvy nejsou optimalizované pro světlost vnímanou lidským okem a některé z nich prostě oku svítí více než jiné. Více o tom píše Jiří Chlebus odkazovaný výše nebo Lea Verou. V CodePenu můžete vidět, jak by to vypadalo u základních barev používaných na Vzhůru dolů: Ano, vidíte dobře. Vypadalo by to blbě. RGBa barvy Automatiky je možné občas dosáhnout i pomocí RGBa barvy. RGBa barva je vyjádřená v modelu RGB, ale s průhledností. Pokud s průhledností pracujete, můžete si do proměnné uložit právě jen RGB složku barvy: :root @media } V kódu pak uvádíte jen proměnnou a průhlednost, barva se vám mění podle použitého barevného schématu: .text Více najde v textu Theming with CSS variables in RGBA od Bence Szabo. Vyzkoušet si to můžete v mé ukázce, pokud si v prohlížeči nastavíte dark mode: V CodePenu je také vidět, že jsem se pokoušel prohlížeči barvu vnutit jako HEXa hodnotu, se kterými se mi pracuje lépe. A taky je vidět, jak jsem neuspěl. Učinil jsem také pár experimentů se osmimístným hexa zápisem, který by poloprůhlednost měl podporovat také: .text Podpora v prohlížečích už nějakou dobu je. caniuse.com/css-rrggbbaa Ale výsledek byl opět totožný se sedláky u Chlumce. Na osmimístné HEXa si prostě s autorskými vlastnostmi nepřijdete a pro dark mode zatím nejsou použitelné, viz Stack Overflow. LAB barvy, budoucí naděje Pojďme se ale od HSL přesunout k zajímavějšímu barevnému modelu – LAB. Jak můžete vidět na následujícím obrázku, zatímco u HSL je světlost vnímaná jinak, u LAB působí na naše oči podobně. Barvy LAB a dark mode. LAB je barevný model více stavěný pro lidské oko. V CSS je k dispozici jako LCH barvy. Podpora zatím není plná, ale dobrá zpráva je, že Safari už tyto barvy podporuje a Chrome se přidá ve verzi 111, takže za pár týdnů. caniuse.com/css-lch-lab Ke konverzi barev z HSL do LCH můžete použít tento nástroj. Automatický převod není vše, bez citu to nepůjde Pokud to dosud nebylo jasné, ještě to jednou akcentuji: ačkoliv kodérská čast mojí osoby by nejradši vytvářela barvy pro dark mode automaticky, realita je jinde. Musí se zde zapojit i designer nebo designerská část osobnosti. Vytvoření barev pro dark mode vyžaduje cit a znalost barev. Automatika jako HSL, LCH nebo třeba RGBa je použitelná jen v některých případech. Obrázky a logotypy Další, opět trošku nečekaný zásek, na mě číhal v případě obrázků a logotypů. Všechna tato média dosud koncipuji pro velmi světlé pozadí, ideálně bílé, a přepnutím do tmavé verze najednou začaly vypadat dost špatně. Na obrázku vidíte několik možných variant jak zobrazovat logotyp na tmavém pozadí: Logotypy v dark mode. Jednotlivé varianty z obrázku si vysvětleme: Základní verze logotypu pro světlé pozadí. Varianta logotypu pro tmavé pozadí, dle logomanuálu. Základní verze na tmavém pozadí s okraji. Jednobarevné negativní provedení logotypu. Pokud těch logotypů na webu máte hodně a zrovna tvoříte tmavý režim webu, můžete inklinovat k jednoduché variantě 3 – prostě ke stávajícím logům přidat světlé okraje. Nevypadá to ale dobře. Logotypy pak uživateli svítí do očí. Ideální je držet se varianty podle logomanuálu, takže varianty 2. Může se vám ale stát, že značka logomanuál nemá nebo je plnobarevná negativní verze pro vás nevhodná. Je možné převod logotypů do tmavého pozadí automatizovat? Ano, do určité míry to jde. Jednobarevné negativní logogypy Vezměte stávající logotyp a s pomocí CSS je upravte pro tmavé pozadí. Možnosti jsou zhruba tyto: Převod do odstínů šedi: filter:grayscale . Nemusí to ale odpovídat povoleným variantám logotypu. Odstranit bílé pozadí pomocí mix-blend-mode:multiply. Viz CodePen Ondřeje Konečného. Převést na inverzní barvy: filter:invert viz David Walsh. Jen pozor, u většiny logotypů toto změní barvy, což není ideální. Maximalizovat jas: filter:brightness . Všechny barvy v logotypu se stanou bílými. Víceméně to pak odpovídá variantě 4 podle obrázku. Toto je varianta, kterou jsem pro některé logotypy skutečně použil. Responzivní SVG je ideál Pokud máte logotypy v SVG, což doufám máte, úplně ideální varianta je samozřejmě podpora tmavého režimu přímo v SVG souboru. Jak jistě víte, SVG může být responzivní, takže podporuje i dotaz prefers-color-scheme: path @media } Tak a je to hotové. Tmavý režim je na webu: Připravte se na to, že dark mode obnáší více práce než jste očekávali. Ale myslím, že to stojí za to. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
29.01.2023 03:00 Node, Deno, Bun…? S Borkem se vám v těch serverových javascriptových věcech pokoušíme dělat pořádek. Sobě taky. Svět javascriptových runtimů běžících nikoliv v prohlížeči, ale také na serveru, se nám v posledních měsících rozrostl o Bun, který bude soupeřit s již existujícími Node.JS a Deno. V podcastu se mimojiné dozvíte, proč by Borek nejnovější Bun zatím nepoužil, ale proč jej stejně fascinuje, hlavně z pohledu rychlosti. Podcast MP3 ke stažení. Host: Borek Bernard Borek je aktuálně CTO v Shoptetu, ale také člověk, který k naší velké radosti sleduje a veřejně komentuje dění na scéně webových technologií. Z dřívějška jej můžete znát jako zakladatele Versionpressu a historicky také například jako autora knihy o Adobe Flex. Borka najdete mimojiné na LinkedIn nebo Twitteru. O čem mluvíme? Robinův tip: Heroku zdarma končí Martinův tip: Jak WP Optimize podvádí v testech rychlosti Borek Bernard - představení O čem si budeme povídat a proč to bude JS na serveru a proč je to klíčové pro frontendový tooling? Prapůvod: prohlížečové JS runtime Jak jsme se dostali k JS na serveru? Začátky Node.js Node.js - v čem byl jeho příchod revoluční Node.js - proč může být dnes vnímaný jako dinosaurus Odbočka k NPM a Yarn Deno.js, rok 2018, a čeho Ryan Dahl litoval na Node.js Bun, „projekt šíleného vědce” Jarreda Sumnera Bun a sázka na rychlost Bun - co dělá jinak? Shrnutí: proč Borek zatím Bun nepoužije, ale Deno a Node.js rozhodně Odbočka ke Cloudflare Workers Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Pište nám na e-mail podcast@vzhurudolu.cz.
27.01.2023 18:16 Živě s publikem jsme se v kancelářích společnosti Productboard zaměřili na to, co nás zaujalo v roce 2022. Budeme reagovat na výsledky ankety State of CSS 2022, kde se objevily Cascade Layers, selektor :has a další novinky, a kde framework Tailwind dále posiluje pozice. Vítězové ankety State Of CSS 2022: Flexbox gap, CSS Modules, Subgrid a prohlížeč Arc. Dále odhadujeme trendy pro rok 2023. Robin doporučuje sledovat technologie pro tvorbu Local First aplikací, CSS nesting a Conditional Rules. Martin zase připomíná WebP obrázky, staronovou BFcache a funkce pro předběžné vykreslení stránky v Chrome. V dotazech z publika padla témata jako Edge First a Web 3, na které jsme se rovněž pokusili reagovat. Podcast Video O čem mluvíme? State of CSS 2022. Zajímavé, ale ne až tak překvapivé. Zaměření ankety na výkon. Viz náš komentář k loňské anketě. Stává se Firefox novým MSIE? Container Queries. Největší darda přelomu roku. Parent selektor :has. Konečně, ale proč až teď? Cascade Layers, vrstvy. Jsou super, ale revoluce se nekoná. Obliba Talwindu stále roste, teď už ale dokonce v anketě klesá Bootstrap. Rok 2023: Specifikace CSS nesting. Oslabí to CSS preprocesory? Conditional Rules Module Local First Plná podpora WebP obrázků BFcache nově v Chrome Prerender v Chrome nově a jinak Designový trend GlassMorphism Diskuze: Edge First Diskuze: Web3 Odebírejte podcast ze Vzhůru dolů Spotify – iTunes – Google Podcasty – TuneIn – Anchor – RSS podcastů. Jsme také na e-mailu podcast@vzhurudolu.cz.
25.01.2023 01:00 Kaskádové vrstvy jsou novinka, která webařům umožňuje měnit platnost deklarací bez nutnosti uvádět je na konkrétní místo v CSS souboru a v konkrétním pořadí. Obecně vzato, CSS Cascade Layers poskytují strukturovaný způsob uspořádání stylů. Slouží tak ke zjednodušení práce s kaskádou v CSS a hlavně specificitou selektorů. Dejme si jednoduchý příklad: @layer framework @layer override @layer framework } Vývojářky a vývojáři mohou díky pravidlu @layer vytvářet vrstvy pro reprezentaci výchozích nastavení prvků, knihoven třetích stran, motivů vzhledu nebo komponent. Není přitom nutné přizpůsobovat tomu selektory v rámci jednotlivých vrstev nebo se spoléhat na pořadí zdrojů při řešení konfliktů. Zároveň nám kaskádové vrstvy poskytují možnost přeskupovat pořadí platnosti deklarací: @layer base, framework, override; @layer framework @layer base Podpora této části specifikace CSS Cascade Layers ve všech moderních prohlížečích je plná. To hlavně díky tomu, že prohlížeče aktuálně velmi dobře spolupracují. V textu vám ukážu několik příkladů, jak to pro vás může být užitečné. Nejprve vám ale zkusím vysvětlit, proč si myslím, že kaskádové vrstvy jsou skoro až revolučně užitečné. Věčný boj s kaskádou Už od vzniku CSS před více než více než čtvrt stoletím se uživatelé CSS dělí do dvou skupin. Související „Problémy“ CSS Kaskáda a specificita Dědičnost v CSS Kaskádové vrstvy Selektory v CSS Pseudotřídy v CSS Menší skupina , která CSS miluje i se všemi nedostatky. Ve druhé skupině sedí drtivá většina běžných vývojářů, kteří CSS používají, protože nemají jinou možnost. Kaskádové styly tyto vývojáře více či méně štvou a principy návrhu CSS obvykle nechápou. Dělicí linkou mezi těmito skupinami je často chápání kaskády v CSS a jejich vlastností – dědičnosti, důležitosti a hlavně specificity selektorů. Myslím, že příchod kaskádových vrstev je dobrá zpráva pro tu první skupinu. A skvělá zpráva pro tu druhou. Obvyklý vývoj a hlavně úpravy CSS probíhají v první skupině vývojářek a vývojářů podle metodik, z nichž je pro tyto účely nejdůležitější ITCSS. V druhé skupině se často prostě přidávají deklarace na konec souboru a doufá se, že to pomůže: #content .btn .btn .btn Poznáváte svůj kód? Jenže klíčové slovo !important a důležitost v CSS je určena pro jiné účely, a tudíž tohle je trošku prasárna. No, možná i více než trošku… Řešení s kaskádovými vrstvami je jednoduché. Prostě si jednotlivé části CSS izolujeme do relativně nezávislých vrstev: @layer base } @layer override } Ano, je to přesně tak, kaskáda platí jen uvnitř konkrétních kaskádových vrstev. Rozhoduje jen pořadí vrstev, tak, jak jsou uvedené v CSS nebo jak jej specifikujete na začátku CSS souboru pomocí pravidla @layer. Jeden původ, jeden origin Je dobré akcentovat, že kaskádové vrstvy organizují styly v rámci jednoho původu . V CSS jich může být více – prohlížečové styly, autorské styly , uživatelské styly. Tzn. pomocí @layer nelze například z autorských stylů „vstoupit“ do prohlížečového originu. Příklad s Bootstrapem: bez vrstev V dalším textu vám Cascade Layers představím krok za krokem pomocí jednoduchého příkladu s přestylováním Bootstrapu. Začneme příkladem bez vrstev. Framework nejprve importujeme, pak přestylujeme: @import url ; body .btn Na první pohled nám to přestylování takto půjde dobře. V prohlížeči dostaneme, co jsme chtěli, tedy přebarvené a tlačítko: Problém však nastává při najetí myši na tlačítko . Barva nezůstává taková, jakou jsme nastavili. Důvodem je vyšší specificita původního selektoru: .btn:hover .btn Původní selektor s vyšší specificitou tedy vyhrává a naše změna barvy se neaplikuje. Co s tím? Jak už jsem psal, můžeme to přetížit selektorem stejné nebo vyšší specificity. Můžeme přidat důležitost pomocí !important. Nebo jinak a lépe – můžeme použít kaskádové vrstvy. Příklad s Bootstrapem: vrstvy vrství V další ukázce už jsem použil Cascade Layers a trošku zkomplikoval ty přebíjené vlastnosti: @import url layer ; @layer my-styles } @layer my-base .btn } Jak je vidět, kromě změny barvy pozadí ještě obarvuji rámečky tlačítek na červeno. Najednou to celé funguje. Výše uvedené problémy nevidíme. Specificita selektorů Bootstrapu nás už netrápí, protože se aplikuje jen uvnitř vrstev. Příklad s Bootstrapem: změna pořadí vrstev Můžeme to celé ještě vylepšit. Pravidlo @layer totiž využíváme buď pro vložení deklarací do vrstvy nebo deklaraci pořadí vrstev. To druhé vypadá takto: @layer bootstrap, my-base, my-styles; Deklaraci zbylého kódu necháme v původním pořadí, ale vzhled stránky se změní. Tlačítka nebudou mít červenou barvu rámečku, protože vrstva my-base je přepsaná vrstvou my-styles. Prostě lusknete prsty a všechny bolehlavy s nutností dodržovat pořadí v kódu a hlídat specificitu jsou pryč. Vrstvy vrství a já se raduju. Dávám lajk. Proč vrstvy neexistovaly už před patnácti lety…?! Odbočka k !important Než budeme pokračovat, je potřeba udělat odbočku k další části kaskády. Tou je důležitost pravidel a klíčové slovo !important. Důležitost totiž kromě zvýšení váhy konkrétní deklarace také obrátí pořadí priority. To je velmi důležité. Stejně to funguje také u kaskádových vrstev. Deklarace, kde použijete !important, budou měnit pořadí. Příklad s Bootstrapem: použijeme !important Do našeho příkladu s frameworkem Bootstrap nyní přidáme důležitost: @layer bootstrap, my-base, my-styles; @import url layer ; @layer my-styles } @layer my-base .btn } Vzhledem k pořadí deklarace kódu byste mohli čekat, že tlačítka budou šedivá , ale ony jsou hnědá . Důvodem je obrácené skládání vrstev v případě použití !important. Deklarace z vrstvy my-base prostě dostane přednost, protože je níže než vrstva my-styles. Abych to ještě doplnil o poslední dílek skládačky, v pořadí hrají roli i deklarace neuvedené ve vrstvách: Nejníže deklarace z jednotlivých vrstev podle pořadí, které jste jim nastavili. Uprostřed jsou deklarace nezařazené do vrstev. Nejvýše pak platí deklarace s !important, ovšem v opačném pořadí než jsou uvedené vrstvy. Je to docela galimatyáš, že? Ale má to dobré důvody. Nejlépe to uvidíte na obrázku: Když už nemůžeš, vrstvi víc. Když už nemůžeš vrstvit, přidej důležitost. Připravil jsem k tomuto ještě tři CodePeny. Jsou o praktickém využití nebo spíše trablech přebíjení !important, které nám nadělil Bootstrap. V kódu frameworku najdete tyto řádky: Nechme teď stranou důvody, proč bychom to měli chtít přebíjet ve svém kódu. Řekněme, že opravdu moc chceme. V takovém případě nám ovšem vložení pravidla pro přebití do vrstev nepomůže . Musíme přebíjející pravidlo ponechat mimo vrstvy . Alternativně pak můžeme vrstvy použít, ale vložit přebíjející pravidlo ještě pod styly Bootstrapu: @import my-styles, bootstrap; @import url layer ; @layer my-styles } Vnořování vrstev Alespoň stručně ještě zmíním možnost vnořování vrstev, který rozebírají na skvělém MDN: @layer framework } Podpora v prohlížečích Prohlížeče jsou na tom skvěle, díky za optání. Chrome podporuje @layer od verze 99, Safari od verze 15.4 a Firefox od verze 97. Ke dni psaní tohoto textu, což je listopad 2022, je tedy podpora dostupná ve všech moderních prohlížečích. Více je jako vždy na caniuse.com/css-cascade-layers. Závěr Vrstvy jsou skvělý nástroj, který nám umožní vytvářet kaskádové styly, které budou přehlednější a také snadněji udržovatelné. Jsou navržené tak, aby mohly způsobit revoluci v organizaci CSS. Zároveň je možné je použít tak, aby se vůbec nezměnila naše běžná práce. Taky je možné, že se běžná práce kodérů vůbec nezmění a @layer se stane něčím, co se používá jen ve výjimečných případech. Rozdíly mezi teorií a praxí jsou totiž v oblasti organizace CSS velmi časté. Tak či tak – mám z přítomnosti vrstev v CSS velkou radost a věřím, že vám pomohou, stejně tak jako vám doufám pomohl i tento článek. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
22.01.2023 07:15 Vlastností contain označujeme části stránky, které jsou izolované od zbytku. Izolujeme je proto, aby prohlížeč nemusel při změnách překreslovat celou stránku. Ušetříme tím výkon na stránkách s komplexním DOMem. Prohlížeče se už dlouho různými způsoby snaží nepřepočítávat vzhled celé stránky při každé změně samy. Kromě toho existují kodérské triky, jak to udělat v běžném CSS . No a relativně novou možností je použít pro tyhle účely vlastnost contain. → Celá problematika „CSS Containmentu“ je nejzajímavější ve vlastnosti content-visibility, ale silně se využívá také v Container Queries. Dva příklady Vlastnost contain může ušetřit čas potřebný pro vykreslování hlavně v případech, kdy DOM obsahuje tisíce uzlů. Následující příklady proto berte jako schématické a hodně zjednodušené. Přidání prvku do DOMu Tuhle ukázku jsem převzal z dokumentace od Googlu. Máme následující HTML: Home About A teď JavaScriptem přidáme nový prvek: Home About Check me out! Přidání nového prvku spouští rovnou tři kroky procesu překreslování – styl, layout a paint. Blbé ovšem je, že se ten proces spouští pro celý DOM a celou stránku. Může pak pomoci přidání vlastnosti contain. Ilustrační obrázek: Čas potřebný pro fázi layout můžeme snížit díky omezení na konkrétní boxík menšímu počtu prvku k přepočítání. Zdroj developers.google.com. Podívejme se ještě na jednu ukázku. Výpis článků mimo viditelnou část obrazovky Vezměme, že na stránce máme stovky či tisíce položek typu články, produkty nebo třeba tweety. Většinu z nich uživatelé neuvidí v prvním vykresleném viewportu. Zároveň jde o samostatné a izolované prvky, které se se zbytkem stránky nijak vzájemně neovlivňují. Takhle může vypadat jejich výpis ve stránce: Articles … … Představme si, že prvků jsou zde stovky a zároveň mají složitou vnitřní DOM strukturu. Pomocí vlastnosti contain můžeme prohlížeč informovat, ať tyto prvky vyjme z celkového vykreslování stránky: article Prohlížeči tak dáváme instrukci, že prvky .element, které „nevidí“ ve viewportu může v klidu vynechat z počítání vzhledu celé stránky. Ušetříme tím v některých situacích slušný renderovací čas. Typy „containmentu“ Zatím se mi nepovedlo najít vhodné české slovíčko pro teorii, o které se ve specifikaci mluví jako o „CSS containmentu“. Jde o soběstačné a nezávislé zapouzdření prvku, což je ale poněkud kostrbaté označení. Známe čtyři typy zapouzdření, které jsou zároveň možné hodnoty vlastnosti contain: Hodnota contain Typ zapouzdření size Zapouzdření pro velikost. Prohlížeči říkám, že velikost prvku nijak neovlivní jeho potomci. Pokud nastavíme contain:size, je potřeba v CSS také tomuto prvku nastavit nějakou velikost. Jinak prohlížeč počítá, že velikost je nulová, což nechceme. Zapouzdření velikosti samo o sobě zase tak moc výkonu při renderování neušetří. inline-size Zapouzdření pro „inline“ velikost. Totéž jako size jen pro změny velikosti na vodorovné ose. layout Zapouzdření pro rozvržení. Říkáme tím, že se layout potomků prvku a zbytku stránky nijak vzájemně neovlivňují. Díky tomu může při zápise contain:layout prohlížeč vynechat počítání layoutu vnitřních prvků elementu a zaměřit se jen na prvek, který tuto vlastnost má nastavenou. paint Zapouzdření pro vykreslení. Informujeme tímto, že žádný vnitřní prvek nevyčnívá ze svého rodiče. Uvedení contain:paint prohlížeči umožňuje potenciálně přeskočit vykreslení potomků, pokud je prvek mimo obrazovku. style Zapouzdření pro styly. Říkáme, že ovlivněný prvek vyjímáme z počítání hodnot napříč dokumentem, které provádějí vlastnosti jako counter-increment, counter-set nebo quotes. Hodnoty vlastnosti contain jde kombinovat, takže můžete například uvést contain: style paint. Speciální hodnoty Za účelem zjednodušení problematiky pro nás, autory webů, přichází specifikace se speciálními hodnotami vlastnosti contain: Hodnota contain Typ zapouzdření strict Všechny typy zapouzdření, kromě stylů. Totéž jako zápis contain: size layout paint. content Všechny typy zapouzdření, kromě stylů a velikosti. Totéž jako contain: layout paint. Hodnota strict ušetří prohlížeči více času, ale zase musíme znát a definovat velikost prvku. Jak to použít v praxi? Pojďme se zde vrátit k druhé ukázce – renderování desítek či stovek článků mimo viditelnou část obrazovky: Pokud bychom použili contain:content, nemusíme definovat výšku jednotlivých bloků. Na druhou stranu bude prohlížeč při prvním vykreslení považovat výšku za nulovou a nevykreslí například správně velká rolovátka. Pokud bychom použili contain:strict, prohlížeči musíme výšku sdělit, ale zase nenastane přepočítání velikosti rolovátka. Vlastnost contain vytváří nové kontexty Pokud containment použijete s hodnotami paint, strict nebo content vytvoří se nové kontexty, které je možné dělat i jinými metodami v CSS: Nový obsahující blok – pro potomky, jejichž vlastnost position je absolute nebo fixed, takže něco jako position:relative. Nový kontext stohování , ve kterém můžete nezávisle na zbytku stránky umísťovat prvky do vrstev pomocí z-index. Nový kontext formátování bloku , který například umí obsáhnout vnitřní prvky umístěné pomocí float nebo zakáže spojování vnějších okrajů . Využít containment, konkrétně například contain:content, tedy můžete i v případě, že nechcete šetři výkon, ale usnadnit si kodérskou práci. Podpora je plná Vlastnost contain nepodporuje Internet Explorer, což vůbec nevadí. Všechny moderní prohlížeče v containmentu jedou s námi. Viz také CanIUse.com/mdn-css_properties_contain Odkazy Pokud vás problematika containmentu zajímá více, zde je pár tipů k dalšímu studiu: Vlastnost content-visibility, která z containmentu vychází. MDN: CSS Containment, vlastnost contain. Smashing Magazine: Helping Browsers Optimize With The CSS Contain Property Za připomínky autor děkuje Michalovi Matuškovi. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
04.01.2023 10:45 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á to háček. Ale jen malinký. Container Queries zatím nepodporuje Firefox, ale brzy s tím začne – odhadem v únoru 2023. 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. I v nejméně rozšířeném prohlížeči, ve Firefoxu, se podpora připravuje. Dorazí do Firefoxu 108, což je v době psaní už příští verze. Těšit se můžeme už v lednu nebo únoru 2023. Aktuálně můžete Container Queries zkoušet ve verzi Nightly. Jako vždy platí – sledujte CanIUse.com. Možná náhradní řešení Aktuálně tedy čekáme na podporu ze strany Firefoxu. 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 Safari by naše komponenta v tomto prohlížeči 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 Firefoxu, prohlížeči, který využívá 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: .
03.01.2023 02:00 Půl roku od vydání se má kniha „CSS: moderní layout“ čile k světu. Dostávám na ni výborné ohlasy a e-book nebo tištěnou verzi si koupily už stovky z vás. Jak je u mě zvykem, přišel čas na aktualizaci e-booku a vypuštění tištěné knihy do světa. Nyní se s ní, kromě Vzhůru dolů, můžete vidět také v knihkupectvích. CSS: moderní layout, verze 1.1 Jak už někteří víte, každý e-book vždy několikrát aktualizuji. Jednak proto, abych opravil chyby, ale také proto, abych přidal nový obsah. Co nového jsem připravil pro verzi 1.1? Přidal jsem hodně obsahu o Container Queries a novou podkapitolu o související vlastnosti contain. Opravil jsem několik chybek, které jste mi hlásili , a aktualizoval informace o podpoře CSS vlastností v prohlížečích, která se u zmíněných vlastností pěkně zlepšuje, protože prohlížeče spolupracují. Úplně jsem předělal proces generování formátů EPUB a MOBI, takže to teď bude svižnější při načítání v pomalejších čtečkách. Pokud e-book už máte koupený, už jste dostali zprávu o vydání nové verze s odkazem na její stažení. Pro majitele e-booků je to zadarmo. Držitelé nových licencí rovnou dostanou verzi 1.1. Knížka dorazila do knihkupectví Po prázdninách jsem dle plánu ukončil exkluzivitu prodeje tištěné knihy přes svoje Vzhůru dolů. Tištěnou knihu si teď můžete osahat, prolistovat, nebo dokonce koupit v internetových i kamenných knihkupectvích. Kosmas je hlavní zdroj a zároveň distributor knihy. Po alternativních prodejcích se porozhlédněte nejlépe na Heuréce. Chcete mi pomoci? Budu vděčný za každý váš ohlas v e-mailu nebo recenzi, ideálně na webu některého z knihkupců či na Databázi knih. Více o knize
