Responsive design (hogyan?)

Internet: PHP, CGI, stb.

Csak a felbontást kell a figyelembe venni vagy számít a fizikai méret is?
Jó lesz ez így a jövőben?

A legtöbb weboldal a témában csak azzal foglalkozik, hogy hány pixeles a kijelző de annak méretével egyáltalán nem.
Nem sokára jönnek a full HD-s mobilok és a jelenlegi responsive oldalaknak az majd elég fura kihívást fog okozni. Eddig ez nem volt gond, mert minél kisebb volt a felbontás (valószínűleg) annál kisebb volt a kijelző fizikai mérete is. Viszont ez a trend idén megváltozik. Sok laptop 13"-on még csak 1366x768 míg idén 4-5"-on jönnek a full HD mobilok.

Van amit én értettem félre a responsive design kapcsán vagy ez a probléma nemsokára valósággá válik?

Felbontás (dpi || ppi)
http://www.w3.org/TR/css3-mediaqueries/#resolution

https://developer.mozilla.org/en-US/docs/CSS/resolution

http://bjango.com/articles/min-device-pixel-ratio/

Linkek a témában
Alap responsive CSS (fen említett gondra nem megoldás):
http://css-tricks.com/snippets/css/media-queries-for-standard-devices/

Responsive grid:
http://foundation.zurb.com/

Eszközök és felbontásaik (ppi / css ratio):
http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density

RetinaJS (nagyobb felbontásnál kicseréli a képeket nagyobbra):
http://retinajs.com/

Eszköz detektáló PHP osztály:
http://mobiledetect.net/

Kezdem érteni... (és talán másnak is el tudom már magyarázni)
Kicsit nehezen ment, de megértettem. (Elnézést azoktól akiket kifárasztottam az értetlenkedésemmel) Demo-ra készítettem egy egyszerű 100x100px kockát ami különböző színű lesz ahogy a böngészőt átméretezem illetve kiírja az aktuális pixelek számát. Na ez az utóbbi okozta a meglepetést, ugyanis a telefonom ami 1280x720-as felbontású CSS számára (initial-scale=1) csak 640x360 (vagyis pont fele).

Tehát a telefon valós felbontása: 1280x720
initial-scale=0 akkor a css pixelek száma: 640x480*
initial-scale=0.25 akkor a css pixelek száma: 2560x1440
initial-scale=0.5 akkor a css pixelek száma: 1280x720
initial-scale=1 akkor a css pixelek száma: 640x480
initial-scale=2 akkor a css pixelek száma: 320x180

http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density (köszi hakosh)

*Ha a meta tag-nek nem adom meg az initial-scale-t, akkor 1-et vesz alapul.

DEMO amely segít megérteni ezt az egészet: http://funky.hu/css.php
(ígyekeztem úgy csinálni, hogy könnyen olvasható legyen a forrás)

  • 10626 megtekintés

( cherockee v | 2013. 02. 22., p – 12:20 )

nem értetted félre, ez a probléma már valóság. tényleg csak kijelző szélessége alapján változtatja a css a sheet-et.

a vicces a témában az az, hogy régen ugye volt egy külön sablonlapokból álló weblap, ami a useragent alapján ezt vagy azt dobta a készüléknek...aztán jött a responsive css, media típusától függőt adott vissza, leginkább képernyő szélesség alapján...most szerintem vissza fogunk térni arra, hogy lesz egy 3-5 col körüli nézet a weboldalhoz, lesz egy 7-10 color, és egy 10+-os, DE ezt useragent alapján kapcsolgatjuk. igazából nem a pixelszám lesz a lényeg, hanem a fizikai méret, ahogy írod.

(valamelyik nap pont felötlött bennem ez...)

Ez egy jó leírás a témában:
http://www.ibm.com/developerworks/library/wa-cssqueries/index.html

...de azt hiszem ezt kell kombinálni a jelenlegi megoldással (dpi detect):
http://www.infobyip.com/detectmonitordpi.php

Akár egy ilyen "láthatatlan" megoldás is alkalmazható, majd cookie-ban letárolás:
http://stackoverflow.com/questions/9292156/how-to-detect-the-screen-dpi…

Mert a bongeszoengine, ha azt kerik tole, hogy 1 inches szelessegu/magassagu divet hozzon letre, azt 96 pixelen fogja megtenni, o sincs tisztaban azzal, hogy mekkora a valos DPI.
Sot, a kulonfele oprendszerekben meg is lehet mondani, hogy az OS mekkora DPI-t hazudjon az alkalmazasok fele.

( log69 | 2013. 02. 22., p – 14:57 )

Kár hogy így agyon van hack-elve az egész web.

A tartalom szolgáltatónak meg kellene mondania, hogy _mit_ akar a képernyőre printelni (nem azt hogy hogyan), a tartalom megjelenítőnek meg a saját környezete alapján megjelenítenie azt (és nem a tartalmon változtatni). Ebből indult ki az egész, és úgy lenne ma is a legjobb. Amit spórolnak a réven, elmegy a vámon.

És jelenleg pont ezt teszik a mobil böngészők...

Az alapvető probléma az, hogy mindkét oldal elindult a maga evolúcióján és most a félúton rájöttek, hogy kilométerekre vannak egymástól és az egyik megoldás szögletes a másik meg kör alakú.

A mobil böngészők fejlesztői az elmúlt években mindent megtettek, hogy jobb-rosszabb megoldásokkal, de egészen meglepően jó eredményt érjenek el a rendes weboldalak megjelenítésénél. Egy 4,5"-os telefonon 1280x720-on én teljesen jól el tudok netezni. (Kivéve, amikor ilyen okosságokkal megturbósítják az oldalt, mint az FB-n a görgetősáv, aztán meg megy a pislogás, hogy hogyan is fogok egy 4 hónapja írt könyvajánló részlethez visszascrollozni mobilon). Meg ugyanígy elindult a webes ipar is arra, hogy mindenfélére megjelenítse különféle módon a tartalmat, persze plusz munkával. Bár, hogy azt, hogyan gondolják egyesek, hogy fullhd monitort azért veszek, hogy utána egy oldal terítse be az egészet, az már roppant mód érdekelne....

Aztán ugye a két koncepció eléggé üti egymást.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

( kdani3 | 2013. 02. 22., p – 19:24 )

A nagy felbontású, de kis méretű kijelzőkön elég lehet nagyobb betűméretet használni. Hiszen amíg a kijelző nem nagyobb, nem fér el rajta olvashatóan több szöveg. Ezt a mobilos böngészőknek kellene megoldani, legalábbis ha az oldal reszponzív és em szerint van méretezve, akkor már lehet vele kezdeni valamit. Vagy pedig lehet egy kisebb felbontást "hazudni", de a szöveget és a képeket szebben kirajzolni.

( ksgy | 2013. 02. 23., szo – 05:39 )

Ott a pont (pt) mint mertekegyseg. Az fizikai meret fuggo. Ergo ha egy pl font 12pt meretu egy mobilon, az 12pt lesz egy fullhd monitoron is. Nem csak px-ben lehet mereteket megadni, ott van az em, a %, a pt, stb. Vegre elfelejtodik a pixelpontos design fogalma es atalakul relativ meretekke. \o/

Vagy csak en nem ertem hol (lesz) a problema :)

--
x-plane :: hu

Igazad lenne, de px nem véletlen terjedt el ennyire (ez az egy dolog ami biztos a kliensen). (IE6 alatt volt egy ellenérv: nem nagyítható. Ma pedig mellette: IE6 halott!) A relatív értékek és nyomdai-érték anno elég érdekesen néztek ki különböző gépeken még akkor is, ha minden szoftver azonos volt (gondolom ez ma sem változott). Egyszerűen lehetetlen volt velük olyan oldalt készíteni, ami mindenhol ugyanúgy néz ki.

Ha pl.: em-et vagy %-ot használ az ember, akkor a felhasználói beállításokra bízza magát, kivéve, ha http://www.cssreset.com/ -t (vagy valami hasonlót) használ. Szerintem ez nem a legmegfelelőbb hozzáállás, mert el tudok képzelni olyan okot, amikor a felhasználó joggal használ 3x akkora betűt (pl.: nem lát).
Az 1em alapból minden böngészőn 16px lenne. Vagyis az is pixelben számol. A felhasználó dönthet úgy, hogy 20px legyen 1em. Ekkor reset.css használatával élhet a fejlesztő vagy alkalmazkodik a felhasználóhoz.
Ma már a böngészők zoommal nagyítanak méreteznek, nem betűméret állítgatásával, így igazából ez már semleges.

1 em = 16px = ~21,33 pt = ~1,77 pc
1 inch = 6 pc = 72 pt
72*(4/3) = 54px (abból indul ki, hogy 96dpi a monitorod)

http://css-tricks.com/css-font-size/
http://fantasai.inkedblade.net/style/specs/css2.1/pt-unit
http://www.w3.org/Style/Examples/007/units

ps.: a pixelnél nincs relatív öröklődés, vagyis nem a szülő méretéhez képest relatív állítja a méretet. Ez akkor lehet gond pl az em-nél, ha a site-ot átszervezed.

"Ergo ha egy pl font 12pt meretu egy mobilon, az 12pt lesz egy fullhd monitoron is."
Ez csak akkor igaz, ha a rendering engine tudja a kijelzo VALOS, fizikai dpi erteket, nem pedig az OS altal neki hazudott logikai DPI-t kapja meg.

Ugyanez igaz minden mas valodi hosszmertekegysegre, legyen az mm, inch, vagy barmi mas, a tipografiai pont sem kivetel.

( hakosh | 2013. 02. 24., v – 02:54 )

A megoldás az, hogy egy CSS pixel != egy fizikai pixel. Bővebben: http://www.quirksmode.org/blog/archives/2010/04/a_pixel_is_not.html

Például linkelted a Foundation frameworköt. Gondolom a dokumentációt is nézted, ahol azt olvastad, hogy a breakpoint 768px-nél van. Alatta mobil, felette desktop (meg a többi). Ha megnézem a telefonomról, ami landscape módban 800px széles, akkor mégis a mobil oldalt látom. http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density itt azt írja, hogy 1.5 a CSS pixel ratio, azaz az én 800px széles mobilom olyan 530 körül van CSS pixelekben.

"A megoldás az, hogy egy CSS pixel != egy fizikai pixel."
Igen, mivel az alkalmazas (render engine) altal hasznalt (OS-tol kapott) DPI nem egyenlo a valos DPI-vel. Errol szol ez az egesz.

Ezert 1 CSS inch != 1 fizikai inch es igy tovabb.

Mivel JS-bol csak a rendering engine altal ismert (es a fizikaival nem feltetlenul, sot altalaban nem egyezo) DPI-t tudod lekerdezni, valodi responsive designra nincs lehetoseg most.

( log69 | 2013. 02. 24., v – 20:38 )

A DEMO-d jól megy nálam Linux desktop-on FF böngészőben (v17).

Nem úgy mobilon. SG 3-on Opera Mobile-al zöld (201-400), elforgatva piros (401-600) - Stock böngészővel szintén zöld és elforgatva sárga (601-800) - Chrome mobile-al megint zöld és sárga - míg a natív felbontása a telónak 1280 x 720.

Próbáld meg, hogy átállítod az initial-scale-t (0.5 | 1 | 1.5 | 2) értékekkel.

Natív felbontás nem számít. initial-scale állítja be a CSS felbontást a valóshoz képest. Ez az oka annak, hogy nagy-felbontású telefonon is a kisebbik CSS jelenik meg, pl itt.: http://foundation.zurb.com/
Ha ez nem így lenne, akkor jönne az a probléma amit felvázoltam topikban.

( mn3monic v | 2013. 02. 25., h – 00:05 )

Firefox 20-ban van Responsive design view, lehet tesztelni :)

Firefox 15 óta és ez csak átméretezi a viewportot. Kár, hogy nem lehet vele hidpi kijelzőket szimulálni.

Más: az egész viewport témát és a kapcsolódó fogalmakat először innen értettem meg: http://developer.android.com/guide/webapps/targeting.html Igaz, webkit only, de az elmélet a lényeg.