Web a responsivní obrázky se src-n

[Riff]

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.

[Reklama]

[Mirage]

Měnit název souboru je nehorázná kravina 
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.

[Makovec]

Ř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!).

[omg]

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="…"

[Karel]

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.

[Reklama]