Az Operának régóta sok gondot okoznak a nem szabványos, böngészőspecifikusan megírt, vagy éppen elavult oldalak. Ez ellen sokféle módon próbálnak védekezni, ma az oldalakat betöltődés közben javító browser.js-ről lesz szó.

Ez a bejegyzés az "Opera's site patching" című cikk fordítása. Az eredeti cikk 2009. április 7-én jelent meg a Core blogon.

Tudod, a web technológiák komplexitása kezelhetetlenné válik, amikor minden egyes oldal valami egyedi kezelést igényel. Képzeld el, milyen lenne az autóvezetés, ha minden új utcába bekanyarodáskor kicsit bütykölni kellene a motoron, vagy le kellene cserélni a kerekeket. A böngészőfejlesztés sokban emlékeztet erre napjainkban.

Szinte minden modern böngésző rendekezik valamilyen oldal-hibamentesítő eljárással arra az esetre, ha meg kell kicsit olajozni web kiszámíthatatlan elemeinek kitett szabványok fogaskerekeit:

• az IE8 egy kompatibilitási lista alapján IE7 módban jelenít meg bizonyos oldalakat
• a Google Chrome álcázza magát a Hotmail-en
• a Safari homályos, dokumentálatlan trükköket alkalmaz
• a Firefoxnak úgy tűnik, csak a böngészőazonosító-váltó kiterjesztése van - de az eléggé népszerű
• az Opera álcázást és browser.js-t használ

Minden oldalt külön kezelni? Elég őrülten hangzik. Egyértelműen lehetetlen. Kezdőknek: több milliárd weboldal létezik és mind különböző. És változnak is, hiszen millió sornyi kódot adnak hozzá, és cserélnek le minden áldott nap. Hogyan lehet ezzel egyáltalán lépést tartani? Mellesleg nem a szabványoknak kellene a megoldást szolgáltatniuk?

Szabványok

Minden tiszteletem a The Web Standards Project-ben, vagy másutt dolgozó, szabványosítást hirdető evangélisták törekvéseié. Nélkülük sokkal-sokkal rosszabbul állnánk. A jövő talán éppen az ő oldalukon áll - egyre több oldal validálja és teszi szabványosabbá a kódját. Az erő legyen veletek!

Különböző operás csapatok szintén kiveszik a részüket a szabványosításból, akár oktatással, akár más módokon. Az Open The Web [kb. Nyisd meg a webet!] csoport tagjai felveszik a kapcsolatot a honlapok fejlesztőivel és tanácsokat adnak, hogyan tehetnék őket szabványosabbá és kompatibilissebbé.

De a böngésző a felhasználót képviseli. Tartozunk annyival a felhasználóknak, hogy mindent megteszünk az összes szabványokat, szabályokat felrúgó oldal megfelelő működéséért. Gyakran a hibás oldal nem a mi hibánk, de biztos, hogy a mi problémánk. És nekünk ma kell működésre bírnunk őket, nem 2022-ben...

Ezért nem tehetünk mást, javítunk.

Mivel a többi böngésző fejlesztő részéről különböző, jórészt alkalmi megközelítést tapasztaltunk a témában, itt az ideje, hogy megosszuk velük a tapasztalatainkat - mit tartunk a saját implementációnk erősségeinek és gyengéinek.

Erősségek

Tapasztalatok

Az Opera minden más gyártónál több tapasztalattal rendelkezik ezen a téren, hiszen már a 8.01-es verzió óta javítjuk a webet. Úgy hiszem a megoldásunk messze a legfejlettebb. A felhasználói JavaScript rendelkezésére álló speciális parancsok egy egyszerű, de hatékony API-t alkotnak az oldalak módosításához és javításához. A getter-ekkel, setter-ekkel és DOM interfészekkel az Opera viselkedését a leggyakoribb eltérésekhez igazíthatjuk. Néha hozzáadunk egy hiányzó stílust, vagy eltávolítunk néhány elemet és előírást, ami az utunkba áll. És amikor egy oldal böngésző-diszkriminációt alkalmaz (browser sniffing), gyakran képesek vagyunk az inkriminált kódsor javítására! Néhány véletlenszerű példa:

• amikor az AOL Japán diszkriminációt alkalmaz, és nem alkalmazza a megfelelő stílusokat, mi hozzá tudjuk adni azt az egy osztályt, ami hiányzik, és kijavítjuk az AOL Webmail helyesírás-ellenőrzőjének hibáját, amikor a dojoType-ot dojotype-nak betűzné
• egy elegáns postMessage() hívással elintézzük, amikor az E*Trade megpróbálja megsérteni a biztonsági előírásokat azzal, hogy más oldalak keretében akar navigálni, miközben az éppen titkosított tartalmat tölt be

Ezen túlmenően felülbírálhatjuk a böngészőazonosításra és renderelési módra (szabványos vagy hibatűrő) vonatkozó előírásokat a letölthető beállítások alapján.

Hibajavítások

Az Opera és az oldalak megváltoztatásának képességét kihasználva még a saját hibáinkat is ki tudjuk javítani.

• amikor a menü a weather.com oldalon eltűnik, mert az egér események rossz sorrendben következnek, mi át tudjuk rendezni őket
• amikor a Google Codesearch keresési eredményei fehér alapon fehérrel jelennének meg, mi új stílust adhatunk nekik

Egy rövid gondolat: Opera - a böngésző, ami képes a saját hibáit javítani, hogy ne neked kelljen? Ez olyan, mint egy időgép - kijavíthatjuk a múltbeli bűneinket egy már megjelent termékünkben.

Hosszútávon ez egy fontos és komoly hatása a user.js használatának: kevesebb Opera-specifikus hack miatt kell aggódni. Az IE8 frissítéssel kapcsolatos problémák és a mi tapasztalataink is azt mutatják, hogy a saját régebbi hibáink válnak később a legnagyobb problémáinkká. Hibát követünk el, a honlapok válaszul szintén hibát követnek el [a böngészőspecifikus javítással]. Mi megjavítjuk a mi oldalunkon, de a web sosem felejti el a korábbi hibáidat.

Milyen különbséget jelent a browser.js? Amikor kiadunk egy új verziót, tele hibajavítással, a hozzá tartozó browser.js fájlban lévő megfelelő javításokat egyszerűen elhagyjuk, mivel elavulttá válnak. Ami korábban csak módosításnak köszönhetően működött, azt az új verzió már alapból tudja. Ez a frissítést mind a felhasználó, mind a webfejlesztő számára jelentősen könnyebbé, és számunkra is egyszerűbbé teszi. Szinte érzem, ahogy az IE8 csapat irigykedik ránk az óceán túloldaláról.

Egy másik érdekes hatás, hogy különösebb aggodalom nélkül implementálhatunk új standardokat. Amikor a HTML5-ös input required [szükséges mező] funkció elrontotta a Barnes & Noble oldalát - elvégre a felhasználói név mező kitöltése nem feltétlenül szükséges, ha az új fiók létrehozása gombra kattintunk -, akkor a problémát ideiglenesen megoldhattuk a browser.js-el. Később aztán értesíthettük a szabvány fejlesztőjét a problémáról, és megbeszéltük, hogyan tehetné a specifikációt web kompatibilisebbé.

Átláthatóság

Kezdettől fogva az egyik legnagyobb aggodalmunk az volt, hogy a javításaink meggátolják a fejlesztőket a hibák megtalálásában és kijavításában. Még újabb hibákat is generálhatunk, ha a javításaink huzamosabb ideig megmaradnak, miközben az oldal megváltozik.

Hogy a dolgokat annyira átláthatóvá tegyük, amennyire csak lehetséges, a javításokat dokumentáljuk, igyekszünk a fájlt olvashatóvá tenni, és számos megjegyzést fűzni hozzá (ugyanakkor szeretnénk elkerülni, hogy áttekinthetetlenné váljon). Minden foltozás, amit az Opera végez az adott honlapon, megjelenik az Opera hibakonzolján is, hogy nyilvánvalóvá váljon a beavatkozás.

Fókusz

Az oldalak foltozása keresztplatform. És ez még enyhe kifejezés.Tudtad, hogy vannak javításaink Nintendo Wii-re? Meg a DSi-re? Windows Mobile-ra, Symbianra, BREW platformra és az Archos hordozható médialejátszóira? A fenébe is, még Opera Minihez is vannak javításaink!

• Amikor a Hotmail és a Yahoo mail rich text szerkesztési képességeket igényel a levelek írásához, mi átverjük őket még olyan készülékeken is, amik egyébként túl gyengék és erőtlenek lennének ehhez.
• a Facebook látványos animációi túl sokáig futnának az Opera Mini szerveren - elvégre időben el kell juttatnia a tartalmat a kliensnek -, mi rövidre zárjuk őket, és elvégezzük azokat a fontos műveleteket, amiket a honlap az animációk utánra tartogatott

Ez egy ambíciózus cél [mármint a keresztplatform működés], talán ambíciózusabb is, mint amilyennek kívülről látszik. Az eszközöknek és platformoknak nagyon különbözőek lehetnek a követelményei és a problémái. Néhány példa:

• A Wii-n fix minimális betűméretet használunk, hogy a szöveg olvasható maradjon - de ez gyakran okoz problémát a tartalomban a nem várt szélességek, tördelések és újrapozícionálások miatt, ami nem fordulna elő az asztali böngésző esetében. Jónéhány oldalt javítunk tehát, amelyek túl rugalmatlanok a némileg megnövelt betűméret használatához.
• A Wii és más telefonok esetében automatikusan megjelenik a virtuális billentyűzet, ha egy szövegmezőbe szeretnénk gépelni, ami együtt jár az oldal átméretezével. Ha például a British Airways honlapja minden ilyen alkalommal újratölti a jegyrendelő oldalát, akkor a jegyvásárlás igencsak nehézzé válik...
• a francia eBay oldala a regisztráció során megpróbálja megszámlálni a leütések számát, hogy megbizonyosodhasson arról, hogy nem csalsz, és - gépelés helyett - nem csak egyszerűen bemásolod az e-mail címedet az "erősítse meg az e-mail címét" mezőbe. Ez viszont megint csak nem fog működni virtuális billentyűzetekkel, egyesek egyáltalán nem is támogatják a billentyűzet-eseményeket. Gyerünk, eBay, én tényleg begépeltem. Úgy értem, TÉNYLEG! Egy olyan hardveren, ahol a másolás-beillesztés nem is elérhető...

Amikor az ember a problémák ilyen széles körével kénytelen szembesülni, akkor válik nyilvánvalóvá a browser.js fájl igazi és varázslatos potenciálja.

Infrastruktúra

Hogy mindezeket megvalósíthassuk, szükségünk van egy remek szerverparkra, ami minden bejelentkező kliensnek a megfelelő fájlt küldi el. A javításokat egy adatbázisban tároljuk, olyan információkkal együtt, hogy például az adott fájl milyen verziójú és melyik eszközökre vonatkozik. De tudtad, hogy vannak olyan szkriptjeink is, amik azt ellenőrzik, hogy egy hiba fennáll-e még az adott oldalon? Ha egy kijavított oldalon megváltoztatnak valami idevágó részt, arról tudni szeretnék. Szeretem a virtuális "elavult" mappába kerülő javítások hangját.

Megkötések

Idő

Annyi lehetőség, és olyan kevés idő... Az oldalak elemzése és a javítások elkészítése rengeteg időt igényel. Sehol sem vagyunk az IE8 2400 elemből álló, hatalmas listájától. (Tulajdonképpen a lista böngészése egyfajta deja vu érzést okoz. Rengeteg ismerős név, olyan oldalak, amik készítőivel korábban fel kellett vennünk a kapcsolatot, vagy amikhez javítást kellett kiadni.)

Teljesítmény

Az imént említettem, hogy még rengeteg helyünk van a további javítások számára. De meddig mehetünk el anélkül, hogy a sebesség látná kárát?

Úgy tűnik, még egy darabig ezzel nem lesz gond. Az általunk végzett tesztek azt mutatták, hogy akár 10 ezer specifikus oldalig is elmehetünk anélkül, hogy az Opera sebessége néhány százalékpontnál nagyobb mértékben romoljon.Őszintén szólva mire eddig eljutunk, valószínűleg már a jelenleginél sokkal erősebb gépet használsz majd...

Biztonság

Ez biztonságos megoldás? Nem tudja egy vírus, vagy ártó szándéú szerver meghamisítani a browser.js fájt, és hozzáférést szerezni a böngészésemhez?

A rövid válasz: nem.

A hosszabb válasz, hog ez elképzelhető lenne, ha nem tennénk megfelelő biztonsági óvintézkedéseket, ed ezekre nagyon ügyelünk. Minden fájlt aláírunk, így az Opera le tudja ellenőrizni azok eredetiségét, és hogy nem módosították-e. Egy ilyen aláírást nagyon nagyon nehéz meghamisítani. Ha egy rosszindulatú támadó módosítja a fájlt, az Opera nem fogja azt többé használni, hanem megpróbál egy frissebb verziót letölteni az Opera szervereiről.

Összefoglalás

A browser.js-el kapcsolatban az lepett meg leginkább, hogy milyen gyorsan változik a web. Amikor ilyen komoly figyelmet szentelünk konkrét oldalaknak, láthatjuk, ahgy a web egésze fejlődik, és sokkal gyorsabban, mint ahogy azt én valaha is képzelni mertem volna. És ellentétben azzal, amit esetleg gondolsz, igenis azt látjuk, hogy egyes oldalak Opera-barátabbak lettek azután, hogy javítottuk őket!

Ez azt jelenti, hogy az oldalak foltozása működik. Működik, mert növeli a kompatibilitást, ami megadja a felhaszálóknak szabad böngészőválasztás lehetőségét, és - bármilyen furcsán hangzik is - ennek egyenes következményeként arra ösztönzi az oldalak üzemeltetőit, hogy biztosítsák oldaluk Opera és keresztplatform kompatibilitását.

Üdvözöllek a jövőben - a szabványok, a nyitottság és az oldalfoltozás világában.