Web a responsivní obrázky se src-n

[omg]

Na Zdrojáku vyšel článek o adaptivních/responsivních obrázcích na webu:

http://www.zdrojak.cz/clanky/adaptivni-obrazky-vyresena-otazka-s-novym-otaznikem/

Jde o to, aby se načítal vždy obrázek vhodný pro dané zařízení/displej (desktop, mobil atd.) a ne nějaký univerzální. Článek je o návrhu, který spočívá v tom, že by se zavedly atributy src-n, tzn. src-1="...", src-2="..." až src-n="..." kde uvnitř hodnoty atributu bude nějaká speciální syntaxe, vnitřní struktura popisující jak velikost displeje/okna, tak cestu k obrázku.

Je to prasárna a zvěrstvo, jednak kvůli těm číslovaným atributům a jednak kvůli vnitřní struktuře. Pokud víte něco o normálních formách v databázích, zkuste si je aplikovat na tento návrh. Nebudu to více rozvádět, protože to za mě už dobře popsali jiní.

Líbí se mi komentáře Davida Grudla:

... Src-n zavádí:
- úplně nový typ atributu ve tvaru xxx-n, což znamená popsat, jak se atributy řadí, zda se číslují od nuly či jedničky, zda se mohou čísla vynechat, jak vůbec dynamicky přidat nový attribut s nejnižší prioritou, když src-1 už je obsazené, atd...
- úplně nový typ hodnoty, která je komplikovaná a jde proti duchu značkovacího jazyka, protože přidává nový jazyk.
...

a Jirky Koska:

Osobně za největší problém src-N považuji naprostou nekompatibilitu se stávající infrastrukturou značkovacích jazyků. DOM nemá metodu, která vrátí všechny src-N atributy, XPath nemá jednoduchý způsob, jak vrátit src-N atributy, ... Navíc seřazené podle N. src-N je něco podobného, jako udělat v relační tabulce sloupce tel1, tel2 a tel3, místo napojední druhé tabulky s telefony se vztahem 1:N.

Pokud chcete k tématu něco dodat, aniž by hrozilo, že vám to smaže Hassman, můžete využít toto diskusní vlákno :-)

Možná má být tento návrh jen odstrašujícím případem, aby ostatní návrhy vypadaly relativně lépe a byly snáze přijaty.

[Reklama]

[omg]

Mě napadají dva způsoby, jak to řešit:

1) Uložit informaci do HTML, ale správně, tzn. ne žádné číslované atributy, ale vnořené elementy a žádný strukturovaný obsah uvnitř atributů – hodnoty by měly být atomické.

2) element img by obsahoval volitelný příznak např. responsive="true" který by prohlížeči říkal, že k URL ze src atributu má přikódovat GET parametry obsahující velikost displeje, typ zařízení případně další údaje.

Přikláním se k řešení 2), to považuji za dobré, 1) je pořád trochu špatné v tom, že markup je zahnojený těmito nedůležitými informacemi (ale pořád je to mnohem lepší než návrh popsaný v článku)

[Riff]

Druhá varianta se mi taky líbí, akorát pořád může být potřeba někam nacpat media queries. K tomu by se dal využít třeba právě ten atribut responsive a v něm uvedená hodnota by se předala jako suffix(tzn. bla_320.png, atd). Pokud by nevyhovoval žádný z minimálních rozměrů, tak se použije nezměněná hodnota src. No a pro displeje s různou hustotou pixelů by buď stačilo za konkrétní velikost přidat třeba "x2" nebo použít atribut určující, že všechny rozměry mají i hi-density variantu, například hd="2".

Kód [Vybrat] Rozbalit

<img
    src="bla.png"
    responsive="320,480,1024,1280"
    hd="2"
/>

[omg]

K tomu by se dal využít třeba právě ten atribut responsive a v něm uvedená hodnota by se předala jako suffix(tzn. bla_320.png, atd).

spíš jsem to myslel tak, že by prohlížeč ze src="bla/bla.png" vyrobil něco jako bla/bla.png?x=800&y=600&device=desktop&dpi=96 a server by mu podle toho vybral vhodný obrázek. Když to bude kódované jako GET parametry, tak se to bude líp parsovat, snadno si na servery ty informace vytáhneš, ne jako když to budou nějaké prefixy/suffixy.

Na serveru tuhle práci obstará buď modul do Apache/Nginxu nebo nějaký skript.

[omg]

P.S. Nějaká duplikace tam bude vždycky – jde o to, že ti vždycky (resp. když to bude blbě nakonfigurované/naimplementované na serveru) může vzniknout nesoulad mezi tím, co je v HTML/CSS a tím, co skutečně přijde ze serveru (velikost obrázku), ale s tím se asi nedá nic dělat. Takže by v HTML toho mohlo být co nejméně a v CSS by bylo, pro jaké rozměry displeje/okna (nebo dostupného prostoru pro obrázek) se má použít jaká velikost obrázku.

[Reklama]

[Riff]

Už tě chápu, to zní dobře. Akorát by bylo asi ideální nechat obě možnosti, třeba pomocí get="true/false". Ale jestli se nečeho podobnýho dočkáme, tak za hodně dlouho. Zatím bych to viděl klasicky do src placeholder, do atributu data-src obrázek a JavaScript rullz ;-)

[?]

Jasně .. dejme to do url a všechno nechme na vývojářích Apache .. snad k tomu nějaký ten modul dodělají ;-). Nebo ještě lépe zabereme těch pár znaků, co je v url povolených na nesmyslné atributy.

Varianta, která je popsaná v článku se mi líbí. Fakt, že si každý bastlí vlastní CMS a nechce se mu pracovat na novém řešení je pěkné, ale nemůže se to plést do rozhodování o specifikaci.

[Riff]

Varianta, která je popsaná v článku se mi líbí

Ona ta varianta má bohužel dost celkem podstatných zádrhelů.

nemůže se to plést do rozhodování o specifikaci

Tady se čistě teoreticky bavíme o tom, jak by se to líbilo nám, nic víc :-)


OMG: Napsal jsem si skript, který funguje tak, jak popisuješ. Říkal jsem si, že by se ti(nebo někomu dalšímu) mohl hodit:

Kód [Vybrat] Rozbalit

<!doctype html>
<html>
    <head>
        <title></title>
        <meta name="viewport" content="width=device-width" />
    </head>
    <body>
        <img src="placeholder.png" data-src="picture.png" />
        <script src="responsive.js"></script>
    </body>
</html>

responsive.js:

Kód [Vybrat] Rozbalit

// Choose images according to screen width and pixel ratio
(function() {
   
    // Get pixel ratio
    var ratio = 1;
    if (screen.systemXDPI && screen.logicalXDPI && screen.systemXDPI > screen.logicalXDPI)
        ratio = screen.systemXDPI / screen.logicalXDPI;
    else if (devicePixelRatio)
        ratio = devicePixelRatio;

    // Get screen width
    var width = screen.width;

    // Iterate all images with data-src attribute
    var pics = document.querySelectorAll('img[data-src]');
    for (var i = 0; i < pics.length; i++) {
        var pic = pics[i];
       
        // Set appropiate url
        var src = pic.getAttribute('data-src')
        pic.setAttribute('src', src + '?width=' + width + '&ratio=' + ratio);
       
        // Cleanup
        pic.removeAttribute('data-src');
    }
})();

[omg]

Jasně .. dejme to do url a všechno nechme na vývojářích Apache .. snad k tomu nějaký ten modul dodělají ;-).

Modul do HTTP serveru je optimální možnost – napíše se jen jednou a pak ho můžou používat všichni. Ale než bude hotový, tak se klidně můžou používat PHP skripty nebo Servlety nebo cokoli jiného, co si přečte parametry v URL a na základě nich vybere vhodný obrázek.

Nebo ještě lépe zabereme těch pár znaků, co je v url povolených na nesmyslné atributy.

Místo v URL není až tak vzácné :-) a běžně se do něj cpou mnohem neužitečnější údaje, než je tohle. Jestli si prohlížeč vyžádá místo

Kód [Vybrat] Rozbalit

/web/adresar/mega-lol-husty-obrazek_800x600.png

tohle:

Kód [Vybrat] Rozbalit

/web/adresar/mega-lol-husty-obrazek.png?x=800&y=600

je celkem jedno, nemyslíš?

Varianta, která je popsaná v článku se mi líbí.

A mně se fakt nelíbí, je to hnus, viz argumenty výše.

[omg]

OMG: Napsal jsem si skript, který funguje tak, jak popisuješ.

JS moc rád nemám, jsem toho názoru, že by web měl fungovat i bez něj. Navíc tohle by mělo být deklarativní – načíst nějaké datové struktury, atributy a na základě nich rozhodnout, ne spouštět nějaký libovolný kód/proceduru. Nicméně než bude podpora v prohlížečích, tak by to použít šlo, ono stejně spousta webu bez JS nefunguje, tak už je to asi jedno... Do <noscript/> by šlo přidat výchozí obrázek, aby se zobrazilo aspoň něco, takže by vlastně web byl použitelný i bez JS :-)

[Riff]

Jasně, nejde o nic víc, než "z nouze ctnost" dokud nebude podpora. Jinak je to jenom nástřel, ještě to bude chtít doplnit věci jako výběr šířky podle orientace displeje a případně další parametry.

[Makovec]

Řešení by zejména mělo zapadnout do obecných principů na kterých je budována architektura webu - jak v diskusi na Zdrojáku správně poznamenává zejména Jirka Kosek, který do této věci z diskutujících vidí z nejširší perspektivy. Jeden ze základních principů je že se nemění obecná norma a pravidla podle okamžité potřeby specializované funkce. Občas to znamená trochu práce navíc nebo nepřímočarosti či užvaněnosti kódu, ale výsledá koherence systému za to stojí, protože máte něco s čím se dá pracovat bez dalších switchů a ifů.

Řešit standardně ty to věci tím "že se napíše plugin do Apache" a "javascriptová funkčička k tomu" je taková ta microsoftí cesta která praví že implementace podle největšího psa je zároveň definicí. My tu ale chceme technické standardy, ne snad něco na čem se možná tak ňák po letech přetahování dohodnou kluci od Firefoxu, Googlu, MS a Apache (každý trochu jinak, ale od toho jsou konzultanti a optimalizátoři a autoři frameworků a browserů aby si to nějak ošetřili, nebo snad ne?)

URL atributy: fajn, takže budou najednou rezervovaná jména URL query parametrů? Fakt? Praktická nemožnost opravdu statických webů?

[omg]

Řešit standardně ty to věci tím "že se napíše plugin do Apache" a "javascriptová funkčička k tomu"

To je otázka, zda by o výběru obrázku měl rozhodovat prohlížeč nebo server. Na které straně by se ten algoritmus měl vyskytovat. Každé má svoje, ale tu serverovou variantu bych nezavrhoval – ostatně server má vždycky možnost podstrčit klientovi libovolný obrázek, ať už si vyžádá jakékoli URL. Navíc server je součástí webové aplikace – tudíž o výběru konkrétních obrázků vlastně rozhoduje autor aplikace, ne nějaký neznámý prohlížeč. Tudíž můžeme mít jednotnější chování napříč prohlížeči a zároveň implementace v prohlížečích (kterých je mnoho) bude jednodušší (jen zakódovat nějaké parametry do URL). Implementace algoritmu bude na HTTP serveru, kterých je relativně málo (Apache, Nginx...) nebo v jazyce jako PHP, Java, Python...

Tohle řešení se mi líbí taky kvůli čistému markupu – bude tam jen ta sémantická informace: <img src="cesta/k/obrázku" responsive="true"/> a ne nějaký balast kolem a duplicitní informace. V takové galerii obrázků bys měl jinak spousty hnoje.

JavaScript je jen přechodné řešení pro legacy prohlížeče – ty nové by funkci pro přikódování parametrů do URL měly v sobě a žádný JS by nebyl potřeba.

URL atributy: fajn, takže budou najednou rezervovaná jména URL query parametrů? Fakt? Praktická nemožnost opravdu statických webů?

Jen v případě, že budeš chtít používat tenhle standard pro responsivní obrázky. Jinak můžeš mít parametry jaké chceš a statické weby taky, jen si tam tu responsivnost budeš řešit nějak jinak – nikdo tě přece nenutí to používat.

Další možnost by byla vložit tyhle informace (rozlišení, DPI atd.) do nějaké HTTP hlavičky, ale to by komplikovalo kešování na případných proxy serverech.

[Riff]

Řešit standardně ty to věci tím "že se napíše plugin do Apache" a "javascriptová funkčička k tomu" je taková ta microsoftí cesta

Debatovat o tom, jak to bude super až to bude super je moc fajn, ale co mám dělat, když požadovanou funkcionalitu potřebuju TEĎ a ne až za dva roky, kdy se konečně všichni dohodnou na jednotném řešení a výrobci prohlížečů ho za další rok možná implementují? To bude asi chtít ten Apache plugin a nějakou tu JS funkcičku...

[omg]

BTW: taky by bylo fajn nějak sémanticky podchytit vztah mezi náhledem obrázku a plnou velikostí. V zásadě jde pořád o ten samý obrázek, akorát jednou z něj chci zmenšeninu a jednou plnou velikost, nebo třeba ne úplně plnou ale třeba ve velikosti okna, které se mi vejde na obrazovku. Vlastně všechny ty JavaScriptové LightBoxy jsou odporný bastl – tohle by mohl řešit prohlížeč sám.