ugrás a tartalomhoz

Változó láthatárok

Joó Ádám · 2010. Aug. 2. (H), 19.14
Egy napon mindenről el kell számolni. De mindenről. Ez elkerülhetetlen. S akárhogyan odázod: amiben hibáztál, amivel adós vagy, amihez gyáva voltál, amiben bűnös vagy, mindezért számot adsz egy napon. – Márai Sándor

Hosszú évek alatt még mindig nem fogadtuk el, mennyire diverz közeg a háló. Ott volt például az, amikor rá kellett jönnünk, hogy egy weboldalt nem csak egérrel akarunk kezelni. Mikor kiderült, hogy ki akarjuk kapcsolni a képeket. Hogy szöveges böngészőt használunk. És felolvasót. Saját stíluslapot. És a szkripteket sem szeretjük. És már tapogatjuk is a képernyőt.

Hogy változnak a képernyőméretek. És most a részletesség is. Pedig volt, aki szólt előre.

Az új iPhone Retina Display kijelzője lélegzetelállítóan néz ki.

iPhone 4 Retina Display (Aral Balkan)
iPhone 4 Retina Display (Aral Balkan)

Az Apple új üdvöskéjében négyszer annyi képpontot zsúfoltak ugyanakkora helyre, melynek következtében eddig még soha nem látott részletességben tündököl ikon és szöveg. De felvet némely problémákat is.

Dave Hyatt már négy évvel ezelőtt felhívta rá a figyelmet, hogy hamarosan eljön a nagy részletességű képernyők kora. A gond az, hogy a sok pixelben definiált weblap a jövő kijelzőin használhatatlanul apró lesz. Tehát nagyítani kell.

Hiába nagyítjuk azonban a képeket, azok pont ugyanúgy fognak kinézni, mint a kisebb részletességű képernyőn megtekintve: növelni kell a képek felbontását, egyszersmind azonban a megjelenítési méretüket változatlan hagyni – ez azonban nem is olyan egyszerű.

Dave megoldási javaslatai közt szerepel az explicit megadott méret a beágyazott illusztrációknál, nagyobb letöltendő képméret mellett; a háttérképek méretének megadása az új tulajdonság, a felsorolásjeleké az új kiválasztó segedelmével. Vagy a stíluslap feltételes értelmezése, az egyelőre csak Safari által támogatott új média-lekérdezésre alapozva.

A legegyszerűbb persze vektoros képek használata lenne, de mindannyian tudjuk, kilenc évvel az ajánlási státusz elnyerését követően hol tart még mindig az SVG támogatottsága, beszéljünk csak a dokumentumba ágyazott képekről, és ne is szóljunk a stíluslapokban történő használatról.

Aztán persze ott vannak azok a képek, melyek természetüknél fogva nem vektoralapúak. Aral Balkan azt indítványozza, kövessük az iPhone SDK konvencióját, és egy utótaggal különböztessük meg a képek nagyobb felbontású változatait, melyeket a böngésző automatikusan lekérne. És persze rögtön definiáljunk is egy meta elemet, amivel kikapcsolható, hogy ne dőljön össze a kiszolgáló a kérések terhe alatt.

A HTTP protokoll másfél évtizede teszi lehetővé a tartalomegyeztetést (content negotiation), épp ilyen célra. Csak ez is el lett felejtve.

Az Apple kiengedte a szellemet a palackból, mi pedig kapkodhatunk valamiféle megoldás után.

 ■
1

content negotiation

janoszen · 2010. Aug. 2. (H), 19.50
A content negotiationnek egyetlen baja van, méghozzá a Vary header. Azon kívül nem jelzi semmi, hogy más fajta tartalomról van szó, ergó az olyan szoftverek, amik kizárólag az URL-re alapoznak (pl Google), nem tudják értelmesen reprezentálni a felhasználónak a két lehetőséget. A media query a HTTP-s megoldásnál azért jobb, mert a tényleges tartalom különböző URL-eken lesz.

Elég csak arra gondolni, hogy én mondjuk angolul keresek egy kifejezést, de az oldal, mivel úgy gondolja, hogy a böngészőm magyar, magyarul fogja elém lökni adott esetben azt, hogy az oldal magyar nyelven nem érhető el. A még szomorúbb, hogy semmilyen szabványos hivatkozási módszer nincs arra, hogy fölülbíráljam a content negotiationt.

Ettől függetlenül persze lehet használni, csak azért érdemes arra odafigyelni, hogy az IE 6 is azt mondja talán magáról, hogy támogat XML-t, azt közben lótúrót. Ezen a ponton sajnos a szabvány huszárok megbuknak, nagyon óvatosan tessék implementálni az ilyen megoldásokat.
2

Nem a szabvány hibája

Joó Ádám · 2010. Aug. 2. (H), 21.25
Az, hogy a böngészők és a keresők csak egy végletekig leszűkített halmazát implementálják a szabványnak, az nem a szabványt minősíti.

Nyilván ahhoz, hogy a negotiation működjön, alkalmas felületet kéne biztosítania a böngészőnek: be kellene tudjam állítani, milyen nyelvet kérek, milyen típusú tartalmat, a paramétereit stb.
3

URL

janoszen · 2010. Aug. 2. (H), 21.34
Igazából ez a végig nem gondolás hibája. Az URL mint Uniform Resource Locator egy erőforrást jelez. Azt nem gondolták végig, hogy a különböző nyelvek, felbontások isten igazából két külön erőforrás, akármennyire nemes is volna az a gondolat, hogy minden erőforrásnak különböző változatai vannak, nem működik. (Lásd pixelgrafikák.)
4

Az URL nem minden

Joó Ádám · 2010. Aug. 2. (H), 23.18
Ez nem végig nem gondolás, hanem koncepció. Egy vektoros grafika két különböző nagyításban két különböző erőforrás? Erre mostani szemléletben azt mondod, hogy nem. Miért tartod ugyanannak a bittérképes képnek a különböző felbontásait más erőforrásnak?

Ha nincs szükség ezekre a lehetőségekre, akkor minek használunk HTTP-t? Használhatnánk helyette Unix fájlhierarchiát.
5

Flame: Címzés

janoszen · 2010. Aug. 3. (K), 07.00
Hibás az érvelés, mert a vektoros grafika nagyítás nem a szerveroldal kérdése, hanem a kliensé. Ergó nem kell CN sem. A pixeles grafikák illetve a nyelvi változatok viszont igen, mert az előbbiek esetében pl a 16x16 ikon nem csak lekicsinyített mása a 32x32-esnek, hanem másképp van megrajzolva, hogy látsszon a lényeg. Ugyanez az utóbbinál, ahol esetleg más szófordulatok, kiegészítések fordulnak elő.

Egyébként meg ne menjünk bele a flame warba, tudom, hogy nagy szabványharcos vagy, de ez esetben a szabványban nem vették egészen figyelembe a lehetséges felhasználásokat.
6

Flame?

Joó Ádám · 2010. Aug. 3. (K), 15.47
A bittérkép is kicsinyíthető kliens oldalon, csak érdemesebb a szerveren. (A másképp rajzolás pedig csak algoritmus kérdése.)

Nem értem, hogy miért akadályozó tényező az, hogy egy a te terminológiádban vett erőforrást nem egy (URL), hanem több (URL, fejlécek) paraméter megadásával érhető el. Ez egy ilyen protokoll, az már a böngészőfejlesztők sara, hogy én egy kérést csak az URL-lel tudok paraméterezni.

Egyébként pedig úgy viszonyul ez a flame-hez, mint Makó Jeruzsálemhez :)
7

Szinte minden modern

tgr · 2010. Aug. 3. (K), 21.10
Szinte minden modern böngészőn be tudod állítani, milyen nyelveket kérsz (talán csak a végletesen minimalista Chrome-on nem). Más kérdés, hogy *-ot fűzni az Accept-Language végére már nem tudnak.
8

Senki nem használja

Joó Ádám · 2010. Aug. 3. (K), 21.31
Az égvilágon senki nem használja. Firefoxban négy kattintás elérni, egyetlen átlagfelhasználó sem találkozott még ezzel az ablakkal, holott amikor használatba veszi a böngészőt, meg kéne adja, mely nyelveken beszél.

Onnantól, hogy lehet hinni a böngésző által szolgáltatott adatnak, kezdhetnék el használni a fejlesztők szerveroldalon az információt.