15.02.2023 22:02 Do prosincového dílu podcastu jsme si s Robinem pozvali dva hosty: Adélu Dostálovou a Honzu ChemiXe Černého. Probrali jsme fenomén Figmy, nejpopulárnějšího nástroje pro návrh designu webů. V podcastu hledáme příčiny jejího raketového růstu a přemýšlíme nad změnami v pracovních postupech, které s Figmou souvisejí. Na samotný závěr jsme nemohli vynechat Adobe. Shodli jsme se, že obavy o budoucnost Figmy máme sice velké, ale podle všech možných příkladů z nedávné historie je nemožné jednoznačně říct, že Adobe Figmu zkazí. Podcast Host: Adéla Dostálová Adéla Dostálová používá Figmu každodenně v týmové práci pro Pipedrive a spolu s celou designérskou komunitou se obává, co teď s Figmou bude, když ji koupil poněkud těžkopádný obr jménem Adobe. LinkedIn. Host: Honza ChemiX Černý Honza ChemiX Černý spolupořádá meetupy o Figmě. Figmu miluje mimo jiné jako vývojář. Baví ho velké možnosti automatizace, exportů a dalšího usnadnění práce. LinkedIn, Twitter. Ukázka: co bude s Figmou po koupi ze strany Adobe? O čem mluvíme? Robinův tip: vyšel Next.js verze 13. Martinův tip: Web Performance Calendar. Adéla Dostálová a proč používá Figmu? Honza Černý má slovo, Figma meetupy a technologické pozadí Figmy. Cesta k Figmě - Photoshop, Sketch a tak dále. Adobe XD, jak do toho zapadá? High Fidelity prototypy - problém nástrojů nebo procesů? Design systémy a spolupráce designérů s vývojáři. Live table a FigJam. Export do CSS a kódu, dává to smysl? Koupě ze strany Adobe a jak to s Figmou bude? 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.
14.02.2023 13:16 Nová, už desátá verze, nástroje pro audit webu Lighthouse mění způsob počítání Lighthouse Score. Přednost dostanou metriky Web Vitals. Metrika TTI naopak ze skóre a viditelných reportů úplně mizí. Obrázek: Zase je to trochu jinak. Jinak a lépe. Aktuální vliv metrik na celkové skóre je tedy následující: TBT = 30 % LCP = 25 % CLS = 25 % FCP = 10 % SI = 10 % Z mého pohledu je to dobře, protože to skóring alespoň trochu přibližuje principu tří metrik Web Vitas. Je to dobře i proto, že TTI je sice pro odborníka zajímavou metrikou, nicméně laika může svým specifickým výpočtem velmi zmást. TTI metrika „interaktivity po načtení”, takže je nahraditelná metrikou načtení v kombinaci s metrikou interaktivity . Jen pozor, aktualizace metrik nic nemění na faktu, že Lighthouse Score není zase tak dobrý indikátor rychlosti webu. Je totiž měřené na velmi specifických zařízení a ze specifických míst světa. Pro středoevropské prostředí bývá zbytečně přísná. Pokud je to možné, vždy dávejte přednost Web Vitals získanými přímo od uživatelů, z Chrome UX Reportu. Další novinky v Lighthouse 10 Můžeme se ale těšit i na další inovace v reportech Lighthouse: Audit Back/forward cache, velmi zajímavé nové vlastnosti Chrome, která dokáže weby u uživatelů vcelku slušně zrychlit. Audit bránění uživatelům vložit heslo ze schránky. Lighthouse 10 také přichází s deklaracemi typů TypeScriptu. Cokoli importovaného z Lighthouse by nyní mělo být typováno. Kdy se na to můžeme těšit? Už brzy se to objeví v Chrome 112, PageSpeed Insights, jejich API, a tedy i našem testeru na PageSpeed.cz. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
14.02.2023 13:16 Subgrid umožní vytvořit zanořenou mřížku, která zároveň podědí layout rodičovského gridu. Je to velmi praktické, ale zatím podporované jen ve Firefoxu a Safari. Subgrid je součástí specifikace CSS gridu. Grid je skvělý, ale dříve či později se s ním dostaneme do situace, kdy potřebujeme jeden grid zanořit do druhého. V takové situaci si pak pochopitelně přejeme, aby vnitřní grid dokázal podědit vnější layout. Jak vidíte na obrázku níže, subgrid mám to pomůže zařídit. Vnitřní části položek budou lícovat, i když mají různě velký obsah. Grid a subgrid. Táta a syn. Můžeme to samozřejmě zajistit i bez subgridu: Nastavit prvkům fixní rozměry na výšku nebo použít JavaScript . Staré páky mezi kodéry si vzpomenou na složité tabulkové layouty, kterými se toho dalo dosáhnout, ale ve kterých se nikdo nevyznal… Příklad s kartou produktu Víte vy co? Ukážu vám to na jednoduchém příkladu. Na obrázku výše totiž vidíte layout podobný tomu, který používám na Vzhůru dolů. Mám seznam položek, říkejme jim karty produktu. Každá karta má složitější strukturu, ve které najdete nadpis, obrázek, text a tlačítko: Text… Tlačítko… Vnější rozvržení, tedy to, které se týká vodorovného umístění karet, udělám gridem. To žádný problém nebude: .container Umísťuji zde dvě položky ). Přeji si, aby nebyly užší než 250px a širší než 400px. Mezera mezi položkami je 4rem. To bude asi bez problémů, že? Ale když já chci, aby nadpisy, obrázky, texty i tlačítka jednotlivých karet byly vždy ve stejné výšce. Přidáváme layout pro jednotlivé karty Nejprve musíme změnit rodičovský layout. Uděláme to tak, že přidáme řádky pomocí vlastnosti grid-template-rows. .container Jak vidíte, nemáme příliš velké ambice položky layoutu nějak omezovat. Víme jen, že budou čtyři . A hodláme je pouze zarovnávat mezi sebou navzájem. A teď kouzlo, subgrid Zápis pro vnitřní mřížku u jednotlivých položek, který řešíme podmřížkou , bude: .item Prohlížeči dáváme tyhle instrukce: Budiž grid ! Umísti tuto položku do čtyř buněk gridu . Svislý směr mřížky nechť je subgridem, takže po gridu zdědí vnější mřížku . Je to jasné? Výsledek uvidíte na obrázku, který vám snad pomůže s pochopením celé věci, což je opět možné zkoušet na živé ukázce. Zelená podmřížka si hoví v modré mřížce a je spokojená. My také, protože vnitřní položky karet jsou navzájem zarovnané. Živá ukázka vám řekne více. Poznámky k subgridu Vzhledem k tomu, že v době aktualizace textu subgrid umí jen dva menší prohlížeče, Firefox a Safari, nepůjdu u této části CSS gridu úplně do hloubky. Pár poznámek zde ale uvedu: Vícerozměrnost sugridu V ukázce jsme pro podmřížku využili jen svislý směr rodičovského layoutu. Je ale samozřejmě možné využít i vodorovný nebo prostě oba směry najednou. Pak se z toho stává jeden velký tabulkový layout, jako z roku 2002. Dělám si legraci, je to samozřejmě daleko, daleko lepší než layout v . Dědění mezer Vlastnost gap se z rodičovského gridu samozřejmě dědí i na ten vnitřní. Je ale možné si mezery ve vnitřním layoutu změnit novou deklarací gap. Žádné přidávání implicitních řádků nebo sloupců V běžném gridu je možné pomocí vlastností grid-auto- definovat rozvržení pro řádky či sloupce. Ty se automaticky přidají, když se rozšíří obsah v HTML. Je asi pochopitelné, že toto v subgridu možné není. Vždy se jen umísťuje do mřížky, která je zděděná shora od rodičovského gridu. Podpora v prohlížečích Subgrid je součástí specifikace CSS Grid Layout Module již od Level 2, která se datuje do roku 2018. Zde je stav k únoru 2022: Firefox podporuje subgrid od verze 70 z prosince 2019. Safari subgrid přidalo v září 2022 do verze 16, od iOS 16 a v aktualizaci pro macOS Monterey a Big Sur. V Chromu se na subgridu – zdá se – docela hodně pracuje. Subgrid má tedy opravdu dobrou šanci, že se ujme a bude nám dobře sloužit už v blízké budoucnosti. Aktuální informace od podpoře hledejte na CanIUse.com/css-subgrid Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
07.02.2023 17:00 Pořád se něco učíme. Abych se naučil layouty v CSS, napsal jsem o nich knížku. Opravdu. Nemyslete si, že jsem si prostě jen sedl k počítači a začal sepisovat to, co jsem měl v hlavě. O gridu a flexboxu jsem toho před třemi lety nevěděl zase o tolik více než průměrný frontendista. Jedna z metod psaní knížky obnášela nakódování desítek častých webových layoutů. Nejprve flexboxem, který jsem uměl lépe. Pak gridem. Překvapilo mě, že skoro vždy bylo nakonec řešení pomocí gridu efektivnější, přehlednější. Vlastně celkově lepší. Nejdůležitější praktická kodérská znalost, kterou jsem při práci na knížce získal, bylo to, že skoro vždy preferuji grid před flexboxem. V tomhle textu vám ukážu důvody, proč tomu tak je. Flexbox vs. grid Začneme obecnou rovinou. V knížce mám pro srovnání těchto dvou systémů pro tvorbu layoutu takovou pěknou tabulku: Vlastnost Flexbox Grid Jednorozměrný layout + + Dvourozměrný layout + Layout z obsahu + ? Layout z mřížky + Kompatibilita v MSIE + ? Už tady je trochu vidět, že v obecné rovině výhody gridu převládají: Grid je určený pro dvourozměrný layout , ale zvládnete s ním i ten jednorozměrný . Flexbox byl navržený pro takzvaný „content out“ layout, kdy se layout vytváří na základě obsahu, což je důležitá, ale ne tak častá potřeba kodérek a kodérů. Grid více odpovídá naší představě o layoutu – chceme, abychom layout kontrolovali my, ne obsah, takzvaně „grid in“. Dříve byla velkou výhodou flexboxu jeho slušná komptatibilita s MSIE. Podpora gridu v tomto dnes již neslavném prohlížeči nějaká byla, ale šlo o pověstné škrábání levou nohou za pravým uchem. Navíc – Explorer je už mrtvý. Grid byl vymyšlený pro vyřešení většiny layoutů na webu. Flexbox má pak řešit specifické případy. Flexbox ale stále vládne Tohle téma mě zajímá, a tak občas na sociálních sítích dělám průzkumy mezi vývojářkami a vývojáři. Preferují flexbox nebo grid? Vypadá to, že stále flexbox. Na Twitteru mi v březnu 2021 odpovědělo 55 % lidí , že flexbox považují za výchozí pro svoji práci. U pětiny to byl grid a u čtvrtiny záleží na případu použití. Podobnou anketu jsem letos zopakoval ve skupině Frontendisti.cz na Facebooku. Flexbox preferuje 30 % , grid jen necelá desetina. Zbytek se rozhoduje podle situace, což je asi nejlepší odpověď, protože opravdu záleží na layoutu. Co je za preferencí flexboxu u webařů? Hlavní důvod je v tom, že flexbox působí jednodušeji. Další podstatná příčina je jeho kompatibilita s MSIE, která se ve své době velmi hodila. No a třetí důvod vyplývá z druhého. Flexbox jsme se kvůli MSIE nějak naučili a na velkou část rozvržení prostě stačí. Je samozřejmě otázkou, jak moc optimální jsou layouty nakódované skoro vždy flexboxem. Zkusme se zamyslet, zda to nejde lépe. Důvod první: robustnost gridu Díky zaměření gridu na tzv. „grid in“ layout byli autoři specifikace nucení promýšlet daleko více případů použití. Specifikace je tedy rozsáhlejší, což mnohé odradí. Ale díky tomu je i robustnější. Co vše můžete gridem udělat nad rámec obyčejných layoutů? Uvedu zde pár příkladů: Pomocí vlastnosti grid-area můžete umístit jakéhokoliv potomka na jakékoliv místo mřížky. Hodnota dense vlastnosti grid-auto-flow částečně nechává vykreslení layoutu typu masonry na prohlížeči. I grid se může přizpůsobovat obsahu ). Grid můžete použít nejen blokově , ale také v řádce . Z gridu vycházejí nové typy rozvržení jako podmřížka nebo masonry. Podobně jako mnozí z vás, jsem i já historicky preferoval flexbox. Na většinu běžných layoutů mi stačil. V momentě, kdy jsem se začal věnovat gridu, postupně začalo docházet k přeorientování na mřížku. Došlo to tak daleko, že jsem nedávno sám sebe načapal při přemýšlení, jestli existují layouty, u kterých je výhodnější použít flexbox. Ano, na pár si jich vzpomenu, ale moc jich není. Ještě se u toho v textu pozastavím později. Důvod druhý: plnohodnotný Box Alignment CSS Box Align je modul CSS, který definuje zarovnání v jakémkoliv rozvržení, ať už je to grid nebo flexbox. Na flexboxu je ovšem nešťastné, že pro něj neplatí všechny vlastnosti zarovnání boxů. Také následující tabulka je z knížky: Hlavní osajustify-* Příčná osaalign-* Oba směryplace-* Zarovnání položek*-items justify-itemsflex, grid align-itemsflex, grid place-itemsflex, grid Zarovnání sebe sama*-self justify-selfflex, grid align-selfflex, grid place-self flex, grid Distribuce obsahu*-content justify-contentflex, grid align-contentflex, grid place-content flex, grid Je to tak. Vlastnosti justify-items i justify-self nejsou dostupné pro layouty tvořené flexboxem. Tím pádem nemůžeme ani použít skvělé zkratky pro obousměrné zarovnání – place-items a place-self. Namísto justify-items můžeme použít starý dobrý margin nebo pro centrování položek ve flexboxu na příčné ose třeba justify-content. Jenže tím to trochu hackujeme, justify-content je ve skutečnosti určný pro distribuci mezer mezi položkami. Jaký je důvod pro nepřítomnost některých vlastností Box Alignment ve flexboxu? Rozličné zaměření flexboxu a gridu. Když jsem to ve specifikaci studoval pro potřeby psaní knížky, chvíli jsem nemožnosti použít tyto vlastnosti rozuměl. Je to složité. Dnes už vám to bohužel vysvětlit neumím. Každopádně v kodérské praxi je nutnost pamatovat si, co ve flexboxu používat můžu a co ne, velice nepříjemná. Pojďme na příklad. Chci v obou směrech centrovat boxík uvnitř rodičovského prvku. Asi jako na obrázku. Centruj, centruj, vykrúcaj! HTML: Jsem uprostřed! CSS řešení flexboxem: .container .item Ano, můžeme zde použít magickou zkratku, kterou kodéři dnes obvykle používají: .container Otázkou je, jestli opravdu kodéři vědí, co přesně tímto dělají. V gridu je to daleko jednodušší. Můžeme použít celou škálu zarovnávacích vlastností z tabulky výše. A tedy i zkratku place-items pro obousměrné zarovnání. .container Pojďme se ještě podívat na poslední z důležitých důvodů, proč já osobně preferuji mřížku před flexboxem. Důvod třetí: layout na rodiči Na gridu mě připadá výhodné, že layouty se vždy vytvářejí na rodiči. Díky tomu existuje jen jeden prvek, který do layoutu promlouvá. A to je rodič. Vezměme tento jednoduchý příklad layoutu s jedním rodičem a dvěma potomky. Jeden má zabrat třetinu, druhý dvě třetiny šířky. HTML kód vypadá takto: 1/3 box 2/3 box Řešení fleboxem by mohlo být následující: .container .col-1 .col-2 Všimněte si, že používám vlastnost gap, která je ve flexboxu k dispozici poměrně čerstvě. Může to být prkotina , ale to, že máme layout definovaný na potomcích, je z mého pohledu, no… řekněme neoptimální. Vždy si totiž představím řádově složitější příklady na komplexních webech nebo systémech designu. Tam se kód pro rodiče i potomky může oddělovat do různých souborů. Dokonce je mohou spravovat různí lidé. Další problém může být v tom, že s vlastností flex definujete také vlastnost flex-basis. Layout se pak může začít chovat jinak, než čekáte. Stačí, když do něj připluje trošku jiných obsah než jste si představovali - například obrázek namísto textu. Podívejte se na vysvětlení „modelů pružnosti“ na posledním uvedením odkazu. Řešení gridem je jednodušší: .container Prostě jen kontejneru nastavíme display:grid a s pomocí grid-template-columns definujeme, jaké má mít sloupce. K tomu přidáme mezeru gap:1rem. To je vše. Dobrá tedy. Ale znamená to celé, že na flexbox máme zapomenout? Ne tak docela. Kam grid nemůže Důvody, proč já osobně grid preferuji, už znáte. Už také víte, že jsem se přistihl přitom, že se mi špatně představují situace, kdy bych grid nepoužil. Jenže co já vím – kodéřinou se neživím a moje představivost je omezená. Proto jsem se na sociálních sítích na příklady ptal i kolegyň a kolegů. Když jsme takto dali hlavy dohromady, už víme, že obecně může být flexbox vhodnější, když jde o tyto situace: Mám jednosměrný layout a neznámý počet položek v něm. Chci, aby se mé rozvržení přizpůsobovalo délce obsahu uvnitř. Rád bych, aby se položky automaticky zalamovaly, pokud prostoru není dost. Jak už jsem uvedl výše, i tyhle případy se dají vyřešit gridem. Fakt jo. Ale bude to samozřejmě trošku složitější. Vezměme si příklad se štítky. Mám předem neznámý počet štítků: Tag Tag too Tag Štítky se mají zalamovat podle šířky okna. Nechci zde zbytečně nastavovat Media Queries. Řešení flexboxem je jednoduché. Navíc přidám gap, který je elegantnější než margin: .tags Gridem to půjde jen částečně a navíc to bude trošku složitější: .tags Protože máme neznámý počet sloupců, musíme zapojit klíčové slovo auto-fit s funkcí repeat . Dále musíme nastavit šířku podle obsahu, zde díky funkci minmax . Zde prostě gridem pácháme zbytečně složitý kód. A navíc – automatická responzivita zde fungovat nebude. Musíme použít Media Queries, však jde o „grid in“ layout, který musíme mít celý pod kontrolou my jako vývojáři. Na sítích se díky vám naskytlo pár dalších příkladů, kdy je prostě flexbox jednodušší: Zarovnání ikonky v tlačítku Zarovnání formulářových prvků s automatickou responzivitou. Fotogalerie s důrazem na přizpůsobení velikosti obrázků. Kroková navigace, která se přizpůsobuje obsahu a viewportu. Kdo je vítěz? Ono záleží… Jak už jsem psal výše, záleží na situaci. Grid je řešení, které mě ve většině případů vyhovuje, ale pro určité konkrétní rozvržení je evidentně flexbox lepší. Hlavně tam, kde má vládnout obsah, není známý počet položek, chceme automatickou responzivitu nebo jde o skutečně velmi jednoduchý layout. Neměl jsem v úmyslu vás přesvědčovat, abyste se začali grid učit. Ale pokud jsem vám pomohl lépe zmapovat problematiku CSS layoutů, budu moc rád. Cílem článku a celého mého zamyšlený bylo najít hranice. Mít v hlavě jednoduchý rozhodovací strom, kdy je použít flexbox výhodnější. Více se samozřejmě dozvíte v knížce. Budu taky rád, když mi napíšete, pokud byste snad v úvaze našli mezeru a nebyl to gap. Děkuji partnerům Vzhůru dolů. Aktuálně hledají tyto lidi: .
07.02.2023 17:00 V dalším díle podcastu natáčeném v lednu v Productboardu jsem s Honzou Sládkem z Contemberu a některým z vás v publiku přemýšleli nad vlivem novinek ve světě umělé inteligence na práci vývojářů. Rozebírali jsme samozřejmě ChatGPT od OpenAI, Github Copilot, ale padly i další tipy na nástroje jako Replit, Readwise nebo Serenade. Z publika přišly velmi zajímavé dotazy na etiku, legalitu, možnou nerovnost nebo zda to prostě není všechno jen přehnaný hype. Jsou tyhle novinky pro vývojáře hrozbou, pomocníkem nebo čím vlastně? Shodujeme se, že jde o příležitost. Příležitost zbavit se té méně záživné části práce, jako je třeba prototypování nebo rychlá dema. Jde zároveň o příležitost usnadnit si psaní menších částí kódu v jazycích, které zase tak dobře neznáme. Podcast Host: Honza Sládek Honza je Founder & CEO v Contemberu a CTO / UX designer v manGowebu. Dříve běhal orienťáky, vedl WebExpo a můžete si jej pamatovat jako spolupracovníka projektu Rekola pro sdílení kol. Honzu najdete na LinkedInu a Twitteru. O čem mluvíme? Honza a Contember, jak používají AI v podobě asistentky Ember? Co myslíme, když říkáme „AI”? GPT modely od OpenAI. Proč se teď AI/ML tak řeší? Jak to funguje při používání zvenčí, např. přes API? Problém s tím, že AI nemá paměť a vysokých nákladů na provoz Možností využití, např. brainstorming, pomoc s textem, kódem, psaní textů. Github Copilot a pomoc s psaním kódu a textů. ChatGPT a jak může pomoci vývojářům. Blížíme se k vizi Serenade, hlasovému psaní kódu? Viz starší díl. Replit a Ghostwriter: AI asistent přímo pro programátora. Co AI teda může vzít a dát vývojářům a webdesignérům? Pomoc od AI na začátku projektu, s MVP fází a prototypy. Chybovost a půjde ji v rámci vývoje AI vyřešit? Zákaz AI obsahu na StackOverflow a opět ta chybovost. Pomoc AI na konci procesu, sumarizace, dokumentace. Náklady a problémy s nimi. Disruption Theory Dotaz: Co Google a generovaný obsah? Mají se vyhledávače začít bát? Dotaz: Soukromí, bezpečnost a umělci přicházející o práci. Děti školou povinné a AI/ML, kniha AI dětem. Readwise a snadnější učení z textu. Dotaz: není to bublina a hype? Dotaz: co když AI začne dělat klientské změny nebo refaktoring? Dotaz: nebojíme se nerovnosti vzniklé trénováním AI na angličtině? Dotaz: rizika, legalita a kdo má právo řídit, co vrací AI? Fronta na autogramy. :-) Děkujeme za spolupráci Jiří Nečas, Productboard — Vladimír Příhoda, Productboard — Honza Michálek — Johana Kratochvílová, Signatura . 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.
