Johnny Cage Wins
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
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.
■ 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.
FPS mérés
Meg lehet oldani
Még nem néztem meg, hogy keretrendszerekkel hogyan oldják meg mindezt, de kíváncsi lennék.
Erőszak
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).
Sose lesz szerintem teljesen
Változó igények
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.
Éppen ellenkezőleg!
Akadályoztatás
HTML ős
Persze, ehhez az IE6-nak is ki kell halnia.
XHTML alatt az XHTML1.1
Szöveges dokumentum vs. multimédiás prezentációs felület
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.
Igen
Csak elvi elgondolás volt ...
Alkalmazás vs utánzás
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.
Az alapoktól
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.
Egyetértek
Kérdésfeltevés
(„Ugyan, ha az egyik ki akar mászni, a többi visszahúzza” – azoknak, akik ismerik a viccet.)
A HTML, CSS és JavaScript