Ezért nem jó a túlzott CSS + JS

 ( log69 | 2013. január 11., péntek - 9:58 )

Kép itt.

"Firefox / View / Zoom / Zoom Text Only" menüpont bekapcsolva, és így egy olyan piacvezető cég, mint G weboldala sem nagyítható normálisan. Szerintetek ez így helyes és megfelelő megoldás?

Miért jó fix szélességgel beégetni az oldalba objektumokat. Eleve miért kell ilyen szinten, ekkora aprólékossággal szétformázni? A forrást megnézve töménytelen JS tele fix szélességű beállításokkal.

Tudom, ne akarjak nagyítani. Szerintem ez hack és gányolás, főleg egy ekkora cégtől.

Kikapcsolt JS mellett valamivel jobb a helyzet.

Hasonlót látok nap mint nap, pl. fix méretű gombokra adott betűtípus méretű felirat rakva meg hasonlók. Nagyításnál kifolyik a font a gomb mellé. Kikapcsolt JS nélkül meg egy üres kép fogad sok weboldalon, semmilyen alap szinten nem biztosítva a használhatóságot (komoly nagy cégek és állami weboldalak is beleértve).

Az nekem nem válasz, hogy a piac igényli ezt. Kérdésem, hogy ez jó-e így szerintetek, és miért? (A funkcionalitástól elvonatkoztatva a megjelenést figyelembe véve).

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Igen. Mivel a trendek és az okos telefonok miatt is ma már nem tudod kihagyni a js-t. Amúgy meg hogy mókolni kell az köszönhető a css3 késői terjedésének (implementáció szinten) és az Internet Explorernek.

Nem jó, de hozzá kell szokni :(

Én már évek óta mondom, hogy nagyon rossz az az irány, amerre a web halad ezzel a HTML + JS + CSS nyűglődéssel.

De a technológia rossz szerinted, vagy a felhasználási módja - esetleg mindkettő?

Is-is. Egy olyan technológiát használnak kényszerűségből, ami egyrészt nem erre való, másrészt addig patkolgatták, míg brutál hackelések árán ki lehet belőle hozni azt, amit más platformok már évek óta meghaladtak.

A felhasználási módnál meg még csak most fognak előjönni az igazi ocsmányságok, mint a webapp által felüldefiniált shortcutok (Google már el is kezdte), amik elfedik a böngésző shortcutjait, de említhetném a lassan mindenhol jelenlévő ajax-os betöltős szórakozásokat is, amitől a layout úgy ugrál, mint ahogy a bolha se szokott stb.

Szerk:

Plusz nagyon sok helyen nincs megoldva rendesen az Ajaxos cuccoknál a visszalépés (ld. 9gag). Show more, show more, rákattintok egy linkre, visszagomb és máris megint az első adag végén találom magam. Nyilván megoldható ez is, de egyelőre úgy szar az egész ahogy van :(

Milyen érdekes és elgondolkodtató ami írsz.. Régóta megalkotott "fejlett" technológiákat kell lecserélni megint és megint egy kezdetleges és újra evolválóra bizonyos trendváltások miatt, és újra fel kell találni a kereket - vagy legalábbis a megváltozott feltétel- és igényrendszerek miatt össze nem passzoló elveket és dolgokat kell újra egyeztetni / összeilleszteni - a tulajdonságok különbsége miatt a kétes végeredmény lehetőségével.

Miert text only zoom?
--
HUP Firefox extension

Hogy nagyításnál lehetőleg vízszintes irányban ne nőjön az oldal, hanem csak függőlegesen, vagy legalábbis csak annyit, amennyire a betűtípus nagysága indokolja. Ha nincs bekapcsolva, akkor durva mód nő a képek nagyítása miatt, és ezért a felnagyított oldalon sokat kell feleslegesen scrollozni oldal irányban, amely a használhatóság rovására megy. Nem beszélve a felnagyításból eredő homályos képekről, amelyek fix felbontásra lettek tervezve.

Persze szerintem a régebben alapértelmezett text only nagyítást is pont a mai hack-ek miatt váltotta le a ma alapértelmezett képpel együtt nagyító megoldás, hogy a weboldalak vizuális struktúrája ne essen szét.

Minden weboldal úgy készül, hogy először csinálnak egy látványtervet, ami tulképp egy kép. Majd ezt átültetik web-re. Ahhoz, hogy a weben megjelenő izé ugyanúgy nézzen ki mint a kép, ahhoz olyan megoldások kellenek, amiket te gányolásnak nevezel, talán joggal. Amikor a html+css+js készül, akkor már késő okosnak lenni, amikor a látványterv készül akkor kellene előre gondolkozni. De nem teszik, nem hogy zoomolásra nem gondol senki, hanem sokkal-sokkal alapvetőbb dolgokra sem. Pl. hogy nézzen ki egy form elem ha éppen írok bele. Vagy egy link ha fölötte van az egér. Mivel a látványterv kép, ezért nem tudnak ilyenekre előre gondolni.

Igen, sok helyen azt látom, hogy design-erek szeretnék a weboldalt egy általuk elképzelt képhez megegyezőre megalkotni, holott nem így lett tervezve a web / nem erre találták ki / nem ez lenne a célja stb. Tehát a gond szerintem is az, hogy design mindenek felett - akár a használhatóság rovására is.

Sajnos jártunk így webfejlesztővel, hogy fotósopban megcsinálta a látványtervet - tegyük hozzá, hogy az elég pofás lett -, de smarty-ra már nem tudta implementálni. Tulajdonképpen html-re se, mert ők - az átadott html kódból kiindulva - úgy szokták csinálni, hogy a psd-t exportálják html-be, és részükről kész a webdesign.

A vicc az, hogy amit így csináltak, az majdnem tökéletes volt, csak a doctype tért el a smarty template-ben, így amit copy-paste beletettek, az épp nem lett jó. Itt el is akadtak.

Ebben több dolgot nem értek: nem épp az a cél, hogy a megjelenés elkülönüljön a működéstől?
Hogy lehet psd-ből közvetlenül html-be konvertálni?
A webdesigner-nek nem pont az a feladata, hogy pixel pontosan elkészítse az oldalt, a grafikus látványterve alapján?

1. De.
2. Nem tudom, de amit adtak html-table-szörnyet, azt nem ember csinálta (pláne hogy ha annyira űberprofi, akkor a doctype miért okozott gondot?)
3. De. De nem tudták megcsinálni. Szóltunk több ízben, ha elakadnak, egyszerűsíteni kell, segíteni kell, akkor szóljanak és megdumáljuk.

A történet vége, hogy én egy délután összeraktam a smarty-val azt, amit két hét alatt nem bírtak megszülni. Igaz nem pontosan ugyanazt, mert én kihagytam belőle az egypixeles mókolásokat, amit ők is kihagyhattak volna, ha szólnak, hogy sok macera. De a gond nem ezzel volt (v.ö: szétesett oldal vs. doctype).

Én vagyok a hülye, de ugye ha nem csak textet nagyítok, akkor minden remek: http://i.imgur.com/dBeqj.png

Persze ha csak a képeket nagyítanám, vagy csak az "a" betűket, akkor széthullana. Vagy ha csak minden második pixelt.

Az, hogy állatira tele van js-el nem feltétlen baj. Szép az oldal? Gyors? Megbízhatóan működik? És nem árt figyelembe venni azt se, hogy a kiszolgáló oldal terhelése egy-egy trükkel (pl. css sprite) nagy mértékben csökkenthető. Az ajaxos megoldással szintén. És nem feltétlen kell ugrálnia az oldalnak, csakhát azt is lehet rosszul csinálni.

"..de ugye ha nem csak textet nagyítok, akkor minden remek..."

http://hup.hu/node/120981?comments_per_page=9999#comment-1555357

"..Persze ha csak a képeket nagyítanám..."

Ennek nincs értelme számomra.

"Az, hogy állatira tele van js-el nem feltétlen baj."

Ezt megindokolnád?

"Szép az oldal? Gyors? Megbízhatóan működik?"

Nem. Pont ez a baj. A web által (eddig?) biztosított lehetőségeket használva éppen nem. Szerintem legalábbis (a feljebb leírtak miatt).

Nem is arra akartam célozni a témával, hogy lehet rosszul csinálni. Ez mindenre igaz. Hanem hogy piacvezető cégek miért csinálják rosszul ha lehet jól is?

"Ennek nincs értelme számomra."

Van egy összehangolt rendszer, aminek egyes részeit elhangolod. Persze hogy nem lesz jó.

Ezt megindokolnád?

Írtam: "...nem árt figyelembe venni azt se, hogy a kiszolgáló oldal terhelése egy-egy trükkel (pl. css sprite) nagy mértékben csökkenthető. Az ajaxos megoldással szintén."

A megbízható működés szerintem megvan. Ha egy oldalt nagyítok, akkor miért csak a szöveget nagyítsa? Ha kinyomtatsz egy pdf-et, ami A4-es, mondjuk A0-s méretben, akkor a képek maradjanak kicsik, mert te csak a szöveget akarod nagyba látni? Szerintem az a normális, ha az egész lap skálázódik, nem csak egyes részei.

Ugyanakkor kicsit átgondolva nem is biztos, hogy az oldalak a rosszak, hiszen a skálázás nyugodtan kiterjedhetne pl. a div, table, stb. tagokra is, hiszen egy div az nem kép (bár nem is szöveg, ugye). Ha viszont elvárás, hogy az adott lapbeosztást meg kell tartani, azaz a lap szélessége maradjon annyi amennyi, akkor mindegy, hogy az adott menüpont szélessége 200px vagy 13,4%, szövegnagyításnál úgyis szét (össze) fog esni. Ha meg lehet a beosztást skálázni, akkor meg ott vagyunk amit elsőnek írtam, hogy működik.

Kicsit kapkodok, mert ebéd van, ehe.

Jóétvágyat! (most várom én is a spagettimet..)

"Van egy összehangolt rendszer, aminek egyes részeit elhangolod. Persze hogy nem lesz jó."

Egy ~20(?) éves trendről van szó, amelyet pár éve megváltoztattak. A web-nél alap volt a HTML oldal nagyítása akárhogy, amely kizárólag a betűtípus méretére vonatkozott (fix me).

Gondoljuk végig hogy mi a cél. Számomra 2 db: olvashatóság és használhatóság. Ilyen szempontból vizsgálva az oldalt jogos az igény (amely egy legalább több mint 1 évtizedes hagyomány része), hogy nagyíthassam a betűket. Mint feljebb írtam, ha a képeket és egyéb struktúrát is nagyítja, akkor lehet majd oldalra is scrollozni folyamatosan. Ez nagy mértékben rontja a használhatóságot.

A képek nagyításának mi értelme? Ja igen, hogy az összehekkelt struktúra ne essen szét. Legalábbis ezen kívül nem tudok jobb érvet. Egy homályos felnagyított képnek nem látom értelmét, főleg hogy nem egy limitált mértékig nagyítja, hanem ameddig te nagyítod a szöveggel együtt. Nem vagyok meggyőzve az érved által.

A megbízhatóságot nem firtattam, mint feljebb is írtam, a funkcionális működést nem figyelembe véve vizsgálom a megjelenést (és ezzel a használhatóságot, mivel a megjelenésnek ehhez mindenképp hozzá kellene járulnia szerintem, főleg piacvezető megoldásoknál).

"..úgyis szét (össze) fog esni..."

Nem igaz, nézz meg egy rendes oldalt (pl. ezt ;))

Mi az értelme a teljes zoomnak?

A különböző felbontású eszközök. Lásd mobiltelefonok, ahol az egyik készülék 320x480 (3,5") a másik meg a 1920x1080(5,5") felbontású.

Legyen külön mobil verzió.

Hagyd default értéken a device pixel ratio-t.

Ez az oldal valóban nem esik szét (össze), ám a funkcionalitása icipici töredéke pl. a google keresőoldalának. A funkciókra pedig szükség van (az, hogy ez valós, vagy mesterségesen gerjesztett igény az más kérdés), és ezek megvalósítása js nélkül sokszor értelmetlen.

A fix méretek, szélességek, pixelek: a design megtartása miatt, hogy az egyes funkciók épp úgy és ott legyenek elérhetőek ahol az szokott lenni, ne ugráljon össze-vissza a menü :D

+1

"Szép az oldal? Gyors? Megbízhatóan működik?"

Igy aztán tkp. lehetne ez egész web mappelt png is (ami a csupaflash oldalak láttán nem is túlzás).

Szerintem nem lehet gond a js, csak fallbackről is kellene gondoskodni. Az ilyesmit meg nem mindenki szereti kifizetni (pedig csak annyiról van szó, hogy az adott rész formázását kétszer kellene definiálni css-ben).

Ha a javascriptet funkcionalitás- (ux) kiteljesítésére használnák, nem lenne semmi gond.

én se bírom ki a fixed szélességõ ojjektumokat.
a html-nek van saját geometry motorja (még text-based böngészõkbe is implementálták). a lehetsõgeinek mellõzése szerintem extra regresszív.

~~~~~~~~
http://www.youtube.com/watch?v=VbUVqODL1nE