Plány na podzim: přednášky, newsletter a nové VzhůruDolů.cz
V létě se rodilo a na podzim urodilo. :-) Dovolte mi stručné upozornění na chystané novinky.
Přednášky
Můžeme potkat na třech akcích:
Devel.cz — 9. listopadu se chystám shrnout a okomentovat to nejdůležitější co se za poslední měsíce událo na scéně responzivního webdesignu.
MS fest – 3. listopadu a zase ten responzivní webdesign! Tady to zatím vypadá i na osvětu mezi začátečníky a mírně pokročilými.
Konference WebTop100 je spíše „kravaťácká“ akce. Po ohodnocení pár desítek webů v soutěži přednáška nemohla mít jiný název než… „Pohroma jménem Optimalizace pro mobilní zařízení”. Očekávám, že 7. listopadu dostanu pěstí. :-)
Školení
Je vypsáno hned několik termínů Mobilního a responzivního webdesignu a Dnešního webového front-endu v Praze a Plzni (tam už zbývá jen posledních pár míst).
Newsletter o novinkách webového front-end
Pokud nejste až tak zbláznění do sociálních sítí a shrnutí všeho zajímavého kolem front-end technologií a postupů vám stačí dostávat jednou za čas, přihlašte se k odběru newsletteru. Nebude vám chodit častěji než jednou za měsíc.
A nový blog!
Ano, pracuji na úplně nové verzi VzhuruDolu.cz. Co jako? Proč jako? Nic vám neujde, ale pokud jste zvědavější než stará Blažková, sledujte newsletter nebo Twitter.
CSS preprocesory: Nejspíš nějaký potřebujete a nejspíš je to LESS
O potřebě uvažovat nad jejich výběrem netechnicky jsem už psal na Devel.cz. U Davida Grudla je k nalezení fajn průvodce, jehož vyznění ovšem deformuje autorova velmi specifická sada požadavků na preprocesory. Ony jsou daleko lepší než si může nepozorný čtenář domyslet. ;)
Tady je status quo mého přibližně 3letého přemýšlení o preprocesorech, jejich používání a školení. Za tu dobu proběhly tři fáze:
„Preprocesor je zbytečná komplikace, primitivnost ryzího CSS je přednost!”
„Preprocesor je dost dobrá věc! Ale jen u velkých projektů.”
I ten nejmenší projekt začínám rovnou psát v preprocesoru.
Potřebujete CSS preprocesor?
Je to jako s gitem — čím více lidí sahá do CSS, čím složitější projekt děláte a čím více CSS3 nebo responzivních projektů děláte, tím jistěji preprocesor významně prospěje vaší práci.
Pokud spravujete web strýčkově hospodě, kašlete na preprocesory, stejně jako právem kašlete na git a celé slavné verzování. Je tu někdo takový? Tipuji, že téměř všichni čtenáři Vzhůru dolů preprocesor potřebují.
Co vám CSS preprocesor přinese?
Proměnné, mixiny, zanořování selektorů, matematické operace, jednodušší syntaxi… Prrr! Vykašlete se na technické parametry. Je to jednodušší: CSS preprocesor vám zlepší pracovní postupy. Špatná zpráva je, že si sami musíte vyzkoušet jak přesně.
Jaký CSS preprocesor zvolit?
SASS nebo LESS.
Pokud jste techno-fašoun a individualista, co si nejradši všechno napíše sám, zvolte Stylus. Mnoha lidem (včetně mě) jeho fíčury učarovaly. Bohužel chybí rozumné nástroje kolem něj a autorská komunita je slabá. Původní autor je zřejmě génius, ale příliš plodný na to, aby celý život spravoval technicky nejpokročilejší CSS preprocesor.
Podle čeho CSS preprocesor zvolit?
Podle frameworku…
Pokud vám učaroval Bootstrap, je to jasné — LESS je vaše nová milá. K Foundation zase patří SASS. Lepší je zvolit si nejprve framework. Rozdíly mezi LESS a SASS nejsou tak zásadní.
Podle komunity…
Jste Rails-radioaktivní? Pak už asi dávno používáte SASS a LESSu se arogantně smějete. ;)
Podle stupně geekovitosti…
Neradi příkazovou řádku a učit se novou syntaxi? LESS syntaxe je bližší CSSku a existuje pro něj celá řada UI kompilátorů pro různé platformy. SASS je pro technicky pokročilejší.
A nakonec — proč používám LESS?
Protože Bootstrap. Většinu projektů začínám s pomocí některých komponent Bootstrapu. Při posunech z prototypu k finálním verzím Bootstrap opouštím, LESS zůstává.
Jde dobře začátečníkům. Prakticky na každém školení používáme preprocesor. Zvolil jsem LESS, protože má nejblíž k CSSku, UI kompilátory a českou dokumentaci.
Nicméně — LESS i SASS jsou si relativně podobné. Podobně blbé, chcete-li, protože jednoduché. Furt je to technologie složitostí jen kousek za CSSkem. A tak slušný frontendista neodmítne práci na projektu s týmem, který používá ten druhý preprocesor jako by to nejspíš udělal Pythonista oslovený na práci v péhápku. ;)
Jak tady často zmiňuji, bývá výhodné vrstvit preprocesorem zpracovávaný CSS kód od mobilních (nebo křápovitých) zařízení směrem vzhůru k desktopovým. Problémová děcka, Internet Explorer verze 8 a starší, ovšem nerozumí Media Queries, pomocí kterých vrstvy stavíme. Dá se to naštěstí řešit pomocí preprocesorů.
Na hezkou alternativu řešení mě na nedávném školení pro eSportsMedia přivedl Petr Kysela. Několikrát jsem ji vyzkoušel a nyní prohlašuji, že ji celým svým kóderským srdcem miluji.
Body třída, cože?
Body třída neboli body class. Zkušenější vědí. Ostatním pomůže kus HTML kódu:
↳ Díky přítomnosti třídy .old-ie pak v CSS kódu můžeme všechny osmičkové a starší Explorery zacílit krásným selektorem typu .old-ie .selektor. Nepostradatelná technika.
Body třídy a responzivní Mobile First
Pomocí preprocesoru a selektoru z body třídy teď můžeme krásně zacílit starší Explorer a například mu pošeptat: „Brachu, vykašli se na fluidní layout. Vím, že se u něj zadýcháváš. Chci po tobě jen fixní rozměry.” —
Výhodné to je například na webech, kde používáme nějaké to Background Size, které osmičkový Explorer nepodporuje.
Teď už víme dost, abychom porozuměli následujícímu LESS kódu a podstatě tohoto článku:
.nav { .nav-small-screen; // Verze pro velke displeje @media (min-width: @largeScreenStart) { .nav-large-screen; } // Verze pro IE8- .old-ie & { .nav-large-screen; } }
↳ Stejný kus kódu, který věnujeme zařízením s určitou minimální šířkou velikosti okna (velké displeje), tedy předložíme i Exploreru ve verzi 8 a starších.
Kód by samozřejmě mohl být elegantnější, kdyby LESS uměl spojit media query (@media (min-width: @bigScreenStart)) se selektorem body třídy (.old-ie &) do jednoho selektory. Jenže to by pak bylo moc jednoduché. Není důvod nevěřit, že tuhle drobnost vývojáři LESSu dříve či později vyřeší.
Využíváme síly LESSu a mixin .nav-big-screen si nadefinujeme někde bokem. Jeden kus kódu využijeme na více místech. Už jsem vám říkal, jak úžasné jsou mixiny a že preprocesory prostě musíte používat?
Jaké breakpointy zvolit v responzivním webdesignu?
Stručná odpověď: Vezměte třeba ty co používá Bootstrap.
Pokud ovšem Bootstrap nebo jiný front-end framework nepoužíváte a první responzivní weby máte za sebou, jediná dobrá odpověď zní:
Zapomeňte na breakpointy.
Ukážeme si, proč není vhodné breakpointy používat pro detekci zařízení a proč nedávají smysl pro stránku jako celek.
Pozor, Media Queries neslouží k detekci zařízení. Slouží k úpravě zobrazování obsahu, když v nějakém rozlišení obrazovky hapruje. #rwd
February 22, 2013
Media queries a detekce limitů obsahu
Věřte mi, detekovat zařízení pomocí media queries je velmi nespolehlivé:
480px široký může být starší iPhone v landscape módu nebo úplně nový křápovitý Android tablet držený na výšku
Kolem 800px máte iPad na výšku nebo třeba Nokii Lumia 800 na šířku.
Mohli bychom pokračovat. V jednom rozlišení pomocí media queries detekujete zařízení s velmi odlišnou fyzickou velikostí a odlišnými způsoby používání.
Daleko lepší je soustředit se na obsah a používat media queries k úpravám jeho formy pro různá rozlišení.
Mikrobreakpointy místo breakpointů
Definice responzivního webdesignu pro zelenáče zní asi takto: „Nakóduj si layout ne v pixelech, ale v procentech. Layout zvětšuj a zmenšuj s oknem prohlížeče. Až se ti v nějaké šíři okna rozsype, neházej myš do žita, pomocí media queries rozsypanost opravíš.”
Jenže ona se vám skoro nikdy nerozsype celá stránka. Vždy jen její konkrétní část — hlavička, tělo dokumentu, navigace… Nepotřebujete tedy upravit layout stránky, jen layout konkrétní části. Říkám mu mikrolayout.
A pak namísto breakpointů můžeme používat mikrobreakpointy. Breakpointy pro změny formátování konkrétní části stránky, mikrolayoutu.
Čisté CSS a responzivní webdesign nejsou kamarádi
Dobře, už víme, že použití media queries k detekci zařízení není úplně vhodné. Zaměříme se na obsah stránky a jeho konkrétní části. Dává to smysl. Proč ale část webařů hledá breakpointy, nejlépe univerzálně použitelné napříč projekty?
Myslím, že jeden z důvodů, proč takhle weboví technici uvažují, je používání CSS v responzivním webdesignu. Specifikace CSS3 sice zanořování Media Queries umožňuje, ale to právě teď podporuje jen Firefox a Opera.
Aktuální implementace CSS bez zanořování svádějí k zápisu podobnému tomuto:
Vidíte? CSS nás „nutí” kód rozdělit do několika logických kategorií na základě hodnot v media queries. Odtud už je jen krok k uvažování nad globálními breakpointy.
Ještě markantněji to uvidíme v HTML zápise:
<link href="default.css" rel="stylesheet"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 481px) and (max-width: 1023px)"> <link href="smartphone.css" rel="stylesheet" media="screen and (max-width: 480px)">
Pokud bychom ovšem s pomocí některého CSS preprocesoru předběhli čas, zanořovací vychytávku CSS3 využijeme ve všech prohlížečích. Přidáme silnou touhu po rozumné spravovatelnosti kódu a media queries budeme používat v kontextu části obsahu, kterou právě stylujeme:
.nav { /* … */ /* Formatovani navigace tam kde se nevejdou zalozky vedle sebe */ @media screen and (max-width: 560px) { /* … */ } } .content { /* … */ /* Formatovani obsahu tam kde se nevejdou dva sloupce */ @media screen and (max-width: 900px) { /* … */ } }
A je to. Media queries patří k obsahu. Globální breakpointy jsou pryč a s nimi i touha detekovat s jejich pomocí skupiny zařízení.
Důvodů, proč se media queries mylně používají pro detekci zařízení a webaři uvažují o breakpointech je samozřejmě víc. Vybral jsem tenhle, protože ukazuje jak pouhá snaha o dobře spravovatelný kód může ukázat na problémy v obecném uvažování o webdesignu.
A taky ukazuje, že responzivní webdesign se bez CSS preprocesorů kóduje velmi špatně. Ponaučení? Šup pro preprocesor!
O řešení pro obrázky si už cvrlikají i responzivní vrabci na střeše, jenže pokud chceme do stránky vkládat Youtube videa nebo třeba mapy, musíme na to jinak. Pro elementy <video>, <iframe> nebo <object> používám staré řešení proporciální změny velikosti elementu.
V HTML musíme element musíme nejdříve obalit stylováníhodným rodičem:
<div class=”rwd-media”>
<iframe>…</iframe>
</div>
V CSS pak flexibilnost elementu a zároveň zachování poměru stran zajistíte takto:
Věnujte pozornost hodnotě padding-bottom u první deklarace. Alergici pozor! Zvýšený výskyt matematických výpočtů! Snad to ale nebude moc bolet, potřebujeme jen vypočíst procentuální hodnotu, která definuje poměr stran. V tomhle případě 16:9. Výpočet tedy vypadá takto: 9 / 16 * 100 = 56.25.
Pokud máte na stránce embedovaných médií moc a nevadí vám další kus javascriptu, problém automaticky řeší i jQuery plugin FitVids.
Kuk na příklad na Codepen.
Dočasná nutnost serverové detekce mobilních zařízení
Serverová detekce zařízení pro účely úpravy prezentace obsahu není žádná ostuda. Je to nutnost, často i u malých webů. Tam zřejmě jen dočasná.
1) Vkládaný prohlížeč fotek z Flickr.com
Ten vkládáme do stránky apartmánu v desktopové verzi. Prohlížeč je moc pěkný, ale postavený na Flashi, takže velká část uživatelů mobilních zařízení na tomto místě obsah neuvidí. Mobilistům a tabletistkám namísto Flashe tedy nabízíme tlačítko s odkazem na HTML5 slideshow přímo na webu Flickru, která je optimalizovaná i pro mobilní zařízení. (plný kód, web)
<?php if ($detect->isMobile() and !$detect->isTablet()): ?> <a class="button" href="http://www.flickr.com/photos/machal/…"> Fotogalerie na Flickr.com </a> <?php else: ?> <object class="flickr-embed"> … </object> <?php endif; ?>
2) Vkládané Google Mapy
Klasický příklad. Na desktopu moc užitečné, ale na mobilních zařízeních náročné na výkon, rychlost stahování a s komplikovaným uživatelským rozhraním jako bonusem. Na smartphonech tedy opět nabízíme tlačítko s odkazem přímo na maps.google.com. Jejich uživatelé si mohou vybrat zda mapu otevřou v prohlížeči nebo luxusním prostředí mapové appky. (plný kód, web)
3) Odříznutí křápů a šedivých myší od složitějších technologií
Křápem myslím hodně staré nebo špatně vybavené mobilní zařízení. Třeba Nokia E50. Šedivé myši mohou být vybavené obstojně, ale nemáme je zatím moc dobře osahané a tak jim raději složitější vrstvy front-endu webu neposíláme. Třeba zařízení s Windows Phone 7.
Na svých projektech postupuji z druhého konce – definuji si bezpečnou zónu, ve které jsou zařízení, s jejichž prohlížeči jsem v přátelském vztahu. Typicky jsou to Android zařízení od verze 2.2 a iOS zařízení. S detekcí na straně serveru nám pomůže knihovna Mobile Detect. (Pro zájemce, zde je moje sada nejjednodušších testů.)
A co jsou ty složitější vrstvy front-endu? U každého projektu trošku něco jiného, ale v třeba případě takhle malého webu všechny javascripty. Weby vytvářené pomocí progressive enhancement (Mobile First chcete-li) javascriptová vrstva vylepšuje, ale dají se hezky používat i bez ní.
Ve starších nebo neznámých mobilních prohlížečích takhle zabráníme katastrofám, které mohou číhat v našem javascriptovém kódu:
<?php if (!$is_dumbphone): ?> <script type="text/javascript" src="js/index-production-ck.js"></script> <?php endif; ?>
Všimněte si, že uživateli serverovou detekcí ve všech případech nijak neovlivňujeme obsah stránky. Optimalizujeme prezentaci obsahu pro jeho zařízení.
„Dočasná”?
Jsem docela přesvědčený, že dříve nebo později tyhle tři scénáře půjdou řešit jinak a serverovou detekcí si jen usnadňujeme práci než vymyslíme něco lepšího.
Dodavatelé vkládaného obsahu myslím dost usilovně pracují na tom, aby mobilní zařízení uměli nadetekovat sami a poslat mu lepší prezentaci obsahu. Někde se to daří lépe (YouTube), někde jim zatím musíme pomoci.
Odřezávat křápy a šedivé myši od složitějších technologií časem snad přestane být nutné. Ale tohle bude trvat rozhodně déle. Trh mobilních zařízení je všechno, jen ne konsolidovaný.
Nezapomeňte mrknout na první díl seriálu – o strukturování Mobile First CSS pomocí preprocesoru Stylus.
↳ Nejprve importujeme knihovnu nib, která obsahuje CSS3 mixiny a další vychytávky. Je to takový slabší odvar Compassu.
Poznámka na okraj — Stylus má úžasné možnosti a naprosto boží syntaxi (volitelně i takhle minimalistickou), ale zatím hrozně slabou komunitu a celý ekosystém. A pokud vám — jako mě zpočátku — vadí přílišný odklon od zvyklostí v CSS, garantuji, že za 10 minut se sami sobě budete divit.
@import 'base'
↳ Základna base.styl obsahuje normalizující (nebo resetující) deklarace, nastavení písem a barev pro dokument. Vše přiřazujeme běžným HTML elementům, pro selektory v podobě CSS tříd na této úrovni není místo.
@import 'helpers'
↳ V pomocných třídách helpers.styl mívám všechny pomocníky co neobsahuje používaná knihovna — nib. V tomhle případě jen nějaké zarovnávání textu nebo schovávání elementů v různých zařízeních a old skůl resetování floatů.
@media print @import 'print'
↳ Máme uspokojivý vzhled dokumentu a nějaké základní barvy. Tedy přesně to co bychom uživateli mohli nabídnout jako verzi k tisku ještě předtím než přidáme složitosti pro screen media. V print.styl samozřejmě povypínáme vše co uživatel nepotřebuje tisknout.
@media screen @import 'screen'
↳ Ani indexový stylopis pro screen na tomhle miniwebíku žádné pokročilejší CSS neobnáší. Definujeme tady jednodnosloupcový layout pro všechna zařízení s displejem.
Pokud chcete aby tuhle vrstvu zpracovaly i opravdu staré křápy (a já vám to doporučuji), nepoužívejte tady žádné novější CSS techniky typu clearfix.
Tohle je předposlední vrstva stylů pro pokročilejší mobilní a současné desktopové prohlížeče a zároveň finální stylopis pro starší zařízení s displejem jako je Nokia vaší babičky nebo MSIE5 vašeho dědečka, takže k nim buďte hodní.
Všimněte si, že pro screen nedefinujeme téměř žádné rozměry layoutu. Proč taky? Vůbec nevíme jak velký displej to zařízení bude mít. Web tak bude použitelný i bez layoutu.
@media screen and (max-width: 480px) @import 'screen/mobile'
↳ A máme tady první CSS3 Media Query a v ní mobile.styl s několika výjimkami pro malé displeje smatphonů.
@media screen and (min-width: 1000px) and (min-height: 600px) @import 'screen/desktop'
↳ V úplně nejvyšší vrstvě je desktop.styl, kde definuji zejména rozměry původního desktopového layoutu. Vzhledem k tomu, že layout se ve viewportu vertikálně i horizontálně centruje, pomocí takto specifické Media Query poprosíme prohlížeč o její aplikování jen v případě že je tady pro něj dostatek místa.
Pokud jste pozorně četli Mobile First v CSS, pak už víte, že stylopis pro osmičkový a starší Explorery bude vypadat asi takto:
Naživo viz ie8-.styl.
Když se znovu podíváme na centrální stylopis projektu, neodpustím si ještě jednu poznámku na okraj k CSS preprocesorům: Pokud jste se někdy pokoušeli zorientovat v cizím (nebo vlastním starším) CSS souboru, asi budete souhlasit, že dělení stylopisů do „parciálů” a jejich importování do jednoho malinkého samovysvětlujícího indexu je jedna z jejich mnoha killer vlastností.
Díky za pozornost a těším se naviděnou u dalšího dílu seriálu, kde se podíváme na zuby serverové detekci zařízení. A řekneme si, proč ji potřebujeme i u takhle malého projektu.
Když kódujete web pro mobilní zařízení a desktop zároveň, klasický responzivní webdesign vás učí takovémuhle kódu:
/* Tady bude veškeré CSS pro desktop… */ @media screen and (max-width: 480px) { /* CSS pro malé displeje */ @import 'mobile.css'; }
Netvrdím, že to není někdy dobrý postup, ale vadí mi na něm dvě věci:
„Přednastavená” verze je desktopová. Ano, to je ta, na které si můžete dovolit technicky nejpokročilejší řešení. Křápy typu špatný mobilní prohlížeč, tiskárna nebo IE7 od vás mohou paradoxně dostat nejsofistikovanější CSS.
V mobile.css budete muset sofistikované řešení desktopu přebíjet nesofistikovaným. Nevím jak vám, mě osobně se takový kód píše a spravuje docela špatně.
Mobile First
Kód nejprve pro mobilní zařízení vypadá opačně, zjednodušeně takto:
/* Tady bude společná CSS základna pro křápy, mobilní zařízení a všechny ostatní: normalizace, typografie, barvy…*/ @media screen and (min-width: 1024px) { /* CSS pro velké displeje */ }
Nejprve navrhneme řešení pro křápy a Media Queries použijeme jako podmínky pro zobrazení vylepšujících CSS deklarací. A taky jako filtr pro odstřižení opravdu starých křápů, které je neumí. V CSS základně tedy máme jen relativně bezpečné CSS, který by mohly zvládnout i vskutku natvrdlé prohlížeče.
Tohle řešení má jednu nevýhodu: starší desktopové prohlížeče neumí CSS3 Media Queries a proto jejich obsah nepřečtou. Nejvíc nás to pálí v případě Exploreru verze 8, případně ještě 7.
Pokud ostatní prastaré desktopové prohlížeče dostanou vzhled webu bez desktopového rozšíření, tím líp. V desktopovém CSS se tak nemusíme bát používat pokročilejší techniky.
Problém s MSIE8 a staršími můžeme vyřešit pomocí polyfillu Respond, který v nich Media Queries „rozchodí”. Jenže závislost na javascriptu právě v tomhle případě nemusí být to co chcete.
Mobile First řešení s využitím CSS preprocesorů
Chytřeji to vyřešíme s kombinačkami v podobě CSS preprocesorů v ruce. Vezměme třeba LESS. Založíme dva soubory, do kterých se budou importovat naše „CSS parciály”. Po každé úpravě v parciálu se zkompilují oba soubory, index.less i old_ie.less:
Exploreru 8 a starším takto naservírujeme desktopový stylopis z desktop.less ještě jednou bez Media Queries. Jejich obsah bude IE8 v původním index.less ignorovat.
Zůstává jen malá nevýhoda: starší Explorery musí dvakrát načíst obsah desktop.less. Pokud ovšem komprimujete CSS, může jít jen o jednotky kilobytů stažených dat.
Podívejte se na konkrétní řešení: Mobile First pomocí preprocesoru Stylus.
Známých řešení v tomto duchu existuje více. Například:
Jeremy Keith: Řešení bez preprocesorů
Nicolas Gallagher: SASS a podmíněné komentáře pro starý i nový Explorer
Úplně nový je HTML5/CSS3 workshop, který se na základě vašich častých požadavků vyloupl z původního Snadnějšího života na front-endu. Jde o ryze praktickou dílnu, kde se ponoříme do hloubky rodiny technologií zmíněných v názvu. Pokud kolem HTML5/CSS3 zatím pošlapujete spíše nesměle nebo vůbec, tohle je vzdělávací akce pro vás.
22. března, Root Akademie, Praha
16. dubna, Webexpo Academy, Praha
Úspěšný kurz Snadnější život na front-endu (loni se uskutečnilo 7 veřejných termínů) se nově jmenuje Dnešní webový front-end. A jako jde předchozí workshop do hloubky, tohle školení se naopak tématicky rozptyluje do šířky. Prolétneme HTML5, CSS3, preprocesory, Twitter Bootstrap, WAI ARIA, rychlost načítání a další. Ideální pro všechny co delší dobu nesledovali novinky. Interní název zní „Front-end update”.
7. března, Plzeň
14. března, Root Akademie, Praha
9. dubna, Webexpo Academy, Praha
A v neposlední řadě vás zvu na veřejné termíny Mobilního a responzivního webdesignu pro vývojáře, kde se zblízka díváme na zuby asi největší změně prostředí v historii našeho oboru a učíme se technologie a pracovní postupy, které nám pomáhají na ní reagovat.
29. března, Root Akademie, Praha
23. dubna, Webexpo Academy, Praha
Všechna témata je samozřejmě možné připravit na míru vašim firemním potřebám jako inhouse školení. Pokud vás to zajímá, pište na [email protected].
Seznam profesní četby co mi prošla Kindlem za loňský rok seřazený od nejhoršího kousku k tomu nejlepšímu.
Responsive Web Design — Ethan Marcotte
Téma loňského roku, řekl bych. Ale myslím, že dnes už vám bude stačit přečíst si pár článků. Máte za sebou? Knížku si nekupujte. Ethan nejde moc za klasický responzivní webdesign. O tom si myslím, že nám dnes už nestačí.
Scalable and Modular Architecture for CSS (SMACSS) — Jonathan Snook
Autor má velké zkušenosti s organizací uživatelského rozhraní do znovupoužitelných modulů. Číst to je nuda, ale i tak u mě SMACSS způsobil v kombinaci s Idiomatic CSS a adaptací CSS preprocesorů do vývojařské praxe převrat ve způsobu organizace kódu. Doporučuji každému kdo dělá ve větší firmě nebo na dlouhodobějších projektech.
Adaptive Web Design — Aaron Gustafson
Progessive enhancement od jeho – myslím – největšího propagátora. Výborné téma, výborně zpracované. Jenže… Čtu už půl roku, ale stále nejsem na konci. Progressive enhancement si to věčné vytlačování aktuálními tématy fakt nezaslouží. Myslím, že patří do DNA front-end vývojáře.
Mobile First — Luke Wroblewski
Průlomová knížka samozřejmě. A jediná ze seznamu bez řádky kódu. Pokud myšlenky kolem mobilního webdesignu moc nesledujete, určitě si ji pořiďte. Článek ani recenze tady nestačí. Doporučuji úplně všem co umí najednou vyslovit slova „web” a „design”. Wroblewski do našich malých hlav sadí velké brouky, kteří myslím vylezou až za pár měsíců nebo let. A jsem přesvědčený, že nositelé těch co vylezou dříve, budou mít velkou výhodu.
The Truth About HTML5 — Luke Stevens
Pro mě nejlepší technická knížka vůbec. Nekecám. Je to koláž poskládaná z méně známých technikálií kolem HTML5 (nikoliv CSS3, pozor), inspirativních ukázek použití a jejich historie zasazené do kontextu vývoje webu. A nejdůležitější věc: Autor není žádný přežvýkávač referenčních příruček a webařský frikulín. U podstatných částí HTML5 poctivě analyzuje jejich přínos a vychází mu tak dost zajímavé názory. Pokud například chcete hlubší argumentaci, proč HTML5 elementy stojí za starou bačkoru než tu moji, zeptejte se jeho.
A teď call to action do komentářů: Holky a kluci, jaké knížky loni zaujaly vás?
HTML5 strukturální elementy stojí za starou bačkoru
Naštěstí se velká většina webařů pohybuje někde mezi. Jenže když si s lidmi povídám o HTML5, převažuje nezdravé a nekritické nadšení pro cokoliv. Jako obvykle. Pro účel zavedení modulu pochybnosti do nadšených hlav tedy na chvíli přetransformuji do techno-bručouna. Míra arogance odpovídá délce fousů, bacha na něj.
Tak…
V klidu si, vy hrotiči, sedněte, neodbíhejte teď posílat nadšené výkřiky o HTML5 na Twitter, zavřete si to okno, ze kterého normálně křičíte: „HTML5 růluje!” a poslouchejte co vám řeknu.
HTML5 strukturální elementy stojí za starou bačkoru.
K ničemu nejsou a všechny jenom otravujou.
Jo, bavím se o vás, <article>, <section>, <nav>… Vy další, neschovávejte se, vidím vás!
Důvod první: MSIE8 a Javascript
Ne, osmičkový Explorer není mrtvý. A pokud ve verzi 8, 7, 6… chcete do DOM dokumentu vložit HTML5 stukturální elementy, musíte použít kousek javascriptu. A když na stránce javascript selže… Stane se něco strašného. DOM vypadá úplně jinak. Takže vaše slavné přeplácané CSS/jQuery selektory jsou víte k čemu. A chudákovi uživatelovi se stránka rozsype hrozivým a děsuplným způsobem. Ne tak jako když se mu tam něco o pár pixelů posune. Takhle:
„Nojoo, jenže MSIE8 teď má 18%ní zastoupení. Pokud Javascript nemá zapnutý 2% lidí, je to na našem webu denně přesně 2,5 uživatele.”
Dobře, vezmeme to, vy bando, popořádku. Úplně na začátku se musíme podívat na seznam výhod HTML5 stukturálních elementů:
Zpřehledňují HTML kód. Trochu.
Toť vše. Napadá vás víc?
Sémantika — výhoda co neexistuje
Pojďme zkusit najít nějakou další výhodu <section> a spol — co sémantika? Hm… O sémantice můžeme mluvit třeba v kontextu přístupnosti. Navigaci označím jako <nav> a čtečka slepému uživateli nabídne skok rovnou sem. Skvělé!
Skvělé? Hele, mladej, klid, jo!? Z prohlížečů tohle implementoval jen Firefox. Upřesnění: Za pět let existence nových strukturálních elementů je do Accessibility API implementoval jen jeden výrobce prohlížeče. To je docela bída na to, že výrobci prohlížečů se z HTML5 můžou potrhat a nové verze vycházejí co pár týdnů, co?
Jestli ono to nebude tím, že tyhle přístupnostní fíčury HTML5 už dost dobře umí WAI-ARIA landmarky. A umí jich daleko víc než mohou umět strukturální elementy.
Tak ještě jeden pokus o výhodu — osnova dokumentu
Do HTML verze 4.0 se osnova (document outline, hodí se zase hlavně pro přístupnost) dala vytvářet jen pomocí značek pro nadpisy. Vezměme tenhle dokument:
<h1>Maxipes Fík</h1> <p>Přerostlý pes.</p> <h2>Co jím</h2> <p>Dorty a pošťáky.</p>
Při tvorbě osnovy bychom tedy nebyli odkázaní na strukturu nadpisů. A nemuseli bychom myslet na aktuální úroveň nadpisů (h1-h6). To by se mohlo hodit programátorům při inkludování jednoho modulu na různé úrovně zanoření ve stránce. Malá výhoda, ale výhoda.
Jenže, bando frikulínská, HTML5 osnova dokumentu má na problémy zaděláno. Jedním z nich je dost problematická zpětná kompatibilita. A vůbec:
"IMO the outlinealgorithm is dead and we could simplify HTML by dropping [hgroup and section]". I'd drop article too. lists.w3.org/Archives/Publi…
— Roger Johansson (@rogerjohansson) December 14, 2012
Takže…
HTML5 elementy by za cenu atomovky pro pár uživatelů MSIE8- bez javascriptu mohly být v některých situacích fajn, kdyby:
nahradily WAI-ARIA tam kde je nahradit mohou
umožnily vytvářet lepší osnovu dokumentu
Jednoduše: …kdyby uživateli poskytly nějakou výhodu. Jenže neposkytly.
Věřte mi, holoto, HTML5 elementy doteď k ničemu nebyly a všechny jenom otravovaly. Chybí jim implementace a 5 let je v prohlížečových implementacích celá epocha.
HTML5 je obrovská rodina skvělých i méně skvělých technologií a hold ne všem členům famílie bude dopřáno, aby přežili batolecí léta. Tak už to v džungli chodí, no. Tipuji, že strukturální elementy v HTML5 skončí tam kde dneska sladce spí <font>, <blink> a celá ta věc kolem XHTML.
Související čtení:
Luke Stevens: The truth about structuring an HTML5 page
Implementace tak ve výsledku používá nejnovější prostředky dostupné na webu, což má za nepříjemný následek, že třeba Internet Explorer 9, stále aktuální verze, není plně podporována (stejně tak Chrome na Linuxu a trochu problematická je i Opera). Je to poměrně velký kompromis, ale šli jsme do něj, protože aspoň nějakou implementaci máme pro všechny browsery (když nejsou dostupné 3D transformace, použijeme pomalejší 2D, a když ani ty nejsou dostupné, obrázky se staticky napozicují a animace se nekonají) a do budoucna předpokládáme, že podpora 3D transformací bude rychle narůstat.
— píše Borek Bernard ve Zkušenostech z vývoje WebShotteru. Sami se na ten Time Machine efekt podívejte. Cool co? Dobře, na volbě technického řešení se tady asi výrazně promítlo, že si autoři chtěli vyzkoušet HTML5 technologie. Nicméně z čistě technického pohledu vznikla moc hezká odpověď na otázku: „Proč používat nové technologie když nefungují ve starých prohlížečích?” Zní: „V každém prohlížeči něco funguje.”
To think about the web responsively is to think in proportions, not pixels.
— Trent Walton. No jistě. Dodám jen dvě myšlenky:
Nejen responzivně. Stejné platí u „neresponzivních webů”. Protože webový = responzivní. Vizualita dnešních webů je postavená více na typografii a grafickém obsahu jako jsou fotky nebo videa. A méně na drobných grafických oddělovačích, vylepšeních, ornamentech. (Kolik jich najdete na novém Microsoft.com? Ano, žádný!) A tak méně lpíme na ujeté pixel-perfektnosti a zůstává nám správnější lpění na proporcích a jejich souměrnosti.
A pak… S pixely je v responzivním webdesignu hrozně práce. Dvakrát, třikrát, čtyřikrát definovat rozměry jednoho elementu pro různá zařízení je hrozně blbá práce s blbým výsledkem. Nemusíte skončit zrovna u elastického layoutu, ale vsadím se, že ten divný pocit kolem jednotky px sdílíme všichni.
Bude to rok co jsem se rozhodl učit a tak ještě než vás pozvu na poslední tři letošní veřejná školení není od věci zhmotnit pár myšlenek, kterým nové lektorská část osobnosti pomohla na svět.
Drahý a pomalý vývojář, to je něco špatně
Někdy loni jsem si definitivně uvědomil, že pokud budu dál dělat vývojařinu stejným způsobem (s neustálým experimentováním a zkoušením novinek, snad i poctivě), bude ze mě drahý a pomalý front-end vývojář. Řešení byly dvě: buď potlačit to co mě na práci baví nebo znalosti ze svého způsobu práce získané uplatnit způsobem, který ocení jiní. První cesta by znamenala jistější obživu, ale na jejím konci by byl další protivný čtyřicetiletý ajťák. Drahý a pomalý musí předávat dál. A jelikož si volné nohy cením, padlo rozhodnutí na veřejná a firemní školení.
Místnost s 10 lidmi jako validátor myšlenek
Každý lektor vám řekne, že se během školení sám ohromně vzdělává. Nejlepší pro to jsou školení, na kterých účastníci živě reagují. Zcela bez ironie — ideální účastník je ten co se nebojí skočit do řeči. Nevěděl jsem ale, že se toho hodně naučíte i když lidé nereagují. I když mluvíte jen vy. Věta co vyletí do místnost kde poslouchá deset lidí má úplně jinou váhu než když ji nosíte v hlavě nebo řeknete kamarádovi v hospodě. Pokud je věta padlá na hlavu, sami poznáte, že nefunguje, i přesto že lidé nereagují slovy. Na přednáškách tohle neplatí. Přednášky mezi lektorem a ostatními vytvářejí příliš velkou bariéru.
Neexistuje hotové školení
Staří ne-weboví kamarádi říkají: „To si jednou to školení připravíš a pak už jenom opakuješ. To je byznys!” Přesně by ovšem byl způsob jak: 1) Dělat byznys špatně (konec inovací, konec byznysu) 2) Učení pekelně zprotivit sobě a všem přítomným. Neexistuje hotové školení. Každé nové je iterace na cestě k dokonalému zvládnutí tématu. A dokonalost je jak známo vlastností bohů, nikoliv lektorů. ;)
Tolik k myšlenkám, které uzrávaly na 6ti letošních veřejných školeních. Listopad je nabitý termíny dalších tří. Na prosinec a větší část ledna plánuji menší školící odstávku, takže pokud se chcete vzdělat v současných front-end postupech a technologiích jako HTML5, CSS3 nebo způsoby jak se vypořádat s nástupem mobilních zařízení na vaše weby, neváhejte dlouho:
Listopadová front-end školení
Čtvrtek 8. 11. — HTML5, CSS3 a snadnější život na front-endu ve Webexpo Academy
Úterý 20. 11. — HTML5, CSS3 a snadnější život na front-endu v Akademii Root
Pátek 30. 11. — Mobilní a responsive webdesign pro vývojáře v Akademii Root
Komentář k anketě „Jsou weby co vytváříte vždy responzivní?”
Ve včerejší Twitter anketě se nashromáždilo téměř 160 odpovědí (díky za ně!), takže výsledky už stojí za krátké zamyšlení. Můžete je zkusit interpretovat sami. Nebo čtěte dál.
Ale nejdříve ze všeho se musím přiznat, že jsem úmyslně zatajil něco zásadního. Anketa je kopií stejné od Smashing Magazine. Kromě stavu responzivního webdesignu (RWD) v CZ/SK rybníku mě ještě více zajímalo srovnání se světem.
Ano, srovnáváme odlišné skupiny, protože český Twitter není tak rozšířený i do méně technologicky progresivních skupin webařů. Je na něm tedy více early adopters a anketa by ve fázi „Twitter vyspělosti” srovnatelné se čtenáři Smashing Magazinu dopadla určitě více v neprospěch adopce responzivního webdesignu.
Srovnání je tady:
Rozdíl je velký, co? Je jasné, že v technologických trendech jsme více či méně pozadu, takže tím se trápit nebudeme.
Největší překvapení pro mě je vysoký podíl odpovědi „jen pokud to klient chce”. Neukazuje to nějakou zdejší přílišnou opatrnost v nabízení technologických novinek? Kolem RWD je i v ČR tolik povyku, že marketing máte zadarmo, na webu se povalující argumentaci stačí vypilovat pro potřeby konkrétního klienta a ten se těžko v takové situaci bude divit, že v takovém případě musí rozpočet trošku přifouknout. Proč tak 55% „respondentů” dobrovolně promarňuje obchodní příležitost? Třeba mi to pomůžete objasnit v komentářích.
Dobré zmínit, že jsem do české verze nedal možnost „Záleží na situaci”, což mi ti bystřejší omlátili o hlavu, ale v číslech by to myslím nehrálo velkou roli.
Je to pikantní, protože bych si tu možnost sám vybral. Moje chování se totiž při nabízení RWD varianty webu mění podle potřeb klienta, ale samozřejmě i v čase. Za poslední dva roky jsem byl několikrát u rozhodnutí, kdy jsme responzivní design zavrhli, ale variant těch situací v čase docela rychle ubývá.
Ještě jednou díky všem za vyplnění nebo retweet ankety a jsem zvědavý co při pohledu na tabulku napadá vás.
Idiomatic CSS je sada zásad, které vám pomohou psát CSS kód přehledněji, srozumitelněji, krásněji… jednoduše spravovatelněji.
Nejvíc řekne jednotící myšlenka:
Veškerý kód v jednom projektu by měl vypadat jako by ho napsal jediný člověk. Bez ohledu na to kolik lidí přispělo.
Tahle CSS styleguide je samozřejmě ideální pro větší projekty s více vývojáři nebo cokoliv opensource. Ale výrazně ji doporučuji i těm co na projektech píší CSS sami. Klasická poučka spravovatelnosti hlásá, že nejpřísnější pohled na vlastní kód má jeho autor ve chvíli kdy se k němu po třech měsících vrátí. To asi znáte na vlastní kůži.
Idio… matické?
Lingvistický idiom možná znáte, ale co to má znamenat ve vývoji software? Idiom je část kódu jež využívá prostředky jazyka, ale není součástí jeho specifikace a snaží se řešit problém nejobvyklejší možnou cestou. Idiomatické způsoby organizace tedy vycházejí z nejobvyklejších způsobů organizace aniž by řešily zda jsou optimální. Obvyklé a konzistentní je lepší než dokonalé.
Z velké části je moje vzplanutí k Idiomatic subjektivní – našel jsem v něm většinu svých léta ověřených postupů: Vyhovuje mi, že i když rozšiřuje SMACSS, odstraňuje některé jeho nedostatky (máme společnou averzi vůči zkratkovitým pojmenovaním modulů) a z preprocesorů bere v potaz můj oblíbený LESS. Na to nehleďte, užitečný pro vás Idiomatic bude i když nic z toho neznáte.
Nedokonalé, ale nejlepší dostupné a… česky!
Pár výhrad sice mám (občas postrádá smysluplnou argumentaci, je moc ukecaný a jde více o doporučení pro tvorbu styleguide než styleguide samotnou), ale potřebu konzistentního způsobu organizace napříč projekty mám docela silnou a nic lepšího aktuálně kolem sebe nevidím. Přeložit Idiomatic pro mě prostě bylo efektivnější než se pouštět do formalizace vlastních pravidel.
Pull request mého překladu minulý týden Nicolas Gallagher přijal do hlavní větve a tak si jej teď můžete přečíst v mateřštině. Dobrou chuť. ;)
…it’s not an academic understanding you need. It’s a reflective first-hand feeling for how your own eyes react to the screen and how the words play out in your own head as you skim the page. Try to become more sensitive to these experiences by being more aware of them. Then you can make more effective designs.
Ryan Singer ve výborném rozhovoru na .net o vlastnostech, které jsou potřeba k návrhu dobrého uživatelského prožitku. Moc sympatické, protože chybí všechny buzzwordy UX vědy a namísto toho zdůrazňuje „normální” lidské přednosti: schopnost naslouchat vlastní intuici, porozumění uživatelům svého produktu a umění empatie. Ve světě kde UX = vědní obor mi udělal velkou radost.
