ugrás a tartalomhoz

Johnny Cage Wins

yaanno · 2010. Már. 20. (Szo), 15.49
Johnny Cage és Sub Zero újra összecsap, ezúttal azonban a böngészőben. Nem, nem egy újabb canvasra épülő játékról van szó, hanem arról, ahogyan a CSS, HTML és JavaScript együttes működése befolyásolja a megjelenítendő tartalmat.

A mai modern web imádja az animációkat, és abban a szerencsében van részünk, hogy a legtöbb JavaScript függvénykönyvtár tartalmaz – vagy pluginek, modulok segítségével kiegészíthető úgy, hogy tartalmazzon – ilyen függvényeket. Ki ne gyönyörködne egy szépen lenyíló sliderben vagy accordionban, nem igaz?

A probléma ott van, hogy Johnny Cage (aka JavaScript) akárhogyan is erőlködik a böngészőben, a gondosan megírt easing bizony néha szaggatottá válik, az animáció pedig elveszíti értelmét, mert mind esztétikailag, mind felhasználói élmény szempontból inkább zavaró.

Mi lehet a gond? Vajon Scorpion (aka HTML) kavar be nekünk? Ez viszonylag könnyen tesztelhető például egy leegyszerűsített struktúrájú dokumentummal, csupán néhány elemet elhelyezve a DOM fában. Sajnos sok esetben ez sem segít, bár kétségtelen, hogy a kevésbé bonyolult fa optimálisabb vizuális élményt és számítási időt jelent.

A gondot gyakran Sub Zero (aka CSS) okozza, pontosabban az átgondolatlanság. Biztos, hogy érdemes a wrapper elemre egy box-shadow tulajdonságot erőltetni? Miért ne? A modern böngészők támogatják. Ez így igaz – azt viszont kihagytunk a számításból, hogy egy szerencsétlen konstellációt sikerül összehozni, ha például a wrapper elemen belül egy slidert vagy accordiont helyezünk el. Az animáció futásakor a böngészőnk folyamatosan újrarajzolja (reflow) a dokumentum bizonyos elemeit. Ebben az esetben sajnos nem csupán a slidert vagy accordiont, hanem a wrapper elemet is, mégpedig az animációban beállított léptetéssel arányosan!

A pontos részletekért és jótanácsokért érdemes átolvasni Nicole Sullivan (Yahoo! mérnök) Reflows & Repaints: CSS Performance making your JavaScript slow? c. blogbejegyzését.

PLUR.
 
1

FPS mérés

sly · 2010. Már. 20. (Szo), 17.16
Anno FPS-t mérésen is agyaltam. :) Ha az előzőt túl sokáig számolgatta, akkor a következőt kihagyta volna. :)
15

Meg lehet oldani

inf3rno · 2010. Már. 21. (V), 16.58
Én anno setInterval-nál a timeStampek különbségével néztem, hogy a két hívás között mennyi idő telt el, aztán ebből már lehet számolni fps-t, meg azt, hogy valójában hol tartunk időben. Ha elcsúszik, akkor lejjebb lehet venni az fps-t. Alacsony fps-nél kicsit szaggatni fog, de legalább nem 2 perces lesz az animáció...
Még nem néztem meg, hogy keretrendszerekkel hogyan oldják meg mindezt, de kíváncsi lennék.
2

Erőszak

Max Logan · 2010. Már. 20. (Szo), 17.49
Na kb. ezért is írtam a közelmúltban azt, hogy nagyon nem tartom jó iránynak a WEB fejlődése tekintetében a HTML5, CSS3 kombót. Az előzőleg megnevezett két "nyelv" alapvetően szöveges dokumentumok megalkotására való, nem pedig csilli-villi dinamikus UI megvalósítására.

Ennek okán a JS-sel való megerőszakolás számomra egyszerűen elfogadhatatlan koncepció. Kellene egy új megközelítés technológiai szempontból, de nem leszek túl naiv, ez nem fog bekövetkezni (legalábbis egyelőre még nem; előbb-utóbb azt hiszem elkerülhetetlen lesz -- a számítástechnika átalakulóban van, ergó kellenek az új megoldások; a visszafelé kompatibilitás (egy bizonyos ponton túl) pedig mindig is az új dolgok térnyerésének akadályozója lesz).
3

Sose lesz szerintem teljesen

sly · 2010. Már. 20. (Szo), 18.00
Sose lesz szerintem teljesen jó, mert mindig változnak az igények. Néha próbálják terelni, de nem mindig jön be (XHTML). Én is teljesen másképpen csináltam volna. Mivel a határok elég tágak ezért sok mindent meg lehet oldani úgy is ahogy te elképzelted (nagyjából). :)
4

Változó igények

Max Logan · 2010. Már. 20. (Szo), 18.09
A változó igényekre reagálni kell. Ettől megy előre a világ. De a nem ideális technológiát meglátásom szerint nem kellene foltozni, hanem ki kellene dolgozni egy újat. Ha lesz HTML10 és CSS7 akkor sem lesz ideálisabb a helyzet, mert a böngésző gyártók akkor sem fogják egységesen implementálni az ajánlásokat, így végeredményben minden ott fog tartani, mint most, csak sokkal "okosabb" lesz az implementálandó ajánlás.

Erről hosszan és sokáig lehetne vitázni, aminek végeredményben a jelen helyzetre sok hatása nem lenne. Én a magam részéről nem tudok egyet érteni a fejlődés technológiai irányával.
5

Éppen ellenkezőleg!

yaanno · 2010. Már. 20. (Szo), 19.38
A HTML5 eleve azért jött létre, hogy modern webalkalmazásokat tudjunk készíteni, aminek némileg gátat szab az XHTML szabvány (ez erős feltevések mellett igaz); a CSS3 pedig egy logikus továbblépés. A HTML, CSS és JavaScript kombóval igen erős webalkalmazásokat lehet készíteni, lásd pl. liligo.com vagy flowdock.com. Az én kis tűnődésem arról szólt, hogy óvatosan kell hozzányúlni a webdokumentumhoz, mert nem várt következményei lehetnek egy-egy "rosszul" megejtett értékadásnak.
6

Akadályoztatás

Joó Ádám · 2010. Már. 20. (Szo), 20.32
Hogy érted, hogy az XHTML gátat szab valaminek? Egyáltalán, mit értesz XHTML alatt?
7

HTML ős

saxus · 2010. Már. 20. (Szo), 21.42
XHTML-t nagyon sokan úgy kezelik, mint egy szigorúbb validálást igénylő HTML4 és nem is tudják, hogy igazából az egy XML fájl és hogy egyáltalán nem kellene ragaszkodni ahhoz, hogy div halmokat írjunk, lehetne sokkal kifejezőbb XML tageket is írni, amit aztán valamilyen egyéb megoldással (pl. XSLT) is feldolgozhatunk.

Persze, ehhez az IE6-nak is ki kell halnia.
16

XHTML alatt az XHTML1.1

yaanno · 2010. Már. 21. (V), 20.44
XHTML alatt az XHTML1.1 szabványban adottakat értem. Ezzel persze részben ellentmondok saját magamnak, hiszen ez éppen arról szól, hogy kiterjeszthetjük az elemkészletet stb. Úgy fogalmaznék inkább, hogy nem túlságosan praktikus webalkalmazások készítésekor. Amúgy XHTML5, legalábbis én ezt az irányt igyekszem alkalmazni a gyakorlatban.
8

Szöveges dokumentum vs. multimédiás prezentációs felület

Max Logan · 2010. Már. 20. (Szo), 21.46
A WEB a mai formájában inkább egy Flash szerű, eleve multimédiás célokat szolgáló technológiát követelne meg, melynek a szöveg fontos része, de már közel sem a központi.

Ennek azonban ellent mond az, hogy a keresők (még) főként a szövegek alapján találják meg a tartalmat, valamint, hogy sok esetben szöveget akarunk prezentálni (lásd. cikkek, blogok).

Bár ez utóbbi esetben a HTML azért kellemes környezet (mert a szövegen van a hangsúly, a többi csak kiegészítő elem (pl. kép mint illusztráció, videó betét)), de komoly webalkalmazás, admin felület, csilli-villi designos honlap esetén (ahol komoly UI van) a HTML már meg van erőszakolva.

UI-t nem erre kitalált technológiák egyvelegével hozunk létre, ami az egységes böngészőimplementáció hiányában csak megkeseríti a fejlesztők életét.


Nem tudom igazán szavakba önteni, amit mondani akarok. Konkrét technológiai tippem nincsen, hogy merre kellene elmenni, de valami olyasmi lenne jó, hogy van egy felület, amire lehet különböző "layer"-eket felvinni. Ezen layer-ek egyike lenne a szöveg, a másik a videó, a harmadik az audio tartalom, a negyedik a UI és ezeknek lenne valamilyen együttműködése.

Ha jól sejtem, akkor a Flash kb. ilyen a funkcionalitás területén. Na kb. ezt kellene megalkotni a flash binárisa helyett szöveg alapú technológiákkal. Nem tudom, hogy érthető-e a gondolatmenet?

Az egyes keresők pedig hozzáférnének pl. a text layer-hez, így csak a szöveget tudnák indexelni, videókeresők pedig alapvetően csak a video layer-t checkolnák (ahol az egyes videóknak persze meglennének a saját attributumai; leírás, tag-ek, stb).

A végeredmény kb. ugyanaz lenne, mint egy mostani full JS based és/vagy flash based honlapnak, csak a gépi fogyasztása és az előállítása sokkal jobban megoldható lenne. Persze ez a megoldás is megkövetelné az egységes böngészőbeli implementációt (ezért is vetettem fel valamikor régebben a közös render engine kérdését), mely az eddigiek alapján igencsak utópisztikus gondolatnak tűnik.
9

Igen

Joó Ádám · 2010. Már. 20. (Szo), 22.30
A megoldási javaslattal nem feltétlenül, de a jelen diagnózisával teljes mértékben egyetértek. De ezt úgyis tudjátok.
10

Csak elvi elgondolás volt ...

Max Logan · 2010. Már. 20. (Szo), 22.46
... nem konkrét javaslat (ahhoz én kicsi porszem vagyok a gépezetben) ;-)
11

Alkalmazás vs utánzás

saxus · 2010. Már. 21. (V), 00.04
HTML egy dokumentum-leírónyelv. HTTP egy kérés-válasz alapú protokol.

Persze, le lehet utánozni tetszőleges alkalmazás felületét HTML-ben, mögé lehet rakni JS-ben egy hasonló funkcionalitást és meg lehet oldani azt is, hogy látszólag kétirányú legyen a HTTP kapcsolat.

Ettől ez még csak egy utánzás. A HTML kód ugyanúgy egy nagy katyvasz, nincs elválasztva benne az adat és az UI, protokolt nem erre találták ki, stb.

Ha feldobok egy DataGridView pl. egy Visual Studioban, akkor az egy Control. Nem div-k és table-k halmaza. Ha hozzábindelek egy adatforrást, akkor azok adatok. Az lényegtelen, hogy most egy object lista gyűjteménye, egy SQL query eredménye vagy egy XML fájl. És ha kell, tudok rendes progress bar-t odatenni az user elé, hogy bocs, ez most el fog tartani egy darabig. És utána majd a folyamatot végző szál fog szólni az UI-nak, hogy rendben, köszi, most már eltűnhetsz.

Ezek mind-mind olyan dolgok, amikre csak kerülőmegoldásokkal lehet megoldani.

Persze, lehet azzal jönni, hogy a webes szakma kinőtte magát. Tény, kinőtte. Itt lenne az ideje továbblépni és visszaállni az *alkalmazások* fejlesztésére.

Értem én, hogy sokaknak a világnézetét sérti azoknak a kijelentése, akik szerint a mai web rossz irányba halad és az egész HTML+CSS+JS+HTTP erre a célra való felhasználása egy nagy gányolásra hasonlít - és ezzel a kijelentéssel egyetértek én is úgy, hogy szintén webből keresem a kenyerem.

Véleményem szerint, hosszú távon sokkal inkább igény lenne egy új protokol és környezet kifejlesztése webes alkalmazások részére. Kezdeményezések már régen megindultak, (ld. Java, Flash, Silverlight, JavaFX...) csak sajnos egyik se mert igazán elszakadni a webtől és a HTTP-től.
12

Az alapoktól

Max Logan · 2010. Már. 21. (V), 00.31
Nos igen, a WEB, mint olyan az elmúlt 15 évben túlnőtt azon, aminek indult. Nagyon más ma, és az IT, szórakoztatóipar fejlődésének irányai arra engednek következtetni, hogy a mostani helyzetnél sokkal jobban át fog alakulni az internet.

Már nem dokumentumraktár lesz, hanem valódi hálózat minden között (a végén már tényleg minden elektronikai kütyü a hálózat része lesz). Ennek megfelelően pedig újra kell értelmezni a WEB-et, mint olyat. És ha ez megtörténik, na majd akkor lehet azt mondani, hogy itt a webkettő -- persze szigorúan szerintem.
13

Egyetértek

saxus · 2010. Már. 21. (V), 01.29
Ellenben az ipar a HTML+CSS+JS+HTTP kombót akarja ráhúzni mindenre. Sajnos. És még a kérdést se teszik fel, hogy jó-e ez nekünk.
14

Kérdésfeltevés

Joó Ádám · 2010. Már. 21. (V), 02.03
Merd csak feltenni a kérdést :)

(„Ugyan, ha az egyik ki akar mászni, a többi visszahúzza” – azoknak, akik ismerik a viccet.)
17

A HTML, CSS és JavaScript

yaanno · 2010. Már. 21. (V), 20.52
A HTML, CSS és JavaScript alapú fejlesztés legfőbb előnye az olcsóság és a viszonylag könnyű fenntarthatóság. Bocs, de én úgy szeretnék a kis virágüzletemnek honlapot, hogy az költséghatékony legyen. És azt hiszem, a webalkalmazásokban gondolkodó cégek is éppen ezért választják előszeretettel ezt a megoldást.