Megjegyzés: A most következő írásban Jake Archibald Chromium fejlesztő Google Plus-on írt postjának fordítását olvashatjátok.

Még elég új vagyok ebben a Google-dologban, tehát kihangsúlyoznám, a most következő írás a saját, személyes véleményem webfejlesztőként.

Az Opera dobta a Presto motorját a Chromium kedvéért, amely WebKit Blink + V8 + további kódokat jelent. Eléggé vegyesek az érzéseim ezzel kapcsolatban.

Nagy rajongója vagyok a Chromiumnak, a motorok legjobb kombinációjának tartom, kifejezetten teljesítmény tekintetében. Az IE is elég nagy léptekkel halad ebbe az irányba, de ők csak egyetlen OS-t támogatnak és ezt az OS-t is ők maguk fejlesztik. A Chromium több platformon jobban teljesít. Mint Chromium rajongó, felvillanyozott a hír, hogy az Opera is csatlakozik.

Megkockáztatva, hogy a munkáltatóm nem fog örülni, én mindig úgy éreztem, hogy az Opera jobban "megfogta" a webet, mint a többi böngészőgyártó. Ők "weboldalakként" látták az internetet, nem pedig "alkalmazásboltoknak". Még a saját "Woo yey! Új technológia!" típusú cikkeikben is volt egy egészséges adag "Óvatosan! Progresszív javítás! Hozzáférhetőség!" Nagyon örülök, hogy ezek az emberek részt vesznek a Chromium projektben.

Mint egy Opera rajongó, egy kicsit kibelezve érzem magam. Nagyszerű emberek vesztették el az állásukat. De aggódom amiatt is, hogy elvesztettünk egy egyedülállóan felépített motort, amely több szempontból innovatív volt.

Az Opera volt az első böngésző, amit az IE6 után használtam. Ez volt az egyetlen böngésző, amelyért még fizettem is (kivéve azt, amelyért az OS megváráslásával fizettem). Imádtam a füleket, imádtam a mozdulatparancsokat. Imádtam az egész felhasználói felületet.

A TV-men ha valamit nézni akartam iPlayer-en, az ő böngészőjüket használtam a Wii-n, inkább, mint a PS3 böngészőjét, annak ellenére, hogy a Wii-nek alacsonyabb felbontása volt és analóg módon csatlakozott a TV-mhez. A PS3 böngészője szörnyű volt, valami Netfront "clusterfuck", amire azt mondtam, nagyon hasonlít az IE4-re (egy Sony fejlesztő mondta nekem ezt, de soha nem hallottam ilyet korábban, de sok IE-specifikus DOM API-juk volt, amit egyetlen másik motorban sem láttam még). A PS3 böngészője most egy sokkal egészségesebb WebKit származék, mint az összes Netfront böngésző, de a felhasználói felület még mindig elmarad az Operához képest. Szégyen, hogy az Opera miért nem csinált DS-re böngészőt.

Az Opera még mindig innovatív a támogatott eszközökben és a felhasználói felületben, de mi van a motorral, a Prestoval?

Félig szarkasztikusan mondom, de a Presto tele van meglepetésekkel. 2009-ben egy megbeszélésen voltam a JavaScript teljesítménnyel kapcsolatban és felfedeztem, hogy az Operában a lapok továbbra is válaszképesek maradnak (görgetés, szövegkijelölés), miközben a JavaScript beragad egy végtelen ciklusba. Egyik másik böngésző sem képes erre, a JavaScript blokkolja az UI thread-et. Úgy hiszem, hogy a JavaScript ugyanabban a thread-ben fut Operában, mint amiben az UI, de fel van darabolva valamilyen módon, amely lehetővé teszi, hogy visszatérjen az UI feldolgozáshoz folyamatosan. Úgy hiszem, hogy a kezdeti Web Workers implementációjuk nem is volt több, mint füst és tükrök, mivel nekik már megvolt ekkor a nem-blokkoló viselkedésük. 2013-ban már Chrome-ban is képes vagy görgetni az oldalt, miközben a JavaScript blokkolja az UI thread-et, habár mi ezt többszálú-módon oldottuk meg.

Én Chrome-ban fejlesztek, majd ellenőrzöm az oldalt Safariban és Firefoxban. Rendszerint ez fájldalommentes, minden a várt módon működik (általában). IE-ben és Operában gyakran kevésbé mókás a validálás. De itt a különbség, a dolgok azért rosszak IE-ben, mert bugos, miközben a dolgok azért rosszak Operában, mert szigorúan ragaszkodik a specifikációkhoz (általánosságban mondom, természetesen). Mikor Operában bugosak voltak az appcache FALLBACK bejegyzések én órákat töltöttem a specifikációk böngészésével azzal a feltételezéssel, hogy az Opera csinálja jól és a többiek rosszul. Ebben az esetben tévedtem, az Operában volt egy bug, de ha bármelyik másik böngésző másképp viselkedik, azonnal azt feltételezem, hogy az a böngésző csinál valamit rosszul.

Az Opera szövegrenderelésével kapcsolatban is volt néhány kellemes meglepetésem. Ha beágyazol egy webfontot normál weight-tel, de CSS-vel bold-ban rendereled, akkor néhány böngésző megpróbálja álcázni a vastagbetűs effektet a webfonton. Ez borzalmasan néz ki minden böngészőben, kivéve az Operában, amely gyanúsan pontos a legtöbb betűtípus esetében. Valószínűleg nem azért használsz egy böngészőt, hogy betűtípusokat csinosíts, de jó látni, hogy az Opera itt is jól végzi a dolgát.

Természetesen nem minden Presto meglepetés örömteli és a jelenlegi böngészőfejlesztési sebesség mellett több a csúnya meglepetés, mint a kellemes.

Ha nem lenne egy buta 50 fontos fogadásom a párommal, hogy nem iszom egy hétig, most poharat emelnék a Presto-ra. Nagyon remélem, hogy az Opera fejlesztői és támogatói ugyanezt az innovatív hozzáállást teszik hozzá a Chromium projekthez.

(forrás)

A következő postban már jó ideje gyűjtögetem azon oldalak címeit, ahol nem csak száraz szintetikus tesztek vannak, hanem valódi aktív tartalom. Ezeken az oldalakon ki lehet próbálni a HTML5, JavaScript és Canvas sokrétűségét.

Az egyik legismertebb ilyen oldal, amely Operával is működik, ellentétben az Apple hasonló oldalával a Chrome Experiments oldala.

Van még néhány hasonló gyűjtő oldal, az egyik a Canvas Demos ahol mindenféle Canvasban és JavaScriptben írt játékok vannak a memóriától a Super Mario-ig és a HTML5Games.com.

Ezen az oldalon például egy 3D-s, 360 fokban forgatható mobiltelefon van. Természetesen HTML-ben, ehhez sem szükséges semmilyen beépülő.

Itt a renderelési sebességet lehet tesztelni.

Itt egy Tetris játék van HTML alapokon, de régi, klasszikus FPS játékaink sem maradhattak ki a sorból. Bár ezek az FPS-ek még nem teljes játékok, de készült már Wolfenstein és Doom is JavaScript+Canvas-ban.

A következő oldal már kicsit jövőbe mutató, ahol valós időben konvertálhatjuk a HTML5 videót ASCII kóddá.

Amint a fenti példák is mutatják, ötletben nincs hiány, már csak az erőforrásigényt kell még a jelenleginél is lejjebb dolgozni és végre búcsút mondhatunk a zárt és harmadik féltől származó megoldásoknak és az ehhez szorosan kapcsolódó biztonsági réseknek, instabilitásnak és memóriaszivárgásoknak.

Mondhatnám, hogy az Opera 10.50-es verziójával aktuálissá vált, de valójában 2008-ban, a Chrome megjelenésekor vált aktuálissá a weblapok címének kérdése. Vagyis a címsorba helyezett fülekkel eltűnt a Windows címsor, ahol addig az oldalak címe volt látható teljes szélességében.

A régi elrendezés még a faviconok nélküli időszakra vezethető vissza és igazából már a füles böngészés megjelenésekor kényelmetlenné vált azok számára, akik egyszerre sok lapot tartanak nyitva, ennek ellenére sok helyen még a mai napig ezt a struktúrát használják.

Az ExtendOperán egy ideje van egy tab-aliaser nevű userJS, amellyel 3 különböző módon alakíthatjuk át a weboldalak címét, avagy a TITLE részt. Az első konkrét domain, illetve aldomain esetén egy általunk meghatározott Aliast ad az oldalnak. Tehát például ennek a postnak a címét írhatjuk át vele anélkül, hogy a Magyar Opera blog főoldalát is átírnánk.

A második 2nd domain alapján alakítja át, vagyis a példában szereplő, idézőjelek között lévő "google.c" a google.com a google.ca és a google.co.akármi domainek esetén is átalakítja a TITLE mezőt az általunk "alias2"-ben megadott szövegre.

Nemrég adtunk hírt arról, hogy az Opera egy ingyenes cikksorozatot készített, amely felöleli a webfejlesztés szinte minden részletét, ráadásul olvasmányos és rendkívül hasznos formában. Már akkor eldöntöttem, hogy ebben segítenem kell nekik, úgyhogy neki is álltam a fordításnak. Mivel a téma már eléggé túlmutat ennek a blognak a keretein, így indítottam egy másik blogot (Webes szabványok), ahová a fordításokat fogom tenni. Persze a CC lincenc értelmében ezeket bárhová át lehet majd másolni, úgyhogy semmi akadálya, hogy más oldalakra vagy gyűjteményekbe is átkerüljön (persze forrásmegjelöléssel).

Ha csatlakozni szeretnél a fordításhoz, küld egy emailt (kattints fent a nevemre), és felveszlek téged is szerkesztőnek. Válassz magadnak egy szimpatikus cikket az Opera oldaláról, és már fordíthatsz is. Publikálás előtt még átolvasom, és megpróbálom majd közös nyelvezetre hozni a cikkeket, úgyhogy nem az sem gond, ha nem tökéletes mindenütt a fordításod (az enyém sem az). Egyébként reményeim szerint heti egy-két új fordításra számíthattok az új oldalon.

Ha hibát, elírást találsz a jelenlegi fordításokban, cikkekben, azt kérlek itt jelezd!

Akár már el is kezdheted az olvasást: Webes szabványok

Az Opera pár napja jelentette meg a minialkalmazásokhoz a fejlesztői csomag első beta verzióját, vagyis az Opera Widgets SDK-t. Az SDK segítségével még egyszerűbben lehet ezentúl operás minialkalmazásokat készíteni, nem csak az asztali verzióra, hanem az Opera Mobile-ra és a Wii-re is.

A fejlesztői csomag jelenleg többek között a következőket tartalmazza:

• Dokumentáció

  Több új dokumentáció került bele a csomagba a minialkalmazások fejlesztésével kapcsolatban, mint például a legújabb specifikáció, DOM referencia, különböző platformok támogatása, Ajax támogatás, kapcsolat több kiszolgálóval, beállítások kezelése, biztonsági modell.

• Eszközök

  Az új Widget emulator segítségével könnyen kipróbálható, hogy a minialkalmazás hogyan jelenik majd meg a különböző eszközökön. Az Opera Dragonfly pedig használható hibakeresésre, még akkor is, amikor a minialkalmazás éppen az emulátorban fut.

• Library-k

  A Dev.Opera Library részében több olyan függvénycsomag található, amely jelentősen megkönnyítheti a minialkalmazások fejlesztését rengeteg előre megvalósított megoldással. Többek között az alábbi témákban található segítség: animációk, kódolások kezelése, naptár és események kezelése, számláló, adatok beolvasása, fájlműveletek, grafika, súgó használata, tooltip kezelés.