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)

Itt az idő, hogy búcsút vegyünk a Presto motortól.

A mai napon az Opera Software bejelentette, hogy az Opera felhasználóinak létszáma elérte a 300 milliót. Ezzel egy időben egy már korábban sejthető lépést is hivatalossá tettek, miszerint az Opera hamarosan Presto-ról Webkitre vált.

Ezzel a lépéssel az Opera lesz az első nagyobb böngésző, amely teljesen lecseréli a böngészőmotort. (Elvileg Az internet-szerte fellelhető spekulációk szerint a Mozilla is tervezi, hogy a Firefox átáll Webkitre).

A Presto egy nagyszerű motor. Kicsi, gyors, rugalmas és szabványkövető, miközben képes kezelni a való-világban létező (sokszor koránt sem szabványkövető) weboldalakat. Ez tette lehetővé, hogy az Operát bármilyen eszközre portolják a fejlesztők. És - ellentétben a userek véleményével és tapasztalataival - a Presto-t a kezdetektől fogva a kompatibilitást szem előtt tartva tervezték. Mindig is az volt a cél, hogy kompatibilis legyen a valós-webbel, miközben a szabványokat szem előtt tartja. Ez pedig nem kis kihívást jelentett, mivel a web egy kaotikus aknamező, ha szabványkövetésről van szó. Ez a véget nem érő munka (mivel a többi böngésző szerencsés módon a piaci részesedésnek köszönhetően jól jelenítette meg az oldalakat) pedig hatalmas erőforrásokat emésztett fel. Erőforrásokat, melyeket bugok javítására, új fícsörök implementálására és innovációkra fordíthattak volna.

Ez a helyes út

Habár első hallásra még Haavard is szkeptikus volt a döntéssel kapcsolatban, de a felmondási nyilatkozat láttán mostanra már teljesen bizonyos benne, hogy ez a helyes döntés. Nem csak, hogy rengeteg, jobb célokra fordítható erőforrást szabadít fel, de a felhasználók is nagyságrendekkel jobb oldalkompatibilitást kapnak.

Ezzel sokkal jobban ráfeküdhetnek a felhasználói élményre.

Hozzájárulás a monokultúrás (egy motor mind felett) webhez?

Igen, a monokultúra rossz, de az Opera soha nem volt abban a pozícióban, hogy ezt az első helyen megakadályozza. Hiába domináns tényező mobilfronton és rendelkezik 300 millió felhasználóval, a webfejlesztők továbbra is Webkitre optimalizálnak.

Ha a Webkitre váltás felgyorsítja az Opera fejlődését és meghatározó hozzájárulói lesznek a projektnek (már beküldték az első patch-et a következő bugra), akkor végre ők is közvetlen hatással lehetnek a web fejlődésére (akárcsak az Apple, Google és újabban Microsoft, aki saját maga gyártja a szabványokat, immáron szabványosított keretek között).

A web versenyben áll zárt megoldásokkal

Lényeges szem előtt tartani, hogy miközben a böngészők versenyben állnak egymással, addig a web szintén versenyben áll a natív alkalmazásokkal. A web talán nem teljesen nyílt, de így is sokkal nyíltabb, mint az "alkalmazások" zárt világa. A Webkitre váltás lehetővé teszi, hogy az Opera növelje az erejét és megerősítse a böngészőt, mint nyílt alkalmazás platformot, amely félig nyílt webet kínál a zárt alkalmazások helyett.

Elengedhetetlen, hogy a web ne csak túléljen, hanem folytassa a növekedést, fejlődést. Nem hagyhatjuk a zárt, szerzői jogvédett megoldásokat nyerni. (Egy Petőfi veszett el ebben a srácban - a szerk.)

A helyes lépés a megfelelő időben

Az Opera Webkitre váltása talán újdonság és meglepő egyesek számára, mások már sejthették, mivel nem ez az első alkalom, hogy a cég új irányt vesz hirtelen.

A Webkit ma már elég kiforrott ahhoz, hogy lehetővé tegye a váltást és az Opera is besegíthet a fejlesztésbe a nyílt forráskódnak köszönhetően, cserébe pedig nem kell folyamatosan csiszolni a böngészőt az állandóan változó webhez. Ez pedig lehetővé teszi, hogy felkészítsék a platformot a jövőbeli növekedésre az erőforrások felszabadulása által, amely eddig visszafogta az Operát és segíthet a webet a helyes irányba terelni.

További információ az ODIN blogról, hogy a Carakan-t is lecserélik V8-ra. Arra is utalnak, hogy a böngésző sokkal több, mint motor, ezért ezt egyfajta "motorháztető alatti" változásnak kell felfogni. (Remélem a fícsörök megmaradására céloznak, nem valami norvég humor arra vonatkozóan, mikor a Porsche-be tesznek Trabant motort - a szerk.) Az váltás első terméke mobil-fronton érkezik (Opera Ice), melyet Barcelonában mutatnak majd be a Mobile World Congress rendezvényen a hónap végén. A desktop változat átalakulása később történik meg.

TL;DR

• Ez nem fogja megváltoztatni a webfejlesztési praktikáidat, amennyiben webfejlesztő vagy: a szabványok alapján kódolj!
• Az Opera kiegészítők nem lesznek elavultak (ez érdekes lesz, de ha ők mondják... - a szerk.)
• Az Opera hozzájárul a Webkit és Chromium projektek fejlesztéséhez
• Továbbra is szabványkövetőek maradnak

Mit jelent ez a webfejlesztők számára?

A rövid válasz az, hogy semmit, továbbra is szabványosan kódolj. De néhány dolgot nem árt figyelembe venni.

• A Chromium és így az Opera jövőbeli verziói a következő beépített codec-ekkel rendelkeznek majd: WebM, Ogg Theora és Ogg Vorbis, de nem támogatják natívan sem az MP3-at, sem a H.264-et (habár ha az oprendszered rendelkezik ezekkel a codec-ekkel, tudod kezelni böngészőből ezeket a médiákat). A megfelelő módon ellenőrizd a támogatást: HTML5 canPlayType. A legegyszerűbb módja, hogy megbizonyosodj minden modern böngészőben, rendelkezik-e az adott codec-kel, hogy kezelje akár a WebM, akár a H.264-es tartalmakat a <source> elements vagy használd a canPlayType -ot, hogy ellenőrizd a támogatást (lásd itt: Bevezetés a HTML5 videó rejtelmeibe további információkért).
• A window.opera értelemszerűen megszűnik az Opera következő verzióiban. Továbbra is ajánlják a fejlesztőknek, hogy NE HASZNÁLJANAK browser-sniffing-et. Helyette vagy feature-detection-t - vagy valami 3rd party megoldást, mint a Modernizr vagy hand-rolling, mert az sokkal jobb.

Mit jelent ez a kiegészítő fejlesztők számára?

A kiegészítők a legsikeresebb Opera "kiegészítők" ezért a legfontosabb az Opera számára is, hogy a már létező kiegészítők működjenek. Egy konvertáló eszközön dolgoznak, ami a létező OEX kiegészítőket a Chromium-alapú Opera által használt változatra konvertálja. Ezen felül dokumentációkat és how-to-kat is biztosítanak majd és a dev.opera.com fórumán is segítenek. Továbbra is elkötelezettek a fejlesztői közösség és a userek iránt, ezért mindent megtesznek, hogy az átmenet olyan simán menjen, amennyire csak lehetséges.

Mi a váltás oka?

A kezdetekkor, 1995-ben ki kellett hozni egy új motort, hogy versenybe szálljanak a Netscape-pel és az Internet Explorerrel, hogy webes szabványokat alkossanak és terjesszenek. Mikor a "HTML5"-nek hívott specifikációt elkezdték implementálni a cél az volt, hogy egyfajta platform (azaz böngésző) független webet alkossanak, avagy minden böngészőben egyformán (jól) jelenjen meg minden oldal.

A WebKit projekt szabványkövető, amely az Opera egyetlen álma volt a kezdetekkor. Ahelyett, hogy feleslegesen duplikálnák a Webkitben már létező szabványokat, az innoviciókra koncentrálhatnak, mellyel jobbá teszik a böngészőt. Olyan innovációk, mint a füles böngészés, gyorshívó vagy az Opera Turbo

18 év tapasztalatával továbbra is aktív részesei lesznek a szabványosítási folyamatnak. Lásd: HTML5, native video and Media Queries egészséges részei a modern webnek.

Ezen felül hozzájárulnak a WebKit és a Chromium projektek fejlesztéséhez. A belső összeállítások, melyet már tesztelt a QA és talán az Elektrans csapat is (Karbonade?), további szabványokat támogat és továbbfejlesztettek néhány fícsört is, ami hiányzott a Presto-hoz képest (például, multi-column layout).

Az elmúlt néhány hétben megegyeztek, leszerződtek a Webkit projekttel, és az azt aktívan fejlesztő szervezetekkel, hogy megvitassák a szándékaikat és hogy mivel tehetnék a WebKitet még jobbá. Azzal, hogy egy patch-et nyújtottak a Webkit számára, nem csak az Operát, de az összes Webkit-et használó böngészőt tették jobbá.

Megjegyzés: A Dragonfly is megy a levesbe.

Hosszabb várakozás után a mai napon újabb előzetes érkezett, az Opera 12.10.1592. Nem, nem én írtam el, tényleg 12.10. Az Operások ugyanis a 11.6 útját követik. Az is egyfajta köztes verzió volt az addig bemutatott és kellően stabil újdonságokkal, amíg a fő attrakciónak szánt 12 meg nem érkezik. Aztán azt is elkapkodták és hivatalosan most sincsen még HWA...

Most pedig úgy néz ki, hiába vártunk az Opera 12.5-re, előbb a 12.10 érkezik. Vélhetően hamarabb, mint gondolnánk (lehetséges?), mert szerintük ez már a béta RC! A saját tapasztalataim, és a Desktop Team-es hozzászólások alapján viszont nem az. Egy béta ugyanis egy nem teljes funkcionalitású, helyenként bugos kiadás. De stabil! Ez a build pedig nem az.

Ettől függetlenül próbálkoznak derekasan, a Presto például már 2.12.388-nél jár, ami még nincs is rendesen dokumentálva. Ezen kívül javítottak pár fagyást (mint már említettem, születtek újak), befoltoztak 1-2 lyukat a memóriakezelés kapcsán és jónéhány hibát orvosoltak, köztük NSL-el kapcsolatosakat.

Ezen felül jobb lett a szabványtámogatás (jelentős újításokról nincs információ), a Retina kijelzős Mac felhasználók is örülhetnek... Ami viszont már sokakat érint, az a friss libvpx dekóder (aka. "Eider") - a WebM videók esetén jelentős teljesítményjavulásra számíthatunk. Frissült a libwebp is (0.2-re). Az SPDY protokoll már a Turbóval is működik.

Ami még érkezett: pár grafikai csinosítás (frissített, nagy felbontású ikonok) és jobb platformtámogatás, főleg Mac-hez. A teljes lista a Desktop Team bejegyzésben olvasható. Az ismert hibák alapvetően arról szólnak, hogy a 12.5 > 12.1 váltás megviselheti a frissítő algoritmusokat, például a Linux felhasználóknál.

Letöltés (Opera 12.10.1592):

A végleges Opera 12.02 már ma megjelent, a 12.5 alias Marlin viszont még csak a távoli(?) jövő zenéje. Ebben a fejlesztési szakaszban pedig jellemző (legalábbis mostanában, hisz' nem volt ez mindig így), hogy a szorgos javítgatások mellett időről-időre komolyabb újdonság kap helyet a böngésző lelkét jelentő Presto renderelő motorban.

Érdekes módon a legutóbbi nagy javítás szinte egybeesett a 12.01 érkezésével, két nappal később jött, most viszont ugyanennyivel előzi a 12.02-t. Az, hogy az ezekről szóló cikkek nálunk pontosan egybeesnek inkább a mi hibánk...

De vissza a 12.50.1577 újdonságaihoz, mert akad belőlük jócskán. Illetve esetenként az az új, hogy bekerültek a fősodorba, hiszen a teljes képernyős (Fullscreen) API, vagy az SPDY protokoll támogatás nem új azoknak, akik  bő másfél hónapja már olvasták a Labs kiadásról szóló cikkünket. Ezek tehát helyet kapnak majd a 12.5-ben, ha nem is pont ebben a formában. A Fullscreen API ugyanis még a februári szabványvázlatot tükrözi, de az Operánál már dolgoznak a frissebb, júliusi állapot kódba öntésén. Hiába, ezek még nem kiforrott technikák.

Ami viszont az és már régóta hiányolható a böngészőből, az a színprofilok támogatása. Arról van szó, hogy bizonyos képtípusokban lehetőség van a kép adatain túl extra információk elhelyezésére, például a színtér definiálására, amiknek inkább professzionális felhasználásnál lehet jelentősége. Viszont bizonyos webhelyeken már használatosak egy ideje és a különbség igen látványos lehet.

Vegyük például a lenti képet a kissé lökött Opera alkalmazott Bruce-ról, aki - bár a kép alapján ki nem találnánk - meglehetősen otthon van a HTML5 területén, olyannyira, hogy könyvet is írt róla. Ha a böngésződben a felső képen is inkább navii-nak látszik, mintsem embernek (azaz kék a bőre), akkor nem támogatott a színprofilok használata. Mint a 12.50.1577 előtt egyik Operában sem.

Bonyolítja a dolgot, hogy alapvetően két fő verzió létezik, a v2 és a v4 (a legfrissebb egészen pontosan a v4.3). Egyes böngészők - például a Chrome - csak az előbbit támogatják, mások - például az IE9 és most már végre az Opera is! - az utóbbit is. Az ICC honlapján lévő tesztkép alapján erről mi is meggyőződhetünk. Ha a kép teljesen normális, böngészőnk a v4-et támogatja. Ha két negyed is furcsa színű, akkor v2-ről van szó, ha pedig mind a négy rész torz, akkor még nem frissítettük az Operánkat a legfrissebb előzetesre.

A dolog gyakorlati hasznát talán jobban le lehet mérni más példákkal. A megadott oldalon számos képet látunk, alattuk linkekkel. A felső sorbeli gombokra  állva megnézhetjük, hogy az egyes színterek milyen különbséget jelentenek. Az alsó soron végigmenve ugyanezeket láthatjuk, de már beágyazott színprofillal, aminek segítségével a böngésző - elvileg - ugyanazt az eredményt adja minden esetben, változást tehát nem tapasztalunk.

Ha már kiörvendeztük magunkat, lépjünk is túl ezen, hiszen van még más is. Nem is olyan régen az Operánál úgy döntöttek - jól vagy rosszul ezt most ne feszegessük - hogy mások mellett süllyesztőbe teszik a Unite-ot és a minialkalmazásokat, hogy jobban a kiegészítőkre fókuszálhassanak. Amikre rá is fér a támogatás, hiszen még a Chrome-os megfelelőikben is több a potenciál, nemhogy a firefoxos változatban.

Persze csak lépésről-lépésre haladnak, most például a környezeti menü (Context Menu) API került bele, aminek segítségével a fejlesztők képesek elemeket hozzáadatni az Opera környezeti menüihez. Az erre fogékonyak itt olvashatják az API dokumentációját.

Ezen felül jutott még a jövevénybe fordított lista (HTML5-ös reversed ol), valamint beágyazott @media támogatás, ezekről bővebben az ODIN blogon lehet olvasni. De hozzányúltak a billentyűzet kezeléshez is, amit főleg a Mac tulajdonosok fognak értékelni. A többieknek marad a lehetőség, hogy billentyűzettel jelöljenek ki szöveget.

Mindezen túl érkezett még egy raklapnyi javítás és apró optimalizáció a WebGL-hez, a Dragonfly-hoz, a hálózat kezeléshez és úgy általában az Operához. Egy jópofa újítás a ráncfelvarrott opera:cpu, ami már négyzet alakú narancssárga jelölőket használ, de ami sokkal fontosabb: a fülek listájában szereplő kis vissza-nyílra kattintva, alul windows feladatkezelős stílusú grafikonban tájékoztat az adott oldal időbeli processzor-éhségéről, ami további segítséget jelent a gépet "megfogó" renitens oldalak felkutatásában és elliminálásában.

A sok jó mellé pár bug is jutott: a Gyorshívó bejegyzései automatikus frissítés után kiüresedhetnek, illetve - és ez a durvább - Linux/Unix alatt minden beépülő fagy...

Ha még mindig érdekel, a teljes változási közleményt megtalálod a Desktop Team bejegyzésében.

Letöltés (Opera 12.50.1577):

Mindig örömteli, ha hosszas hallgatás után a Desktop Team blogon új verzió jelenik meg. Hát még ha olyan hosszú a lista, mint a most pénteki kiadásé. Mindezt annak dacára, hogy éppen a nyári szabadságolási szezonban vagyunk.

A legtöbb változás az oldalak összeállítását és megjelenését végző Presto renderelő motort érintette: immár a 2.12.363 változatnál járunk. Ez persze sok belső változással jár, a teljes listát elolvashatjátok a blogon (tényleg hosszú), én itt most csak a legfontosabbakat emelném ki.

Ismert hibák:

• a címsorbeli csillag ikonra kattintás lefagyasztja az Operát
• hibás text-shadow Windows alatt
• billentyűzet-eseménykezeléssel kapcsolatps problémák Mac alatt
• Google+nem szereti az új UA karakterláncot

Főbb változások:

• teljesítményfokozó optimalizációk (VEGA, CSS3 animációk, magas CPU használat... stb.)
• új, rfc6455 kompatibilis WebSocket implementáció (mostantól alapból engedélyezve!)
• Unicode 6.1.0 implementáció
• URL szűrő API fejlesztések (fehérlista!)
• Screenshot API
• Resource Loader API
• Page Visibility API
• rövidített User Agent azonosító (jelenleg Google+ problémákat okoz)
• már nincsenek támogatva az -o- előtagú CSS utasítások (Transitions, Animations és Transform esetén)
• a találatok javított láthatósága a forráskód-megjelenítőben
• számos renderelési és oldalkompatibilitási hiba javítva
• Voice XML, CSS Speech támogatás eltávolítva
• Pretty-print és más javítások a Dragonfly-hoz