24.11.2021 01:46 Nástroj pro audit webu Lighthouse vyšel v deváté verzi. Musím tomu věnovat alespoň stručnou poznámku, protože přináší minimálně dvě zajímavé novinky. No a taky je to už tradice. Na Vzhůru dolů se tomuhle nástroji věnuji pravidelně. Psal jsem zápisky například k verzi 8 nebo 6. Nový Lighthouse 9 v Chrome. V devátém vydání přinesli autoři nástroje z Googlu zejména razantně předělané rozhraní výsledků testu, včetně těch na PageSpeed Insights, ale hlavně User Flows. User Flows, průchod uživatele službou Velkou nevýhodou Lighthouse byla možnost testovat jen první načtení stránky. Ano, určité výjimky existovaly – například při testování v Chrome bylo možné nastavit, zda vytvořit audit s plnou nebo prázdnou keší prohlížeče. User Flows umožňují skriptované testování. Lighthouse tak můžete pouštět v rámci jednoho testu vícekrát – ať už jde o načtení různých stránek nebo spouštění na základě interakcí na stránce. Nově tak budete moci testovat například tyto scénáře: Průchod uživatele webem – testem si nasimulujete procházení uživatele například nákupním procesem na e-shopu. Interakce uživatele se stránkou – Lighthouse nemusíte pouštět jen při úvodním načtení, ale také například po kliknutí na element nebo scrollování. Posbíráte metriky a vzniklé problémy. Fixnete to. Pustíte test znova. To se mi líbí. Dosud bylo možné skriptovat testy rychlosti například pomocí proprietárního rozhraní skriptů ve WebpageTestu. Ale přítomnost v Lighthouse je důležitá, jde o nejpoužívanější nástroj pro testování webů. Navíc to zde udělali pomocí už poměrně standardizovaného API pro ovládání Chrome zvaného Puppeteer. Autoři Chrome nyní ve verzi Canary testují možnost si uživatelský proces naklikat pomocí nástroje Recorder. I tohle vypadá zajímavě. Hlavně pro ty, kteří raději klikají než píší javascriptový kód. Nové rozhraní výsledku testu Další velkou změnou je vylepšené rozhraní výsledků testu. Ukažme si to na příkladu testu oblasti Performance pro úvodní stránku Vzhůru dolů: Lighthouse User Flows. Můžete tady vidět hned několik novinek: Celkové skóre je trochu menší a vedle je nově screenshot hotové stránky. To abyste lépe viděli. Viděli, jak vypadala stránka při dokončení testu. To se hodí, protože Lighthouse často testuje web ve stavu, v jakém jej vy nevidíte – například s cookie lištou. Jednotlivé metriky, ze kterých se skládá celkové skóre , jsou nyní větší. I to hodnotím kladně – zaměří to pozornost lidí na správné místo, tedy nikoliv LPS, ale konkrétní ukazatele, které je potřeba optimalizovat. V každém testu, včetně toho na PageSpeed Insights, je nyní lépe vidět nastavení testu - na jakém zařízení a odkud proběhl. To je důležité pro pochopení rozdílů mezi Lighthouse testy, které mohou být i dost velké. Všechny novinky se rovnou projevily také v PageSpeed Insights, asi nejpopulárnějším nástroji pro jednorázový test rychlosti webu. Nově je najdete na adrese: pagespeed.web.dev PageSpeed Insights dávají nově také větší důraz na metriky od uživatelů z Chrome UX Reportu. To je bezpochyby chvályhodné, protože to je nejlepší způsob, jak se zdarma k číslům o rychlosti dostat. Na druhou stranu – metriky posbírané od uživatelů jsou k dispozici jen pro více navštěvované weby, takže nové pojetí výsledků bude řadu lidí mást. V oblasti „web performance”, rychlosti webu, jsou laici obecně dost v pasti mezi srozumitelností podávaných informací a jejich přesností. Ale to je na jiné povídání a jiný článek. Výsledky testů z Lighthouse 9 už také uvidíte v našem testeru rychlosti na PageSpeed.cz. Všechny novinky z Lighthouse 9 si můžete přečíst v changelogu. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 Lighthouse je velmi důležitý nástroj. Chcete vědět proč? Google jeho prostřednictvím totiž webařům radí jak weby technicky zlepšit. Je to nástroj pro analýzu technické kvality webu, která důležitá jak pro návštěvníky, tak pro umístění webu právě ve výsledích vyhledávání Googlu, například v oblasti Page Experience Obsah: Proč jej používat? Co umí analyzovat Jak jej používat Test rychlosti User Flows Příkazová řádka Pravidelné spouštění Používám jej hlavně pro analýzu rychlosti načítání, ale o webu umí podat daleko barevnější obrázek. Pokrývá přístupnost, SEO a další oblasti. Video: Lighthouse: Základní představení Jak si otestovat web v tomhle výborném nástroji. → YouTube kanál Velmi doporučuji pomocí Lighthouse testovat vaše weby a webové aplikace. A nejlépe to dělat pravidelně a automaticky. → Související novinka: V listopadu 2021 vyšel Lighthouse 9. Proč jej používat? Lighthouse vám pomůže najít problémy na úrovni designu a frontendového kódu, které nějakým způsobem škodí nebo mohou škodit přísunu uživatelů na web a jeho použitelnosti. Za výhody Lighthouse považuji především: Snadnou dostupnost komukoliv. Rychlé výstupy. Rozumné rady. Ale bavme se i o nevýhodách: Dává spíše základní přehled a bez pokročilejších nástrojů se v případě vážnějších auditů neobejdeme. Psal jsem například o nástrojích pro měření rychlosti. Výsledky auditu rychlosti webu jsou obvykle ovlivněné aktuálním výkonem počítače, na kterém jej spouštíme. Dělá jen syntetickou analýzu v jednom umělém uživatelském kontextu. Zdaleka nám tedy nedá obrázek o celé šíři problémů na naší uživatelské základně. Data o rychlosti od uživatelů nám částečně poskytne například jiný nástroj od Google – PageSpeed Insights. I s historií v čase pak tester PageSpeed.cz. Co Lighthouse umí analyzovat? Je toho hodně. Ukázkový report pro Vzhůru dolů. Vidíte celkové skóre a výsledky pro první oblast – performance neboli rychlost. Oblasti webařského pachtění, které Lighthouse pokrývá: Performance – rychlost načítání a výkon při vykreslování. Pro mě velmi důležité. Progressive Web App – jak se web drží doporučení pro progresivní webové aplikace. Best Practices – guláš osvědčených postupů mimo uvedené škatulky, například k bezpečnosti nebo upozornění na použití zastaralých technologií . Accessibility – přístupnost webu. SEO – technická připravenost webu na indexování vyhledavači. Jak jej používat? Ligthouse je balíček pro Node.js, proto způsobů jeho použití existuje fakt hodně: Chrome DevTools – stačí otevřít developerské nástroje Chrome a jít do záložky „Audits“. Online verze – web.dev/measure/. V dalších nástrojích – výstupy „majáku“ jsou dostupné z testů aplikací jako WebpageTest.org, SpeedCurve a dalších. K dispozici je seznam integrací. Příkazová řádka – právě jí vděčí za tolik možností použití: github.com/GoogleChrome/lighthouse. Test rychlosti Lighthouse se ve většině případu použití spouští na vašem počítači a dělá se jen jeden test, takže se výsledky testů mohou lišit podle momentálního vytížení. Hlavně v oblasti Performance. Test rychlosti Lighthouse v Google Chrome. V testech jsou na výběr dvě zařízení: Desktop – váš Chrome v aktuálním nastavení rozlišení, rychlosti připojení atd. Mobile – ve výchozím nastavení jde o „Emulated Nexus 5X“ se simulovaným zpomalením procesoru a rychlosti připojení, které odpovídá zhruba „3G fast“ z nastavení WebpageTest.org . Zajímavá možnost je v nastavení zpomalení – Throttling: Simulated – rychlejší test, navíc s lépe porovnatelnými výsledky. Znamená to, že se web otestuje na vašem aktuálním připojení i výkonu procesoru. Pak se čísla přepočítají, jak by asi vypadaly na slabším stroji. Tohle je myslím lepší používat. Applied – přesnější, ale pomalý test. Připojení a procesor se uměle zpomalí a pak teprve Lighthouse operuje. Jde o původní metodu. No a poslední možnost – Clear storage – před testy smaže obsah lokálních úložišť, aby Lighthouse dokázal zachytit prožitek úplně nového uživatele. Video: Lighthouse: Test rychlosti webu Na videu procházíme výstupy záložky „Performance“. → YouTube kanál User Flows, průchody uživatele službou V Lighthouse 9 autoři přidali možnost testovat nejen úvodní načtení, ale také průchod webem nebo webovou aplikací. Jmenuje se to User Flows. Lighthouse User Flows. K dispozici je to také v Chrome, koncem roku 2021 jen ve verzi Canary. Zde pod záložkou Recorder. Příkazová řádka Jak už víte, Lighthouse je možné nainstalovat na příkazovou řádku: npm install -g lighthouse Otestovat konkrétní web je pak snadné: lighthouse https://www.vzhurudolu.cz --view Tohle jen otevře Chrome nejprve pro otestování a následně pro zobrazení reportu . Další příkaz pak uloží výstupy do formátu JSON: lighthouse https://www.vzhurudolu.cz --output json --output-path vzhurudolu-report.json Související Nástroje pro analýzu rychlosti PageSpeed Insights Lighthouse Performance Score Videokurz o Lighthouse Zpracování JSONu pak je možné dělat automaticky. Toho je možné využít při pravidelném spouštění. Pravidelné spouštění Optimální varianta je samozřejmě pravidelné spouštění Ligthouse, tak abyste na auditování nemuseli myslet při nasazování nových verzí webů a aplikací. Kromě vlastního řešení postaveného na příkazové řádce tady máme několik hotových možností: Integrace do lokální automatizace – Gulpu ). Řešení pomocí CI – například pomocí Lighthouse CI. Hotové vizualizační nástroje jako SpeedCurve, Calibre, Treo a jim podobné. Shrnutí Používejte Lighthouse. Určitě! Pouštějte jej pravidelně a nejlépe automaticky. Držte se jeho doporučení, jsou velice rozumná. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 Břéťa Proft z Pipedrive s námi sdílel zkušenosti s mikrofrontendy, takže jsme opět pokryli jedno téma, které na nás vyskakovalo v předchozích epizodách. Zde očekávejte úvod do microfrontends, ale také porovnání zkušenosti Břéťovy a Robinovy firmy. Bavíme se nejen o technikáliích, ale taky o způsobu organizace firem, což je u nasazování této technologie důležitý faktor. Přejeme vám příjemný poslech. Podcast MP3 ke stažení Host: Břetislav Proft Břéťa je javascriptový vývojář v Pipedrive a organizátor pražských meetupů Frontendisti.cz. Hledejte ho na viasors.com nebo LinkedIn. O čem mluvíme? Robinův tip: Atila a jeho texty o Next.js Martinův tip: State of CSS Hlavní téma: Microfrontends a Břéťa Proft Co jsou mikrofrontendy? Historie: zalando/tailor a bigpipe Microfrontends vs microservices Organizace firmy: Spotify Tribes, Launchpad/Missions v Pipedrive a uspořádání v Klarně Proč se nepoužívají různé frameworky? Společné a samostatné části Společné CSS v mikrofrontendech, component libraries Problém různých verzí frameworků Pro koho jsou mikrofrontendy vhodné a pro koho ne? Jak do microfrontends dostat nové lidi? Architektura komunikace v Pipedrive API pro komunikaci balíčků Co je to Tribe? GraphQL a microfrontends Silné a slabé stránky microfrontends a problém řízení Nalaďte nás: Spotify — iTunes — Google Podcasty — TuneIn — RSS podcastů.
24.11.2021 01:46 Od září 2021 můžeme v prohlížečích používat vlastnost aspect-ratio, která v CSS zajistí držení poměru stran pro element ve stránce. Je to úplně jednoduché, jako hodnotu vlastnosti stačí uvést poměr stran: .box Jde o techniku, která umožňuje vytvářet kontejnery pro asynchronní obsah a zabránit tak nechtěnému překreslování obsahu stránky, který měří Kumulativní posun layoutu . Metod pro zajištění poměru stran v CSS máme vcelku hodně, přičemž zajištění plochy pro obrázky už příliš řešit nemusíme, to za nás rozlouskly prohlížeče, a my jen musíme dodat atributy width a height. Pokud jde o další typy obsahu – iframe s obsahem třetí strany, videa, vkládané SVG dokumenty, asychronně vykreslený obsah od grafů až po výsledky ajaxových dotazů – asi nejznámější stávající metodou je padding trik. No a vlastnost aspect-ratio je tady, aby nahradila právě trik s paddingem. Připravil jsem demo s obrázkem, ve kterém to snad půjde dobře vidět: V HTML je .box rodičem obrázku: Povšimněte si atributů width a height, které drží poměr stran samotného obrázku. Pro vykreslení obrázku využívám skvělou službou Satyr.dev. Díky parametru delay má obrázek nastaveno zpoždění. Když na něj čekáme, prohlížeč by za normálních okolností vykreslil bílou plochu. My tam ale chceme ponechat barevný placeholder , aby bylo vidět, že na toto místo něco dorazí. K tomu nám poslouží prvek .box, který má nastavený poměr stran stejně jako obrázek – 4:3 – aspect-ratio: 4/3. Už chápete? Toto bylo úplně základní použití. V textu na web.dev, který sepsala Una Kravets jsou vidět další možnosti – například zajištění stejné velikosti prvků uvnitř CSS gridu. Podpůrná vlastnost object-fit Pokud by byl aspect-ratio člověk, do hospody by pravidelně chodil s vlastnostmiobject-fit a object-position. Chápu je totiž jako nerozlučnou trojka. Obrázek: Hodnoty vlastnosti object-fit. Ve stránce můžeme mít obrázky nebo videa, o kterých víme, že budou mít různý poměr stran. Díky kombinaci aspect-ratio s object-fit pak můžeme držet jednotný poměr stran a vnitřní prvky následně ořezat nebo nějak napozicovat. Možnosti vlastnosti object-fit jsou následující: Hodnota Jak se chová? fill Vyplní celou plochu. Klidně zdeformuje poměr stran obsahu, ale neořízne ho. contain Nevyplní vždy celou plochu. Obsah nezdeformuje, neořízne a zobrazí celý. scale-down Stejně jako contain, ale nikdy nezvětší obrázek nad přirozenou velikost. cover Vyplní celou plochu. Nenechá volné místo, nezdeformuje obsah, ořízne ho. none Drží původní velikost a poměr stran. Někdy ořízne, někdy nechá volné místo. Triky s attr a důležitost atributů width a height Funkce attr umožňuje do CSS deklarace na místo hodnoty vepsat obsah atributu z HTML prvku. Toho využívají prohlížeče při nastavování výchozího poměru stran. Prohlížeče přidaly aspect-ratio do svých výchozích stylů pro překvapivě hodně prvků a to nejen těch, do kterých se stahuje asynchronní obsah. Toto je například z výchozího stylopisu Firefoxu, alespoň podle MDN: img, input , video, embed, iframe, marquee, object, table Tabulka? marquee? Hmmm… Tady se někdo při nastavování výchozích poměrů stran vyřádil… Podpora Vlastnost aspect-ratio podporují všechny moderní prohlížeče: Chrome od verze 88. Firefox od verze 89 Safari od verze 15 A co Explorer? Hm… jděte si dělat legraci jinam. Více je na CanIUse.com. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 V tomto článku si budeme povídat o starých dobrých HTML značkách postavený na specifikaci Open Graph od Facebooku. Asi je skoro všichni znáte, ale všiml jsem si, že je tam pár nuancí, ve kterých leckdo plave. A taky jsem značky pro sociální sítě ještě na Vzhůru dolů nezdokumentoval. Takže čtěte, i když si myslíte, že tomu rozumíte. Slibuju, že tady nezůstanu u základů. Co to přesně je a jak se to liší od ? Meta značky pro sociální sítě a moderní chatovací nástroje jsou zodpovědné za automatické náhledy stránek v momentě, kdy uživatel někde sdílí URL vašeho webu. Takhle to může vypadat na Facebooku, Twitteru, LinkedIn nebo Slacku. Když se to dobře nastaví. Stále samozřejmě platí, že do stránky musíme uvádět značky a : CSS grid: mřížka v kostce Tohle se použije na mnoha různých místech – počínaje názvem okna v prohlížeči a konče výsledky vyhledávání Googlu nebo Seznamu. Tam to bude ovlivňovat například i šanci, jak moc bude uživatel chtít kliknout právě na ten váš výsledek. Teoreticky by to mohlo stačit všem sociálním sítím. Jenže často je struktura informací potřebných pro náhled v prohlížeči, vyhledávači a nebo pro Twitter dost odlišná. Ten hlavní rozdíl je v obrázkovém náhledu obsahu stránky, který po vás sociální síť vyžaduje: Bez téhle metaznačky se při sdílení vašeho článku, produktu nebo firemní stránky zobrazí jen výchozí náhled bez obrázku nebo odkaz úplně bez náhledu. Znamená to výrazně nižší šanci na kliknutí během boje o uživatelskou pozornost. Proto je dobré, abyste alespoň obrázek měli doplněný vždy. Validátory V tomhle textu chci, jak je ostatně u mě zvykem, postupovat salámovou metodou. Nezahltit vás těžkými sousty hned zkraje. Proto si k informaci o nutnosti přiřadit obrázek přidejte ještě odkaz na tento validátor: → metatags.io Po zadání URL vám vrátí docela přesnou vizuální emulaci toho, jak bude vaše stránka vypadat při sdílení na různých sociálních sítích. Mám to dobře. Alespoň mi to ukazuje MetaTags.IO. Tenhle validátor ovšem může za rok, dva být neplatný nebo prostě nebude dostačovat vašim pokročilým nárokům. Proto se ideálně ještě dívejte na výsledky validátorů pro sociální sítě, které vás zajímají: Facebook: Sharing Debugger Twitter: Card Validator LinkedIn: Post Inspector Pinterest: Rich Pins Validator Minimálně ty první dva doporučuji projít u každého typu URL, které na webu máte. Vzhledem k významnému podílu návštěvnosti ze sociálních sítí je to nutnost. Takže teď víte, že máte vždy připravit obrázek a pak se případně nechat řídit validátory. Pojďme ukrojit další, tentokrát více hutné, kolečko salámu. Plné znění meta značek pro obsahovou stránku Obyčejný detail produktu na e-shopu může mít strukturu meta značek podobnou s tou mojí: Následuje vysvětlení: og:title a og:description je titulek a popisek pro sociální sítě a chaty. Můžete jej kreativně využít k lepší proklikovost, odlišit od . og:image je onen důležitý obrázkový náhled. og:url je kanonické URL, které si přičte všechna sdílení a lajkování této stránky. Prý je to povinné i pro URL, která nemají kanonickou adresu. og:site_name použijte raději vždy, ale hodí se hlavně u webů, které sedí na více doménách a chtějí na socsítích používat jednu značku. og:type je důležité označení typu stránky. Různé typy mohou mít různé zobrazení náhledů. Možné typy jsou např. article, book, product… Více k tomu později. twitter:card je označení typu karty, což umožňuje změnit Twitter. twitter:site odkazuje na Twitter účet, který se může u karty objevit s výzvou k přihlášení odběru. Open Graph, Twitter Cards… a tady oEmbed Asi jste si všimli, že kromě technologie Open Graph od Facebooku se zde používají také Twitter Cards . V praxi se můžete setkat ještě se třetí specifikací – oEmbed, která na to technicky jde trochu jinak. V HTML definujete jen cestu k datové struktuře ve formátu XML nebo JSON: V JSON pak definujete potřebně parametry pro vzhled sdílecího náhledu: Vypadá to zajímavě, hlavně z pohledu vývojářů, protože díky umístění „bokem“ není potřeba zvětšovat HTML kód. Zdá se, že minimálně obecně s oEmbed Facebook i Twitter pracovat umí. To ale neznamená, že byste mohli Open Graph pro vaše weby úplně vynechat. Ptal jsem se na sociálních sítích, zda někdo oEmbed používá jako hlavní zdroj pro náhledy webu : My máme oEmbed na jedinom webe , ale nie je to kvôli zdieľaniu náhľadov. Máme ho kvoli možnosti embedovania, napríklad na Medium, tam to bez oEmbed nejde.— Michal Kočí October 20, 2021 oEmbed tedy zatím považuji spíše za určitou alternativu k Open Graph, která je vhodná pro specifičtější použití, ale OG nenahrazuje. Mimochodem, Medium a blogovací nástroje, to je další pole možného výskytu vašeho obsahu, který stojí za pozornost jak při použití OG, tak oEmbed. A mimochodem podruhé – Medium pro zobrazování náhledů z oEmbed používá Embed.ly, můstek třetí strany, kam je ale potřeba se registrovat. O využití oEmbed z druhé strany – pro zobrazení náhledu ve vaší webové aplikaci – dříve psal Bohumil Jahoda na Ječas.cz. Typy obsahu Vraťme se teď k nejrozšířenějšímu Open Graph a k tématu kategorií obsahu. Specifikovat přesnou kategorii obsahu a sémantický popis vašeho obsahu může být užitečné. Podle Facebooku má og:type vliv na to, jak se váš obsah zobrazuje v News Feedu. Pokud typ nezadáte, výchozí je website. Kdysi jsem viděl texty o tom, jak je Facebook schopný přidat „lajknutý“ mediální obsah typu video do oblíbeného obsahu konkrétního uživatele a tím vytvořit o trochu silnější vazbu mezi provozovatelem webu a oním uživatelem sociální sítě. Pokud tedy připravujete obsah jednoho z následujících typů, zvažte, zda ty metaznačky ještě více nerozšířit: články knížky profil uživatele hudba video Například pro případ typu article by se metaznačky mohly rozšířit následovně: Více o typech obsahu píší ve specifikaci Open Graph nebo v článku na Moz.com. Značky s prefixem fb: a propojení s analytikou Uvádět hodnotu pro fb:app_id sice není pro Facebook povinné, ale pomůže to propojit váš web s aplikacemi lidí Marka Zuckerberga, jako jsou komentáře, a jeho analytikou pro sledování webů: Kdysi jsem četl, že je kvůli analytice dobré propojit web i se stránkou na Facebooku. K tomu slouží fb:pages: U Twitteru prý podobnou vazbu na analytiku dělá twitter:site: Dva náhledové obrázky Docela často se hodí mít možnost nechat uživateli vybrat, jaký náhledový obrázek si pro sdílení vašeho obrázku vybere. Je to snadné: Jasně, používá to jen malý zlomek uživatelů , ale např. u obecných obrázků se vám občasná změna zobrazení na sociálních sítích může vyplatit. Náhledy webů na Apple Watch S příchodem chytrých hodinek Watch mě před lety zaujalo, že kalifornská firma převzala existující standard pro náhledy. Ano, i na Apple hodinkách budou uživatelé profitovat z vašich značek Open Graph: Uživatelům se pak zobrazí náhled webu v chatovacích programech. O tomto píšu v článku o vlivu Apple Watch na webařinu. Strukturovaná data: něco podobného, ale vlastně jiného Musím zde zmínit i jednu věc, se kterou se Open Graph a podobné metaznačky pletou – Strukturovaná data od Googlu: Strukturovaná data definovaná na Schema.org také slouží k sémantickému popisu obsahu stránky. Jenže se zaměřují ne jen na pohled na stránku zvenčí jako celek , ale hlavně na samotný obsah stránky. Takže v případě kategorie produktů na e-shopu se Open Graph stará o popis této kategorie, Schema.org zajímá i detailní struktura produktů v obsahu. Rozdíl je v praktickém využití – zatímco Open Graph je pro online kecálky a sociální sítě, Schema.org pro Google a další vyhledávače. Velikost náhledových obrázků Podmínky pro náhledové obrázky se liší podle sociálních sítí, ale je možné najít rozumný průnik: Facebook Ideální poměr stran je 1,91:1. Minimálně 600 ⨉ 315, ideálně ale zhruba 1200 ⨉ 630 pixelů a širší. Maximálně 8 MB. Více v dokumentaci Facebooku. Twitter Poměr stran 2:1. Minimálně 300 ⨉ 157. Maximálně 4096 ⨉ 4096, 5 MB. Více v dokumentaci Twitteru. Vychází z toho, že vaše obrázky by můžou mít poměr stran 2:1 a šířku kolem 1200 pixelů, ale počítejte, že vám je Facebook po stranách mírně ořízne. Generování náhledových obrázků K náhledovým obrázkům se určitě hodí napsat, že nedoporučuji používat nějaké obecné obrázky, např. s logem firmy. Pokud je obsah hodný sdílení, měl by opravdu prezentovat obsah na stránce. Např. na Vzhůru dolů sice pro články obecné náhledy používám, ale při ručním sdílení je měním. Každý důležitý produkt – jako je video, školení, e-book má pak vlastní sdílecí obrázek. Samotná technologie generování je poměrně důležité téma, ale těžko jej pokrýt v rámci jediného článku o Open Graph, takže vás přesměruju na odkazy: Resoc Image Template Development Kit umožňuje generovat náhledy pomocí HTML a CSS. Jde o balíček pro NPM. Článek. Github nedávno psal o vlastním frameworku pro generování obrázků Open Graph. Pro PHP svět existuje knihovna Astrotomic/php-open-graph. Ve světě WordPressu existuje řada pluginů pro Open Graph, které obrázky generují. Jasně, na všechno tam jsou pluginy. Pro framework Next.js se mi líbil tenhle návod na dev.to. Však vy už si to pro vlastní platformy nějak dohledáte. A nakonec – většina z vás pokročilejších to už dávno má vyřešené. Máte nějaké tipy, na které jsem v textu zapomněl? Napište mi do komentářů. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 Zápis image-set umožňuje nechat prohlížeč vybrat nejvhodnější obrázek, definovaný v rámci vlastnosti background-image, ze sady, kterou mu připravíme. Je to vhodné zejména pro posílání různých obrázků na obrazovky s vysokou hustotou pixelů: .box Základní varianty zápisu image-set je možné používat ve všech moderních prohlížečích. Jak jste asi pochopili, jde o obdobu atributu srcset pro značku . Některé varianty zápisu image-set mohou přebírat také funkčnost značky , jenže ty zatím nejsou podporované. image-set je prostě takový malý srcset pro obrázky na pozadí vkládané přes CSS. Výběr obrázku podle hustoty pixelů Obrázky definované ve vlastnosti background-image občas potřebujeme prohlížečům poslat v různých variantách, protože nevíme, jakou hustotu pixelů bude mít zařízení, na kterém běží. .box Obecně vzato, v image-set vždy uvádíme adresu obrázku a podmínky za jakých se má zobrazovat. Tak je to ve specifikaci. Jenže prakticky vzato dnes máme jediný možný zápis – deskriptory 1x, 2x, 3x a podobné udávají hustotu pixelů, tedy hodnotu dppx, kterou znáte z hodnoty resolution v Media Queries. Takže například na většině počítačů s Windows se stáhne první obrázek , protože dppx má hodnotu 1. Na iPhonu 11 se stáhne druhý obrázek. Na některých moderních Androidech, které mívají vyšší hustotu pixelů, i 3 a více, pak poslední obrázek. Není to jediná varianta, kterou bychom podle specifikace mohli použít. Další teoretické možnosti použití image-set Specifikace je jedna věc, praxe ale velí vycházet z podpory v prohlížečích. Dále uváděné možnosti zůstávají na papíře. Jediný prohlížeč, který je podporuje, je Firefox. Výběr podle typu obrázku Podobně jako u značky bychom i tady mohli prohlížeči nabídnout dva formáty pro jeden obrázek. To by bylo skvělé pro využití u nových formátů jako WebP nebo AVIF… .box …kdyby to ovšem podporoval ještě jiný prohlížeč než Firefox. Více je možné vidět v CodePenu. Kombinace obrázků s generovaným pozadím Občas by se kódérkám a kóderům mohla hodit kombinace obrázku s generovaným pozadím, např. přechody tvořenými pomocí linear-gradient . .box Toto ale nepodporuje ani onen nový Firefox. Odkážu na CodePen k hraní. Deskriptor w V atributu srcset bychom teoreticky mohli mít možnost používat deskriptor w, jenž prohlížeč informuje o šířkách nabízených obrázků. To aby si lépe vybral. .box Tady ale pouštím imaginaci na plné obrátky a troufám si jít opravdu daleko, protože i ve specifikace o tomto mluví jako o přání a úkolu pro budoucí specifikátory, nikoliv o navržené vlastnosti. Tak nic. Mrkněte se na CodePen, pokud opravdu hodně chcete. Na vaše objevování zápisu image-set se těší celá moje kolekce CodePenů. Podpora Použitelnost zápisu image-set díky nové implementaci ve Firefoxu bez pochyby prudce stoupne. Jde totiž o poslední moderní prohlížeč, který jej dosud neuměl. Jenže pokud jste se, jako já, nechali namlsat všemi zde uvedenými možnostmi zápisu, budete stejně zklamaní. Ale tak už to mezi námi webaři chodí. Jsme nadšení z implementace nový vlastností, abychom byli tentýž den zklamaní, co všechno ještě prohlížeče neumí. Při implementaci nezapomeňte na Autoprefixer, protože i moderní prohlížeče pro tuto vlastnost vyžadují prefixy – např. Chrome rozumí jen zápisu -webkit-image-set . Internet Explorer je sice už téměř vymřelý druh, ale pokud byste potřebovali zajistit si fungování i v něm, musíte uvést náhradní řešení. Je to vidět v mém prvním CodePenu: .box Vše o podpoře image-set najdete klasicky na CanIUse. caniuse.com/css-image-set Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 V CSS často pracujeme s rozměry v určitém směru. Občas se ale může stát, hlavně při práci s cizokrajnými jazyky, že typografii nebo layout potřebujeme sázet v jiných směrech než zleva doprava jako naši mateřštinu. Logické vlastnosti a rozměry vznikly jako alternativa k fyzickým vlastnostem a rozměrům. Například namísto fyzického margin-left:1rem napíšete margin-inline-start:1rem. Bude to pak univerzální pro češtinu, arabštinu i japonštinu. Pokaždé se totiž vnější okraj vykreslí na jiné straně. V CSS to je relativní novinka, ale má to vcelku dobrou podporu v prohlížečích. Bude to pro vás naprosto zásadní, pokud pracujete s různými jazyky. Vám ostatním Logical Properties pomohou spíše drobně, např. v tom že zde máme nové užitečné zkratky vlastností jako margin-inline a padding-block. Všechno se ale dozvíte v článku, pojďme to teď rozebrat dopodobrona. Příklad s arabštinou Arabština má, jak známo, opačný tok textu než evropské jazyky – čte se zprava doleva. Vezměme, že máme jednoduchý příklad, který vidíte na obrázku. Nadpis, obrázek a text, který jej obtéká. Na polovině stránky je to česky, na polovině arabsky. Jak to safra nastylovat co nejuniverzálněji? Arabská polovina textu je v HTML označená atributem s hodnotou dir="rtl". To znamená, že v tomto místě má tok dokumentu směr zprava doleva. . To by ale na rozvržení nemělo žádný dopad, pokud bychom použili klasické fyzické hodnoty jako float:left nebo margin-right:1rem. My ovšem pro sazbu textu a vložení obrázku sáhneme po logických vlastnostech a hodnotách: .column img Vysvětlím to více: float:inline-start znamená, že obrázek bude plout k začátku inline osy. V češtině by to tedy bylo doleva , v arabštině doprava . margin-inline-end:1rem přidá vnější okraj na konec blokové osy . V češtině by to odpovídalo margin-right:1rem, v arabštině margin-left:1rem. margin-block-end:1rem je podobný případ, jen v tomto případě pro oba jazyky stejný. Odpovídá margin-bottom:1rem. Například ale v japonštině, sázené shora dolů by se měnily obě osy, řádková i bloková. Užitečné zkratky vlastností Až budete zkoumat přiložený CodePen, pravděpodobně vás v něm zaujme tato deklarace: body Jde o zkratku pro tuto deklaraci: body A podobně fungují zkratky pro blokový směr a další vlastnosti jako je padding. Proč to tak zdůrazňuji? Definice rozměrů v jednom směru je věc, která nám v CSS chyběla a která je díky CSS Logical Properties nyní možná. Drobnost, ale pomůže. I těm, kteří nesázejí dokumenty v arabštině nebo japonštině. Podívejte se na CodePen k tomuto příkladu. Jen pozor, logické hodnoty ve vlastnosti float mě v době psaní fungovaly ve Firefoxu, ale ne v Chrome a Safari. Směr blokový a řádkový Pro podrobnější pochopení logických vlastností a hodnot v CSS je potřeba uvědomit si, že vycházejí z obecné vlastnosti CSS - dvou směrů: blokového řádkového. Řádková osa je směr sázení textu pořádcích. Bloková osa zase ve směru protilehlém. Asi si to umíte představit podle vlastnosti display, která má hodnoty inline a block. Možná není úplně jasné, proč se nepoužívají hodnoty z reálného světa – osa horizontální a osa vertikální, případně vodorovná a příčná? Důvod je v obecnosti. Pokud od CSS chceme, aby umělo pracovat s různými světovými jazyky, je nutné, aby se umělo vyjadřovat v obecných pojmech, nikoliv v pojmech které reflektují například jen jazyky vycházející z latiny. Směr toku dokumentu versus směr layoutu Pojmy jako řádková osa a bloková osa můžete znát z nových layoutový modulů jako je grid. Směr toku dokumentu je ale něco jiného než směr layoutu. Díky tomu, že je CSS stále obecnější, mohou některé pojmy splývat a zaměňovat se. Já sám jsem se napálil právě u řádkové a blokové osy, když jsem se domníval, že je možné změnit osu toku dokumentu pro konkrétní komponenty změnou toku layoutu: .container Ale prdlajs. Takhle to nefunguje. To, co změní vlastnost flex-direction nebo třeba grid-auto-flow je směr rozvržení, nikoliv směr toku dokumentu. Směr toku dokumentu mění pouze tyto vlastnosti: writing-mode – určuje tok dokumentu na blokové úrovni. Možnosti hodnot jsou třeba horizontal-tb nebo vertical-rl. direction – určí směr sázení na inline ose. Možnosti ltr nebo rtl. text-orientation – mění orientaci textu sázeného svisle. V praxi se to pak projevuje následovně: Vezměme, že máme flexový kontejner a v něm několik položek. Každá z nich má tuto deklaraci: .container p Ano, manipulujeme tady s vlastnostmi prvku na blokové osy, tedy v případě sázení v češtině na výšku. Prvek má vyšší vnitřní okraj a zelenou barvu rámečku border-block-color:LimeGreen. V případě, že směr rozvržení změníme z vodorovného na svislý , zelené okraje položek zůstávají umístěné ve svislém směru. Změnil se směr layoutu, ale ne směr toku dokumentu. Pozice blokových vlastností se mění až se směrem toku dokumentu, tedy zapojením deklarace writing-mode:vertical-rl. Zelené blokové okraje změní směr až se změnou toku dokumentu. Podívejte se na to v CodePenu. Podobné to bude u vlastnosti grid-auto-flow, která dokáže změnit směr rozvržení v gridu. Konkrétní logické vlastnosti a hodnoty V další části textu už následuje jen výčet nových logických vlastností a hodnot, které jsou adekvátní fyzickým vlastnostem. Než je začnete používat, dobře si to otestujte v různých prohlížečích. Box model Pro box model máme hezký obrázek s porovnáním fyzických a logických variant: Zdroj: Adrian Roselli. cdpn.io/e/bGGxrvM Logická výška a šířka: Logicky Fyzicky block-size height inline-size width min-block-size min-height min-inline-size min-width max-block-size max-height max-inline-size max-width Logické vnitřní okraje: Logicky Fyzicky padding-block-start padding-top padding-block-end padding-bottom padding-inline-start padding-left padding-inline-end padding-right padding-block padding-top & padding-bottom padding-inline padding-left & padding-right Logické vnější okraje: Logicky Fyzicky margin-block-start margin-top margin-block-end margin-bottom margin-inline-start margin-left margin-inline-end margin-right margin-block margin-top & margin-bottom margin-inline margin-left & margin-right Logické posuny : Logicky Fyzicky inset-block-start top inset-block-end bottom inset-inline-start left inset-inline-end right inset-block top & bottom inset-inline left & right Logické rámečky: Logicky Fyzicky border-block-start border-top border-block-end border-bottom border-inline-start border-left border-inline-end border-right border-block border-top & border-bottom border-inline border-left & border-right Poznámka: Vzhledem k tomu, že vlastnost border představuje zkratku, uvádím jen ji. Adekvátně ale existují zkratky pro všechny podvlastnosti a příbuzné vlastnosti: Šířka: border-width Styl: border-style Barva: border-color Zakulacení: border-radius Klíčové slovo logical Tohle může být zajímavé, ale zatím to v prohlížečích nemá podporu. Když uvedete klíčové slovo logical před zápisem hodnot ve zkratkách vlastností… .box …interně se to bude považovat za logické hodnoty: .box Takto to má fungovat pro následující vlastnosti: inset, margin, padding, border-width, border-style, border-color, scroll-padding, scroll-margin. Až to bude fungovat v prohlížečích… Jen připomínám, že logický směr je pro různé jazyky různý. Hodnoty pro vlastnosti Jak je z článku už asi zřejmé, logické alternativy nemusejí mít jen vlastnosti, ale také jejich hodnoty: Logicky Fyzicky block-start top block-end bottom inline-start left inline-end right Ve vlastnostech float a clear pak budeme moci použít nové hodnoty inline-start a inline-end. Pro text-align je to jednodušší, protože jde zarovnávat jen v jednom směru. Takže text-align:start bude text-align:left. Vlastnost resize zase bude moci nabývat hodnot block a inline. Podpora v prohlížečích V době psaní aktualizace tohoto textu můžu konstatovat, že podpora CSS Logical Properties je v moderních prohlížečích plná. Více na CanIUse. caniuse.com/css-logical-props Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 Pomocí CSS vlastnosti gap můžeme definovat mezery v rozvrženích vytvářených pomocí CSS layoutů. Téhle mezeře se občas i v češtině podle anglického originálu říká „gutter“. A brzy taky možná „gap“. gap je mezera mezi vnitřními prvky layoutu. Vlastnost gap je možné použít ve všech moderních layoutech – v gridu, flexboxu i multicol. Patří však do specifikace CSS Box Alignment. Od příchodu Safari verze 14.1 je možné gap ve všech prohlížečích používat nejen v rámci gridu, ale také ve flexboxu. To je skvělé a taky proto se vyplatí tuto vlastnost umět použít. Zápis gap je zkratkou pro jiné dvě vlastnosti: row-gap – prostor mezi řádky column-gap – prostor mezi sloupci Zkratka se zapisuje takto: gap: ; Nastavujeme zde, jak je v CSS zvykem, nejprve svislý a pak až vodorovný směr. Druhá hodnota je volitelná. Pokud se neuvede, použije se jedna hodnota pro oba směry. I to je ostatně ve stylech běžné. Příklad Vezměme ukázku se čtyřmi položkami v layoutu: 1 2 3 4 Layout v CSS definujeme následovně: .container Vysvětleme si to: Deklarace display:grid zajistí zobrazení pomocí CSS gridu. Vlastnost grid-template-columns definují podobu mřížky. Zde jde sloupce o rovnoměrné šířce. gap: 2em 1em je instrukce pro vložení mezery svisle a pak i vodorovně. Totéž bychom samozřejmě mohli zapsat v nezkrácených deklaracích následovně: .container Raději gap než margin či padding Vlastnost gap je pro definování mezer v layoutu daleko efektivnější než padding nebo margin. Nijak se totiž nepočítá do šířky ani výšky položky layoutu a také se vždy vykresluje jen mezi položkami samotnými. Je také pěkné si nastavit mezery mezi prvky v layoutu pro celý kontejner na jednom místě. Z toho důvodu právě vlastnost gap vznikla. Je však samozřejmě možné a bezpečné zároveň nastavovat mezery pomocí vnějších i vnitřních okrajů prvku nebo případně gap s dvojkou margin/padding kombinovat. Toho se určitě nebojte. Jen si pak dejte pozor na interpretaci v prohlížečích, protože viditelná mezera vám naroste: .container .column Anketní otázka: Jak velká bude mezera mezi položkou 1 a 2? Zvládnete ji zodpovědět ještě než se podíváte na obrázek? Nechám vám chvilku času. Ještě chvilku. A teď už přichází obrázek: Ano, viditelná mezera mezi položkami bude široká celé 3em. Sečteme dva vnější okraje a mezeru . Možné hodnoty Následuje přehled možných hodnot vlastnosti gap. Čistě pro inspiraci, naložte s tím dle svého. Různé hodnoty pro svislý i vodorovný směr .container Jak už jsem uvedl, toto je možné. V prvním čísle je svislý směr, v druhém vodorovný. Pojďme si to vyzkoušet na flexboxovém layoutu, který jsme ještě vlastností gap nestihli nepotrápit: .container .column Raději si to zopakujme. Zápis gap:5px 1rem říká, že svisle mezi řádku chci mezeru 5px a vodorovně mezi sloupci pak 1rem. Použití funkce calc Uvádění výpočetní funkce calc se v hodnotách gap může hodit: .container Dříve toto nefungovalo v Safari, ale nyní je to už zprovozněné. Do slunné Kalifornie posíláme klíčenku s poděkováním! Pokud firmě Apple nevěříte, zkuste si to na CodePenu. A k čemu, že se funkce calc může hodit? Příkladem budiž odpočítání šířky rámečků buňek layoutu z celkové šířky mezery. Klíčové slovo normal Šup s tím hned do vody, tedy do ukázky kódu: .container Slovo normal představuje použitou hodnotu 1em u vícesloupcového layoutu a hodnotu 0px v kontextu gridu a flexboxu. Asi to není zase tak moc zajímavé… Já jen… Když byste se náhodou ptali… nebo vám to někdo položil jako otázku v testu. Procenta a jejich uvádění ve svislém směru Procentuální hodnoty můžete chtít použít, ale dejte si pozor na hodnoty ve svislém směru. .container Ve vodorovném směru je to jednoduché – spočítá se deset procent ze šířky rodičovského kontejneru a tato hodnota se vloží jako mezera mezi prvky. Zajímavější je svislý směr. V layoutu tvořeném mřížkou se spočítá deset procent z výchozí výšky rodičovského kontejneru. Prostě z výšky před aplikováním mezery pomocí vlastnosti gap. Pravděpodobně se vám tedy stane, že mezera vytlačí spodní prvky z kontejneru. V případě flexboxového layoutu a neznámé výšky kontejneru se procentuální gap ve svislém směru vůbec nezapočítá. Je z něj čistá nula. Ptáte se, kdy je výška kontejneru neznámá? Inu, ve flexboxu skoro vždy – dokud ji výslovně nedefinujete. Zkoušení naživo je možné opět v následující ukázce. Co byste o gap měli vědět? Když už jsme v tom, mám pár poznámek. Doslova pár: Mezery tvořené gap mají vliv na minimální rozestupy mezi položkami. Je však možné další rozestupy přidat pomocí vlastností jako justify-content nebo align-content. Jejich hodnota space-between má podobnou funkcionalitu jako gap a je možné je vzájemně kombinovat. Když už se gap dá použít všude, nedá se to použít i pro mezery mezi buňkami uvnitř ? Nedá, děkujeme za optání. Tabulková zobrazení místo používají vlastnost border-spacing. Podpora v prohlížečích Pokud jde o moderní prohlížeče, vlastnost gap ve flexboxu a gridu podporují všechny. Grid: Prakticky plná podpora. Internet Explorer 11 vlastnost gap nepodporuje, ale to je možné dohnat použitím nástroje Autoprefixer. Flexbox: Nepodporuje IE 11. Vícesloupcový layout: Nepodporuje IE 11 a zatím ani Safari. Takže pokud potřebujete mezery v gridu a flexboxu a neřešíte Explorer, jste takzvaně ve vatě. Dříve jen v gridu Dřívější zápisy „děrovacích“ vlastností byly ve specifikaci definovány jinak, s prefixem grid-: grid-row-gap, grid-column-gap a grid-gap a zaměřené čistě jen na CSS grid. Nyní jsou ale z této části specifikace vyjmuté a vyvíjené pod samostatným modulem CSS Box Alignment. Logicky totiž nespadají jen do možnosti definovat layout v mřížce, ale také ve flexboxu nebo vícesloupcovém layoutu. Vlastnost gap, tedy bez prefixu grid- je podporována v Chrome 68+, Safari 11.2 Release 50+ a Opeře 54+. Ale to už je dneska vlastně jen historické okénko. Detailní informace o podpoře jsou na CanIUse. caniuse.com/gap Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
24.11.2021 01:46 Hlavně aby to bylo. Hlavně aby to bylo. Hlavně abychom se viděli osobně. Po roce a půl života v online už nemusí být vaše požadavky na WebExpo vysoké. Chcete se třeba konečně vidět s větším počtem spřízněných lidí. Jako já. WebExpo ale splní vaše požadavky i v případě, že očekáváte víc než networking. A právě o tom je tenhle článek. Co si nenechám ujít? Harry Roberts: Get Your Straight Harryho přednášky o CSS a rychlosti webu už z WebExpa znáte. Je pověstný tím, že si vybírá poměrně úzce zaměřená témata, ale pitvá je až do morku kosti. Jeho rozborku vlivu značky na performance si stejně jako čtvrteční workshop nenechám ujít. Na Harryho myšlení se můžete naladit mým rozhovorem o ITCSS nebo Adamovým o konzultování. In-person events are back! And I cannot wait to return to one of my favourites—#webexpo in Prague. https://t.co/NBVWJckaqz— Harry Roberts June 15, 2021 Tim Kadlec: When Javascript Bytes Největší problém rychlosti webu nejsou obrázky jak si lidé často myslím. Je to samozřejmě JavaScript. Také od Timovy přednášky čekám hluboké znalosti ale i konkrétní tipy. Recommended by @csswizardry, @tkadlec delivered a great talk in 2018 about website performance. At #WebExpo, Tim will show practical ways to reduce the amount of JavaScript we’re sending down to our visitors. You can register at https://t.co/oJ9S5WdD4E pic.twitter.com/VpKfobpFJz— Šárka Štrossová June 24, 2021 Vitaly Friedman: Getting Forms UX Right: From Checkboxes To Dropdowns Vitalyho přednášky do hloubky nejdou a dozvíte se tam i věci které asi hned další den nepoužijete. Dozvíte se toho ale hrozně moc, je to skvěle předneseno a vždy si rozšíříte obzory. To je skvělé hlavně u oborů, které až tak nesledujete, jako je tomu u mě v případě UX. *SO* looking forward to run an in-person Smart Interface Design Patterns Workshop with @webexpo later this month! Everything from multi-mega-hover-menus to complex enterprise tables in one day!Perhaps see you there?https://t.co/sKnRCsYAK0 pic.twitter.com/Zmgfu37yq6— Smashing Magazine September 9, 2021 Na co se těším dále? Na Rikiho přednášku o codemods, talk o Google Analytics 4. Ale mám ambice toho vidět více, viz můj program. Je tu ale ještě pár dalších částí programu, které stojí za zmínku. Mentor Hours Letošní WebExpo bude z velké části přenášené online, ale Mentor Hours jsou jedna z věcí, která je nepřenositelná. Na pokec nebo pro moudra se můžete zastavit například za Jakubem Nešetřilem, Pavlínou Louženskou nebo Janem Řezáčem. Ve středu od 13:00 hodin tam budu k dispozici také já. Moc rád si s vámi popovídám o vašich trablech s rychlostí webů, Google Page Experience a o jakýchkoliv souvisejících tématech. Těším se na vás!
24.11.2021 01:46 V tomhle díle podcastu si Robin s Martinem povídali o novince, která se nedávno objevila v Chrome. O technologii, kterou si oba dlouho v CSS přáli. O specifikaci, které by mohla být tou nejdůležitější za posledních několik let. O Container Queries. Přejeme vám příjemný poslech. Podcast MP3 ke stažení O čem mluvíme? Martinův tip: záznamy přednášek z a záznamy diskuzí z FrontKon Článek: Ohlédnutí za FrontKon, prvním ročníkem konference Frontendisti.cz Robinův tip: Framework pro microfrontendy Piral Hlavní téma: Container Queries Článek: Container Queries jsou teď experimentálně v Chrome Canary CSS Container Queries na MDN Článek Ethana Marcotteho z roku 2010 Responsive Web Design Zápis Container Queries v kódu Návrh úpravy specifikace od Miriam Suzanne Článek: Proč si Martin myslel, že Container Queries nikdy nespatří světlo světa GitHub: WICG/container-queries Článek: The Raven Technique Tvorba specifikace: Pomalost W3C a rychlost Chrome Článek na CSS-Tricks: Say Hello to CSS Container Queries Článek na Smashing Magazine: A Primer On CSS Container Queries Jsou Container Queries největší věc od CSS Grid? Nalaďte nás: iTunes – Spotify – Google Podcasty – TuneIn – RSS podcastů.
