KODÉR.BLOG

Responsive - s odstupem pár let a několika desítek webů z pohledu kodéra

18 Aug 2014

Nebudu vysvětlovat co je retina, pro jaké zařízení ladím nebo co kde funguje / nefunguje, na to je totiž článků po internetu opravdu hodně, budu se věnovat hlavně tomu, jak by se nad jeho tvorbou měl (nejen) vývojář zamyslet, jak nad tím přemýšlím já a zároveň jak co řeším, pokud s něčím nebudeš souhlasit, tak komentáře jsou přesně pro tebe otevřeny :)

Zadání

Je jedno zda se na web uživatel kouká doma, kde má 27” iMac s rozlišením 2560×1440 a nebo na tramvajové zastávce na Sony Xperia Mini s rozlišením 480×320 (jojo, taky mě ta představa pobavila, že by neměl iPhone), kde hlavně stařičký Android 2.3 dělá vrásky nejednomu vývojářovi.

Obrázky a retina


Téma které se opakuje stále dokola, pořád se řeší detekce, načítání různých obrázků, výměna obrázků pomocí JS a podobné IMHO krávoviny, které jako 100% řešení nikdy nejsou! Co si budeme nalhávat u menších projektů nebo tam kde se šetří časem, penězma a nikdo nezaplatí kodérovi jeho know-how se na tohle kašle, ale na novém Socialbakers webu, který kóduju, si můžu dovolit řešit věci, tak jak si myslím, že se řešit mají.

Způsob vkládání obrázků, který se mi líbí nejvíc: obrázek je 2x větší, než má ve stránce být, ale ve čtvrtinové kvalitě.

Netuším jak ty, ale já JPG obrázky většinou z Photoshopu ukládám s kvalitou kolem 65 – 70 a samozřejmě obrázek je 1:1 velkej, jak má být ve stránce. Pokud vezmu příklad, že ve stránce má být obrázek 175x190px, tak výsledný bude 350x380px a místo abych ho uložil s kvalitou kolem 65, tak ho uložím s kvalitou kolem 20 – 30 a pomocí CSS resiznu na 50%. Samozřejmě záleží na tom co na obrázku je, ale rozdíl v těchto dvou variantách dělá pár KB a hlavně pokud v sobě nemá velké přechody, tak se dá jít kompresí ještě níže a dokonce KB ušetřit a přitom bude všude vypadat parádně! Test proběhl na ilustračních obrázcích nahoře, kde jsem začal na kompresi 20 a skončil na kompresi 100, takže od nejmenšího po největšího, kontroloval jsem to na iPhonu a MB Pro, oba s retinou + na obyč monitoru s windows, však si to zkus sám a uvidíš.
Jen pokud to není dostatečně jasné, tak tohle je řešení pro “contentové” obrázky nebo velké obrázky v záhlaví, pozadí, atd. né pro šipky, ikonky… pro ty je pořád lepší nějaký sprite a ideálně SVG + PNG verze a nebo font. Stejně tak opatrně co se performance týče, resizů velkých obrázků nebo background-attachment: fixed; nic co by prohlížeč zvládal levou zadní a lehce se u tohohle může “zapotit”.

Hyper-mega-ultra řešení ikonek fontem


Ano je super dělat, přebarvovat, načítat ikonky fontem a k tomu použít třeba fontastic.me, ale jako všechno má svá úskalí, kvůli kterému je potřeba ho používat obezřetně a kvůli kterému jsem zatím nezměnil a asi jen tak na něho názor nezměním. Jmenuje se Windows Phone, Android a pár zařízení / prohlížečů ve kterých nejen, že se font nenačte, ale o co hůř, nejde ani zdetektovat, že font-face neumí.

Pokud je ikonka u textu, ok udělám jí fontem, pokud je ikonka samostatně a je na ní nějaká akce, tak ne, díky, udělám jí raději obrázkem.

Když se totiž nenačte ikonka u popisku dělaná fontem, tak se nenačte, těm pár % návštěvníků, to vadit nebude a použitelné to bude pořád.

Moje základní idea a na co si dávám pozor


Mít device detektor (ideálně přes nějakou PHP knihovnu), je pecka věc, ale nespoléhám se na něj, takže i když vím, že na mobilu tam tohle nebo tohle nebude, čí tohle nebude tady, ale o kus níž…tak je mi to jedno a prvek nastyluju tak, jako bych žádný device detektor neměl. Popřípadě pokud tam být nemá, tak mu prostě v CSS dám display:none. To, že pak pří úspěšné detekci se z dokumentu vyhodí úplně je jedině plus navíc, ale jak říkám, nespoléhat se! Jediné na co si dávám pozor jsou obrázky, ale i ty jdou snadno obejít aby se nenačetly: Media Query & Asset Downloading Results, takže doporučuju se nad jakýkoliv vložením obrázku zamyslet a neříct si zda prostě neudělám jen jednu věc navíc a pak snadno bude web zase o kus rychlejší jen díky tomu, že se obrázek nenačte.


Jeden z dalších průserů, který (ne)přímo navazuje na device detektor je ten, že rozdíl mezi netbookem, tabletem a mobilem (tím myslím v rozlišení) je někdy tak malej, že prostě nemůžu 100% říct, že nějaký Samsung Galaxy Note je mobil, když je to spíše tablet a zase jakýkoliv menší tablet, je spíše mobil. Ona tahle tabulka to popisuje dostatečně: screensiz.es. Proto pracuji s obsahem jaký mám nehledě na detekci a styluju ho tak, aby byl všude maximálně použitelný. Ano je to časově náročné a ano dělám dá se říct 2x tolik práce, ale ten výsledek za to opravdu stojí.

Pár věcí, které je potřeba mít na paměti než se vrhneš na responsive:

A teď trošku toho kódování k zamyšlení


První problém, kdy mám nějaký obsah “article” a nějaký informace o článku (autor, datum, sdíleni..) “aside” s tím, že nevím který sloupec je vyšší, takže nemůžu / nechci použít position:absolute; na “aside” a zároveň chci, aby při responsivu se šířce device přizpůsoboval “article” a “aside” byl pořád stejně širokej a poté, až bude screen menší, tak aby se stalo to, co je na druhé půlce obrázku. Problém je v tom, že “aside” musí být v dokumentu jako první, takže bez nějakého přemísťování v DOMu (v tomto případě jedině pomocí JS), ho níže nedostanu, ale opravdu nám vadí, když bude nad obsahem a ještě k tomu pouze pokud si někdo bude zmenšovat okno a nebo ho “neodchytne” device detektor? Teď neřeším SEO, ale ani v tom mi nepřipadá špatně, že je pod hlavičkou info o článku, pak článek a pak třeba diskuze…
+ pokud by někdo řešil “přehazování” něčeho v DOMu, tak bacha na PX, protože se snadno může stát, že nějaký tablet na šířku to chytne jako tablet (zobrazí se to co je na první půlce obrázku) a na výšku chytne jako mobil (zobrazí se to co je na druhé půlce obrázku, s tím, že “aside” budeš chtít mít pod “article”), takže to bude pořád přehazovat kusy DOMu, tam a zpět, nebudeme řešit performance, ale osobně to dobře řešení není a nelíbí se mi.


Další věc, kterou se dá snadno vyřešit jakýkoliv list elementů vedle sebe (v tomto případe UL > LI). V první půlce obrázků je jasně daná šířka a výška elementu, takže si dovolím udělat float:left; na LI, nastavím všem margin z leva a o stejný akorát do mínusu nastavím UL (musíte pracovat s border-boxem) a je vlastně vyřešeno. Ale pokud začnu dělat něco do responsivu, tak je blbost dávát jim pevnou šířku / výšku, ale začnu si hrát s %, takže na druhé půlce jde vidět, že LI nastavím šířku 33% (protože chci 3 vedle sebe) a display:inline-block; ale tam nastává problém Remove Whitespace Between Inline-Block Elements, který osobně řeším font-size:0. Není tam celý ten kód a jde spíše o “ilustrační” ukázku, jak zhruba přemýšlím a jak snadno se dá “vyhrát” s webem pro různé šířky zařízení.

Ano většina zkušenějších si řekne, že tohle ví každej, ale potom co mi prošlo rukama X ukázek kódu od kodérů, kteří se k nám hlásí, tak si myslím, že přesně tyto dvě řešení moc lidí nezná / nechápe a že místo toho, aby použil nějaké takové řešení, tak vždy všechno nastavuje dle přesně daných breakpointů, většinou iPad na šířku, na výšku a pak iPhone na šířku, na výšku.

Článek jsem o dost zkrátil, protože na “srdci” jsem toho měl ještě o dost více, ale i tak je pořád hodně dlouhej (takže se omlouvám, pokud jsi to dočetl až sem), v některých věcech jsem nešel vůbec do detailů, tak jak by si to zasloužilo.
Je to téma spíše na přednášku, kde by se dal lépe ukázat nějaký příklad s tím jak jsem ho řešil, jak bych ho řešil dnes popřípadě co jsem u toho řešil za problémy…třeba jednou.

Pokud máš k něčemu otázku nebo jsem napsal něco špatně, popřípadě máš lepší způsob jak co dělat, tak se rozepiš do komentářů, budu rád i za sdílení a třeba mě to “vyprovokuje” k napsání něčeho dalšího :)

Sdílet:

comments powered by Disqus