(Snad už) Definitivní responzivní obrázky – <picture> a Picturefill

V minulém díle jsme rozebrali důvody ke vzniku nového standardu a atributy srcset, sizes, které vám ve velké většině případů pro responzivní obrázky budou stačit. Pokud by nestačily, je tu ještě záchrana v podobě nového tagu . Podíváme se také na podstatnou věc — jak responzivní obrázky polyfillovat ve starších prohlížečích.
Nálepky:
<picture> – ukázka zápisu
<picture>
<source media="(min-width: 1024px)" srcset="large.jpg">
<source media="(min-width: 600px)" srcset="medium.jpg">
<img src="small.jpg" alt="…">
</picture>
Je asi zřejmé, že obrázek small.jpg
se použije ve starých prohlížečích nebo tam, kde není splněna ani jedna Media Query v <source>
– v tomto případě do šířky okna 599 pixelů.
Dobré vědět, že <picture>
tvoří trochu neekologicky zbytečný obal a <source>
jen jakési molitanové vycpávky nesoucí informaci o alternativách. Veškeré stylování nebo věšení událostí v javascriptu je nutné dělat přímo na <img>
element. Prohlížeče také do jeho atributu src
stěhují obsah vyhovujícího obrázku z srcset
u atributů <source>
. Proto v každém <picture>
musí být právě jeden <img>
.
Kdy budete <picture>
potřebovat?
Pokaždé, kdy vaše varianty splňují jednu z těchto podmínek:
- Potřebujete servírovat jinak vypadající obrázky pro různá rozlišení — třeba pro mobily chcete jinak vyříznout hlavní motiv obrázku (scénář art direction).
- Prohlížečům jste připravili obrázky v různých souborových formátech.
Ve všech ostatních případech a tedy v naprosté většině případů vám bude stačit starý dobrý img s atributy srcset a sizes.
Art direction – obrázky pro různá rozlišení mají také různý obsah
<picture>
<source
srcset="large_1600.png"
media="(min-width: 1024px)">
<source
srcset="medium_1024.png"
media="(min-width: 800px)">
<img
src="small_600.png"
alt="Obrázek" width="200" height="200">
</picture>
Demo pro art direction s <picture> na CodePen. (V demu jsme použili polyfill Picturefill, takže funguje ve všech prohlížečích, ale možná jste si všimli nepřítomnosti atributu src.)
Pro okna 1024 pixelů a větší se stáhne a použije obrázek large_1600.jpg
, od 800 do 1023 pixelů medium_1024.jpg
a pro okna šířky 799 a méně pixelů pak small_600.jpg
.
Dobré vědět, že z variant obrázku v <source>
se vezme vždy první vyhovující, takže je nutné je řadit od největšího po nejmenší.
Podle formátu obrázku
Vybírat obrázky můžete i podle formátu. Použijte atribut type=""
. Příklad — některé prohlížeče zvládají nový úsporný formát obrázků WebP.
<picture>
<source media="(min-width: 1024px)" srcset="large.webp" type="image/webp">
<source media="(min-width: 1024px)" srcset="large.jpg">
<img src="small.jpg" alt="…">
</picture>
Prohlížeč, co umí formát WebP a běží v okně velikosti alespoň 1024 pixelů, stáhne a zobrazí soubor large.webp
. Pokud vím, Picturefill umí kromě WebP detekovat ještě SVG.
Další složitější scénáře použití <picture>
najdete například v tomto článku na Dev.Opera.
Teď to všechno ještě uvést do reality. Potřebujeme Picturefill. Polyfill, který dokáže zařídit podporu nově standardizovaných responzivních obrázků (atributů srcset a sizes a elementu <picture>) ve všech prohlížečích. Picturefill má dvě použitelné verze, obě mají svá pro i proti. Standardně doporučuji používat verzi 2.x.
Picturefill 2
Novější verze 2.x obsluhuje daleko více scénářů použití responzivních obrázků – je to plnohodnotný polyfill dočasně emulující funkčnost srcset/sizes i tagu <picture> ve všech prohlížečích.
Nic ale není zadarmo. První nevýhoda Picturefillu 2 spočívá v nutnosti vynechat src
atribut, aby prohlížeče bez podpory <picture>
nestáhly dva obrázky. To také znamená, že prohlížeče bez Javascriptu uvidí místo obrázku jen alternativní text. Vzniknou také problémy s ne-indexováním obrázku v Google Images nebo ne-možností vložit obrázek při sdílení stránky na Facebooku. Pokud je nicméně autorovi známo, pak kromě toho, že tak vznikne dočasně nevalidní kód, nemá vynechání src
žádné jiné negativní dopady ani na čtení stránky slepeckými čtečkami. Zda chcete používat variantu se src
nebo bez něj si rozmyslete podle požadavků projektu.
Druhá verze Picturefillu využívá standardizované syntaxe, a tak se zápis blíží tomu, co za pár let budou prohlížeče umět nativně.
Příklad zápisu pro srcset a sizes:
<img
sizes="(min-width: 40em) 80vw, 100vw"
srcset="small.jpg 375w, medium.jpg 480w, large.jpg 768w"
alt="Obrázek" width="500" height="250">
Příklad zápisu pro <picture>:
<picture>
<!--[if IE 9]><video style="display: none;"><![endif]-->
<source srcset="extralarge.jpg" media="(min-width: 1000px)">
<source srcset="large.jpg" media="(min-width: 800px)">
<!--[if IE 9]></video><![endif]-->
<img srcset="medium.jpg" alt="Obrázek">
</picture>
Kroutíte hlavou nad použitím <video>
tagu? Ano, to je další obezlička, tentokrát pro Internet Explorer 9.
Jasně, Picturefill 2 má těch obezliček a drobných nevýhod docela dost, ale dobře se zamyslete, co vám jeho použití přinese. Pokud chcete mít responzivní obrázky a zároveň jsou pro vás nevýhody druhé verze nepřekonatelné, zkuste ještě původní verzi Picturefillu.
Picturefill 1
Verze 1.x se vyznačuje ošklivou syntaxí postavenou na spanech a umí vyřešit jen dva scénáře použití responzivních obrázků – podle rozlišení obrazovky a device-pixel-ratio
.
<span data-picture data-alt="Obrázek">
<span data-src="small.jpg"></span>
<span data-src="medium.jpg"
data-media="(min-width: 400px)"></span>
<span data-src="large.jpg"
data-media="(min-width: 800px)"></span>
<!-- Fallback pro ne-JS prohlížeče -->
<noscript>
<img src="small.jpg" alt="Obrázek">
</noscript>
</span>
Výhodou ale je bezchybná funkčnost ve všech možných prohlížečích, včetně toho, že nějaký ten obrázek uvidí i uživatel sedící u prohlížeče bez Javascriptu. Picturefill 1 má navíc jen asi 2 kB.
Pojďme to shrnout. Pokud v responzivních obrázcích vidíte přínos pro váš projekt a potřebujete podporu ve všech prohlížečích, volte Picturefill. Volte 2.x verzi. 1.x jako poslední záchranu, pokud vám nevýhody dvojky trhají kodérské srdce.
Čtěte dále
- Dev.Opera: Scénáře použítí responzivních obrázků (anglicky)
- Autorova přednáška Responzivní obrázky v praxi a slajdy k ní
- Přednášky Robina Pokorného: úvod do problému, problém a základní řešení a problém a pokročilé řešení pro responzivní obrázky.
- Generátor variant obrázků pro Grunt.
- Compressive Images, alternativní technika, pokud řešíte jen problém s
device-pixel-ratio
a datovým objemem na pomalých připojeních.
Původně vyšlo na VzhůruDolů.cz. Responzivní obrázky autor také školí na kurzu responzivního designu.
Nevite nahodou, ktere *prase vymyslelo „spravny“ zapis? Odjakziva se v HTML zapisuji parametry zpusobem:
media
je standardní HTML atribut, do kterého se vkládají CSS Media Queries.Na první pohled ta nutnost inlinovat CSS vypadá zvláštně. Má to ale své důvody v potřebě oznámit prohlížeči informaci ještě předtím než zná obsah externích CSS souborů.
no to je podle me jen alibismus, kdyz uz se neco navrhuje tak to ma byt poradne, osobne take zastavam nazor ze by se mely uvest jen adresy obrazku plus jejich velikost a at si prohlizec sam vybere co potrebuje a to ze v te dobe nema css no neni tak teske na nej pockat a zacit tahat obrazky az pak.
Navic a muze to byt jen rychlim netem ale uz se mi dlouho nestalo jako v dobach ie6 ze se stranka pred ocima prerendrovava jak taha dalsi a dalsi css.
Vyber primo prohlizecem by eliminoval patvary vytvarene retina displeji.
O tom jak dlouho se razi doktrina ze se nemaji promichavat html, css, javascript se vracime do promichavani, ikdyz to me osobne zas tolik neboli, neb sem to striktni rozdelovani nikdy nechapal, kdyz jedno bez druheho nema smysl.
Četl jste? http://www.vzhurudolu.cz/prirucka/srcset-sizes#proc-si-velikosti-obrazku-prohlizec-nevezme-z-css
Prohlížeč nemůže čekat na načtení a rozpársování CSS. Představte si tu situaci na takovém EDGE připojení kde uživatel na načtení CSS souboru čeká několik desítek vteřin.
Pokud si nekdo chtel dat tu praci a zlepsit nacitani obrazku, tak preci nelze toho efektivne dosahnout pokud se nezmeni logika v samotnych prohlizecich a to jak pracuji se zdroji. Jednoduse by se jasne stanovilo poradi ziskavanych zdroju html, css, zbytek a nikdo prohlizeci nebrani at si vykresli html jak chce nez dostane css, ale argumentovat tim ze se css taha pomalu je nahlavu postavene, zvlaste kdyz jeho stahovani jeste spomali tahane obrazky ktere se pak zahodi protoze se zjisit ze by jina velikost byla lepsi.
Me todle obcas prijde jak zaplaty od ms misto aby opravily chybu v jadre co tam hnije desetileti tak radeji vydaji 100 oprav ktere se nad jadrem snazi zabranit aby se dana instrukce spatne volala. Tohle lpeni na starych a zabugovanych technologiich me celkem casto zarazi.
Mám trochu dojem, že mi nadáváte za situaci na trhu s prohlížeči. :)
Ano, je to trh. S běžnou konkurencí. Rychlost zobrazování stránek je velká konkurenční výhoda. A tak po výrobcích prohlížečů nemůžete chtít, aby se řídili nějakým hypotetickým standardem způsobu načítání stránky.
Prostě si to prohlížeče udělaly tak jak uznaly za nejlepší a standard pro srcset/sizes se jim v tomto musí přizpůsobit.
Ahoj chcel sa len opytat prehliadac stiahne vsetky obrazky pri vykreslovani stranky alebo ich taha postupne na zaklade rozlisenia?
Nestáhne všechny, to by byla konečná! :) Stáhnou jen ten co vyhovuje podmínkám.