Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: omg 27. 01. 2014, 15:37:37
-
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 (http://forum.root.cz/index.php?topic=8313.0), 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.
-
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)
-
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".
<img
src="bla.png"
responsive="320,480,1024,1280"
hd="2"
/>
-
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.
-
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.
-
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.
-
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:
<!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:
// 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');
}
})();
-
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
/web/adresar/mega-lol-husty-obrazek_800x600.png
tohle:
/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: 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 :-)
-
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.
-
Ř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ů?
-
Ř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.
-
Ř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...
-
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.
-
To by možná bylo pěkný, ale je vidět, jaké problémy dělá dohodnout se na triviálních záležitostech, natož na něčem jako je lightbox, kde se bude muset řešit stylování, zobrazení videa, navigace, atd. Navíc věci, které "řeší prohlížeč sám" vypadají ve všech prohlížečích úplně jinak. Třeba blbý alert - nenajdeš jediný prohlížeč, ve kterém by vypadal stejně, o možnosti nastylovat ho, aby zapadal do stránky, se nikomu ani nezdálo.
-
Měnit název souboru je nehorázná kravina ;D
Ještě řešit code injection u url obrázku?
No lol!
To už by bylo jednodušší zavést něco jako OR
Nejlépe takhle:
<img src="bla0.png" responsive="480:bla1.png, 1024:bla2.png,1280:bla3.png"/>
Nejhůř takhle:
<img src="bla0.png" responsive="480" OR src="bla1.png" responsive="1024,1280" />
Určitě to nekadit do URL ::)
A stejně to bude dělat bordel v css style kódovaných per pixel.
-
Ř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...
Já nepíšu o tom jak to konkrétně naprogramovat teď, a myslím že celá debata o tom ani není, na to mohou být různé "custom" cesty a řešení. Tam samozřejmě vlastní javascript a vlastní funkce na serveru jsou naprosto plnohodnotné řešení. Případně v rámci nějakého frameworku. Mimochodem, psal jsem mobilní weby už před lety (které vracely příslušně velké obrázky, hudbu a video v podporovaném formátu, Java Midlets atd.) a celá logika rozpoznání připojeného klienta byla tehdy - pomocích standardních profilů Device Description Framework - na serveru.
Píšu o tom jak má nakonec vypadat technická norma která bude fungovat napříč prohlížeči které ji budou implementovat, tak abyste se nemusel věnovat implementaci téhle funkce případně kontrole kompatibility prohlížečů a serverů, ale soustředit se na business logiku vlastní webové aplikace (případně statického webu!).
-
Píšu o tom jak má nakonec vypadat technická norma která bude fungovat napříč prohlížeči které ji budou implementovat, tak abyste se nemusel věnovat implementaci téhle funkce případně kontrole kompatibility prohlížečů a serverů, ale soustředit se na business logiku vlastní webové aplikace (případně statického webu!).
Vždyť já se snažím o to samé.
Musím říct, že jsem u toho svého řešení narazil na jednu vadu: URL budou různá podle rozlišení (resp. kontextu, v jakém se obrázek nachází) na klientovi. Což by znemožnilo kešování na společných proxy serverech. Je otázka, jak moc je to problém – jak moc lidí sdílí proxy server s dalšími a zároveň nepoužívá HTTPS? Možná reverzní proxy, ale tu zase sdílí všichni a společné/kešovatelné kombinace rozlišení/dpi by se tam našly.
Každopádně by se mi líbilo, aby toho v HTML bylo co nejméně, pokud možno jen jedno základní URL obrázku, aby v tom markupu byla sémantická informace „sem přijde tenhle obrázek“ ale ne aby se tam řešily technické detaily typu výběr rozlišení pro daný displej. Ten algoritmus pro výběr rozlišení by se nacházel buď na serveru (jak jsem psal výše – klient pošle jen parametry, server rozhodne) nebo by mohl být na klientovi, ale měl by být popsaný někde jinde než v tom HTML a na jednom místě pro všechny obrázky, ne se s tím patlat pro každý obrázek znova a znova. To by mohlo být v CSS – na základě media queries (nebo jiných parametrů, kde se obrázek nachází, kolik je tam pro něj místa) by se zvolila „varianta“ (nějaký textový řetězec) a ta by se pak přikódovala k URL obrázku. Proxy servery by mohly vesele kešovat. V případě varianty (a ne rozlišení, dpi a dalších věcí, což jsou strukturované informace) jakožto jednoduchého textového řetězce by bylo možné ji do URL přidat i jako suffix → a bylo by možné to použít i pro statické weby (není nutný ani modul do Apache ani skriptování na serveru).
Něco takového vlastně navrhoval Riff – jen bych tu informaci (kterou variantu pro které rozlišení) dal do CSS hezky na jedno místo pro všechny obrázky a v HTML přidal pouze ten jeden atribut responisve="…"
-
Ja sem na zdrojaku navrhl reseni, ze by se dodatecne informace davaly do hlavicky http pozadavku, bud primo pozadovana velikost kterou si prohlizec spocita ze potrebuje nebo treba velikost rozliseni. A server by podle toho vratil bud obsah nebo treba redirect odkud se dany obrazek stahne, html by zustalo css take jen by na strane serveru pribyla logika. Slo by to snadno aplikovat jiz na stavajici weby. Navic by se tim rychle pokryly i rozliseni se kterymi autor nepocital.