Magyar Opera

Címkék » webkit


Itt a végleges Opera Mobile 14

Opera Mobile 14 logo.pngAz Opera a mai napon hivatalosan is elérhetővé tette az Opera Mobile 13-as 14-es verzióját, legalábbis az Android rendszerű készülékekre. Akik eddig is figyelemmel követték a mobil böngésző történetét, azok tudhatják, hogy az áthúzott verziószám nem véletlen. A korábbi 12-es után ugyanis most a 13-asnak kellett volna következnie.

Hogy ez mégsem így alakult annak alapvetően két oka van. Az egyik egyszerű számmisztika: a 13-as számnak ugyanis baljós jelentést tuladjdonítanak, nem utolsósorban a fő piacnak számító Egyesült Államokban.

A másik ok inkább praktikus: az Opera Mobile 14 ugyanis a cég történetének első terméke, ami elhagyja az Opera által fejlesztett böngészőmotort (ami az utóbbi években az Presto nevet viselte) és lecserélte azt az nyílt forrású, valamilyen formában a rivális Safari (iOS) és Chrome (Android) által is hasznlt WebKit-re. Ennek megerősítésére még némi kutakodás szükséges, mindenesetre aligha a most a hírekben szereplő Blink háttérre épül a mostani a verzió. Talán majd a 15-ös...

A mostani változatot már tesztelhetjük egy ideje, hiszen Opera Mobile béta néven jó ideje elérhető. A mai hivatalos kiadással annyi változott, hogy immár a korábbi presto-s Operánk helyére települne fel, frissítés gyanánt. Szóval csak óvatosan!

Terveim szerint egy nagyobb tesztet is írok majd ennek tiszteletére, ehhez azonban idő kell, így ez a bejegyzés csak amolyan kötelező hír volt, ennek megfelelő terjedelemben.

Az új Opera Mobile-t letölthetitek a telefonotok segítségével a Google Play piacteréről.  

Blink: A Google új WebKit forkja

Ma bejelentette Haavard Twitteren, hogy a Google szintén nem rég bejelentett új motorját, a Blinket fogja az Opera is használni.

Google BorgKezdjük a legelején. A Google tegnap bejelentette a fejlesztői blogján, hogy kinőtték a WebKitet és a multiprocessz architektúrájuk miatt szükségük van egy új motorra, ezért forkolják a WebKitet. Így 1365084604_rectangle_google_plus_one_+1_grey.png motorral megmarad az egyensúly, a webdiverzitás, ahogy Bruce Lawson fogalmazott, aki szintén bejelentette a blogján. És a személyes véleménye, - amit nemhogy az Opera Software, de még a hörcsöge sem befolyásol - alapján is jó döntés és ígéretesnek tartja az új motort. De az is lehet, hogy csak túl sok rumot töltött reggel a kávéjába. A Google ígéretei szerint az új motor minden eddiginél stabilabb, gyorsabb, jobb és bugmentesebb lesz, valamint a globális felmelegedést is csökkenteni fogja. De maradjunk a tényeknél. Amit tudunk, hogy a kód mérete drasztikusan le fog csökkenni (tehát előfordulhat, hogy az új telepítő már nem lesz 30+ mega) és emiatt átláthatóbb lesz.

  • 7 build rendszert eltávolítanak
  • Több, mint 7000 fájlt törölnek
  • 4 és fél millió kódsort törölnek

Az új motor természetesen továbbra is BSD licences nyílt forráskódú marad és továbbra is támogatni fogja a háziszabványokat és a WebKit-es vendor prefixekkel is kompatibilis lesz (amit a kezdetekkor szintén jó ötletnek tartottak, de ma már kiderült, hogy a gyakorlatban horrible mess az egész.. Bővebben a tervekről a projekt oldalán angolul.

WebKit fejlesztői szemmel

WebKit box logo

Megjegyzés: A cikk az eredeti, Paul Irish által írt cikk fordítása. (forrás)


Sokaknak a WebKit egyfajta fekete doboz. Dobunk neki egy kis HTML-t, CSS-t, JS-t és egyéb eszközöket, majd a WebKit valahogyan, varázslatosan átalakítja azt egy weblappá, ami jól néz ki és működik. De igazság szerint, hogy kollégám, Ilya Grigorik szavaival éljek
A WebKit nem egy fekete doboz. Hanem egy fehér doboz. Pontosabban egy nyílt, fehér doboz.
Akkor most álljunk meg egy pillanatra és vegyünk át pár dolgot:
  • Mi a WebKit? Mi nem a WebKit?
  • Hogyan használják a WebKit-et a WebKit-alapú böngészők?
  • WebKit-en belüli különbségek?
Most, különösképpen a következő írást alapul véve: Opera has moved to WebKit, van számos WebKit-alapú böngésző, de elég nehéz megérteni, hogy mely elemek közösek és mely részeikben vállnak el egymástól. A most következő írás elolvasása után remélhetőleg sok minden világosabb lesz. Továbbá könnyebben képes leszel különbséget tenni a böngésző egyes részei között, majd a hibákat, tapasztalt problémákat a megfelelő helyen jelenteni és jobban megérteni a specifikus böngészők fejlesztésének mikéntjét.

Hagyományos Webböngésző Komponensek

Lássuk, milyen komponensekből tevődik össze egy mai modern böngésző:
  • Parsing (HTML, XML, CSS, JavaScript) (feldolgozás, elemzés)
  • Layout (kirajzolás, elrendezés)
  • Text and graphics rendering (szövegek és grafikai elemek megjelenítése)
  • Image decoding (képek dekódolása)
  • GPU interaction (GPU interakciók)
  • Network access (Hálózati hozzáférés)
  • Hardware acceleration (Hardveres gyorsítás)
Ezek közül melyek közösek a WebKit-alapú böngészőkben? Nagyjából csak az első kettő.A többi önállóan kerül kezelésre az egyes WebKit portokban. Nézzük, mit is jelent ez…

A WebKit Portok

A WebKitnek vannak különböző “portjai”, de hadd idézzem Ariya Hidayat, WebKit hacker és a Sencha műszaki igazgatójának magyarázatát:
A népszerű "WebKit" kifejezés alatt általában az Apple saját WebKit fejlesztését értjük, amely Mac OSX-en fut és (az első és eredeti WebKit library). Mint kitalálhatod, a különböző, natív libeken alapuló különféle interfészek legtöbbje Mac OSX-en a CoreFoundation köré szerveződik. Például ha csinálsz egy sima, színes gombot specifikus border-radius használatával, a WebKit tudni fogja hova és hogyan rajzolja ki az a gombot. Azonban a gomb kirajzolásának végső felelőssége (mint a felhasználó monitorján lévő pixelek) már a CoreGraphics hatáskörébe tartoznak. Ahogy fentebb is említettem, a CoreGraphic használata a Mac-es port sajátja. A Chrome Mac-es változata már Skia-t használ.
Idővel a WebKit portolásra került különböző platformokra, desktopon és mobilon belül. Ezeket gyakran hívják "WebKit port"-nak. A Windows-os Safari esetében az Apple saját maga portolta a WebKitet Windows alá, mindezt a saját CoreFoundation library-jának (limitált változatának) Windows verziójával.
… bár a Windows-os Safari most már halott.
Emellett volt sok más egyéb port is (lásd a teljes listát). A Chromium portot a Google hozta létre és tartja fenn. Van WebKitGTK amely GTK+-on alapul. A Nokia (a Trolltech-en keresztül, melyet felvásárolt) pedig a Webkit Qt portjáért felel, azaz a QtWebKit module-ért.

A WebKit néhány portja

  • Safari
    • Az OSX-es Safari és a Windows-os Safari két különböző port
    • A WebKit nightly a Safari által is használt Mac-es port instabil ága. Bővebb információ az írás további részében…
  • Mobile Safari
    • Egy magán ág szárnyai alatt, de az utóbbi időben being upstreamed(?)
    • Chrome iOS változata (az Apple WebView-ját használja; a különbségekről később a cikkben)
  • Chrome (Chromium)
  • Android Browser
    • A legújabb WebKit forrást használja
  • További portok: Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, stb.
A különböző portok különböző területekre koncentrálnak. A Mac-es port megoszlik a böngésző és az operációs rendszer között és Objective-C és C++ nyelveket használ, hogy beágyazza a megjelenítő motort a natív alkalmazásokba. A Chromium középpontjában tisztán a böngésző áll. A QtWebKit pedig alkalmazások számára kínálja portját futtatókörnyezetként vagy megjelenítő motorként kereszt-platformos GUI architektúrára.

Mi az, ami közös minden WebKit böngészőben?


Először is vegyük szemügyre közös vonásokat az összes WebKit portban.
  1. Először is a WebKit a HTML-t ugyanazon a módon értelmezi, dolgozza fel. Jó, a Chromium kivételével, ami az egyetlen port, ami rendelkezik threaded HTML parsing támogatással.
  2. … Oké, de a feldolgozás után a DOM fa szerkezete ugyanaz. Nos, igazából a Shadow DOM csak a Chromium portban van bekapcsolva, tehát a DOM szerkezet különbözik. Ugyanez a helyzet az egyéni elemekkel.
  3. … Oké, a WebKit létrehoz egy window objektumot és egy document objektumot mindenkinél. Igaz, bár a tulajdonságok és konstrukciók lehetnek feltételesek egyes portokban függően az engedélyezett feature flag-ektől.
  4. … A CSS elemzése egyforma. Csak fogja a CSS-t és átalakítja csini szabványos formára. Igen, bár a Chrome csak a -webkit- prefixeket fogadja el miközben az Apple és egyéb portok a hagyományos prefixeket, mint -khtml- és -apple-.
  5. … Elrendezés (layout).. pozicionálás? Akárcsak a kenyér és a vaj. Ugyanazok, nemde? Ugyan már! A sub-pixel layout és a saturated layout arithmetic része ugyan a WebKitnek, de portról-portra különböznek.
  6. Szuper.
Tehát ez így kicsit bonyolult. Csakúgy, mint ahogyan a Flickr és a Github implementál tulajdonságokat egyes flag-ek mögött, a WebKit ugyanazt teszi. Lehetővé teszi a portok számára, hogy engedélyezzünk/letiltsunk mindenféle funkcionalitást a WebKit fordítás-idejű Feature Flag-jeinek használatával. A tulajdonságok használhatók futásidejű flagekként is, vagy parancssori kapcsolókként (lásd: Chromium) vagy konfigurációs beállításként, lásd: about:flags. Rendben, akkor próbáljuk újra megfogalmazni mi azonos a WebKit-világban…

Mi a közös minden WebKit portban?

  • A DOM, window, document
    • többé-kevésbé
  • A CSSOM
  • CSS elemzés, tulajdonságok/értékek kezelése
    • vendor prefix-ek nélküli kezelés
  • HTML elemzés és DOM szerkezet
    • ugyanaz, ha kizárjuk a Web Components-t
  • Minden elrendezés és pozicionálás
    • Flexbox, Floats, block formatting kontextusok… minden ugyanaz
  • A Chrome DevTools azaz WebKit Inspector eszközkészlete és felhasználói interfésze.
    • Bár 2012 áprilisa óta a Safari a saját, nem-WebKit, zárt-forráskódú UI-ját használja a Safari Inspector számára
  • Tulajdonságok, mint contenteditable, pushState, File API, SVG legtöbbje, CSS Transform math, Web Audio API, localStorage
    • Bár a backend-ek változók. Egyes portok talán eltérő storage layer-t használnak localStorage-hoz és eltérő audio API-kat a Web Audio API-hoz.
  • Számos egyéb tulajdonság és funkcionalitás
Kezd egy kicsit homályos lenni egyes területeken. Próbáljunk felsorolni pár különbséget, ami kevésbé homályos.

Mi az ami nem közös a WebKit portokban:

  • Bármi, ami kapcsolatos a GPU-val
    • 3D Transforms-mal
    • WebGL-lel
    • Video dekódolással
  • 2D kirajzolása a képernyőre
    • Antialiasing megközelítések
    • SVG & CSS gradient rajzolás
  • Szöveg megjelenítés és elválasztás
  • Network stack (SPDY, prerendering, WebSocket transport)
  • JavaScript motor
    • JavaScriptCore van a WebKit repóban. Vannak kötődései a WebKit-hez ennek is és a V8-nak is egyaránt
  • Űrlap vezérlők megjelenítése
  • <video> <audio> elemek viselkedése (és a codec támogatása)
  • Képek dekódolása
  • Előre/vissza navigáció
    • A navigáció a pushState() része
  • SSL tulajdonságok, mint Strict Transport Security és Public Key Pins
Nézzük az alábbit: 2D graphics Az adott porttól függ, különböző libeket használ, hogy a képernyőre rajzolást kezelje: Graphics layer in WebKit Vagy hogy még mélyebbre ássunk… egy nemrég landolt funkció: CSS.supports() engedélyezve lett mindegyik portban, kivéve win és wincairo, melyekben nincsenek engedélyezve a css3 feltételes tulajdonságok. Most, hogy a technikai részéhez értünk.. ideje, hogy pontosabban fogalmazzunk. Még a fenti rész sem teljesen helytálló. Igazából a WebCore az, ami megosztott. A WebCore egy elrendező, renderelő és Document Object Model (DOM) library a HTML és SVG részére, és általában az emberek erre gondolnak, mikor WebKitről beszélnek. A valóságban azonban a “WebKit” technikailag a kötőréteg a WebCore és a portok között, bár alkalmi beszélgetésekben ez a különbségtétel általában elhanyagolható. Ez a diagram talán érthetőbbé teszi: WebKit DiagramSok komponens a WebKit-en belül felcserélhető (a szürke színnel jelöltek). Példaként, a WebKit JavaScript motorja a JavaScriptCore, ami az alapértelmezett a WebKitben. (Eredetileg a KJS-en (KDE fejlesztés) alapul még azokból az időkből, mikor a WebKit kinőtt a KHTML forkjaként). Eközben a Chromium port lecserélte V8-ra és egyedi DOM kötéseket használ, hogy feltérképezze a dolgokat. A fontok és a szöveg renderelése a platform nagy része. Két különböző szöveg útvonal van WebKitben: Fast és Complex. Mindkettő platform-specifikus (port-oldali) támogatást igényel, de a Fast-nak csak a karakterek feldolgozásában kell "segítség" (amelyet a WebKit gyorsítótáraz a platformon) és a complex igazából átadja az egész string-et a platform layer-nek és utasítja: “rajzold ki, kérlek”.
“A WebKit olyan, mint egy szendvics. Bár a Chromium esetében sokkal inkább egy taco. Egy finom, web-platform taco.” Dimitri Glazkov, Chrome WebKit hacker. A Web Components és a Shadow DOM bajnoka
Most szélesítsük látókörünket és nézzünk meg néhány portot és néhány alrendszert. Lejjebb ötféle WebKit portot láthatsz; melyek egyúttal példázzák, mennyire különbözők lehetnek, a közös WebCore ellenére.
Chrome (OS X)Safari (OS X)QtWebKitAndroid BrowserChrome for iOS
Renderelés: Skia CoreGraphics QtGui Android stack/Skia CoreGraphics
Hálózatkezelés: Chromium network stack CFNetwork QtNetwork Fork of Chromium’s network stack Chromium stack
Szövegkezelés: CoreText via Skia CoreText Qt internals Android stack CoreText
JavaScript V8 JavaScriptCore JSC (V8 is used elsewhere in Qt) V8 JavaScriptCore (without JITting) *
* Egy megjegyzés a Chrome for iOS-re vonatkoztatva: UIWebView-et használ. Az UIWebView korlátai képességei miatt ez azt jelenti, hogy (csak) ugyanazt a renderelő layer-t használ(hat)ja, mint a Mobile Safari, valamint a JavaScriptCore-t (V8 helyett) és single-process model-t. Mégis jelentős Chrome-oldali kód maradt benne, mint network layer, a szinkronizáció és a könyvjelző infrastruktúra, omnibox, metrics és hibajelentő. (Továbbá érdemes megjegyezni, hogy mobilon a JavaScript ritkán jelenti a szűk keresztmetszetet, így a JIT Compiler hiánya minimális negatív hatással van rá)

Rendben, tehát akkor hová jutottunk?

 

Ezek szerint minden WebKit teljesen különbözik. Megrémültem.

Ne tedd! A layoutTest lefedettség WebKit-ben hatalmas (28,000 layoutTest és folyamatosan bővül), nem csak a létező funkciók, hanem bármilyen regresszió. Igazából bármit felfedezel, valami új ezoterikus DOM/CSS/HTML5-y fícsört, a layoutTest-ek gyakran fantasztikus minimális demókkal rendelkeznek a teljes webplatformon. Ezen túl, a W3C nagy erőfeszítéseket tesz a conformance suite testing érdekében. Ez azt jelenti, hogy bár különböző WebKit portok különböznek, de ugyanazokon a teszteken kell átmenniük, ami kevesebb quirk-módhoz és több szabványossághoz, egységességhez vezet. Mindazok számára, akik segítették ezt az erőfeszítést a Test The Web Forward event-en való részvételükkel… köszönöm!

Az Opera is WebKitre fog váltani. Hogyan fog ezek után működni?

Robert Nyman és Rob Hawkes már pedzegette a témát, de én hozzáadom egy jelentős részét az Opera bejelentésének, miszerint Az Opera adoptálja a Chromium-ot. Ez azt jelenti, hogy a WebGL, Canvas, HTML5 formok, 2D graphics implementációk-és minden ehhez hasonló cucc ugyanaz lesz Chrome-ban és Operában. Ugyanazok az API-k és ugyanaz a backend implementáció. Mikortól az Opera Chromium-alapú lesz, magabiztos lehetsz, hogy az általad fejlesztett weboldal Chrome és Opera alatt is ugyanúgy fog kinézni és működni. Az szintén megjegyzendő, hogy az összes Opera böngészőa Chromium-ot adoptálja. Tehát az Opera Windowsra, Mac-re, Linuxra, az Opera Mobile (a teljeskörű mobilböngésző). Még az Opera Mini is, a vékonykliens is kicseréli a szerveroldali renderelő farmját Presto-ról Chromium alapúra.

.. és a WebKit nightly, az micsoda?

Az a WebKit mac port-ja, ugyanazt a binárist használja, mint a Safari (néhány mögöttes libet kicseréltek benne). Tehát a viselkedése és a tulajdonságai megegyeznek a Safariéval. Egyszerűbb példával élve, gondolj rá úgy, hogy a… WebKit Nightly ugyanaz a Safarinak, mint a Chromium a Chrome-nak. Chrome Canaryis a legújabb WebKit forrást használja maximum pár napos késéssel.

Ha szeretnél többet tudni a WebKit belsejéről, lásd a következő prezentációt:

További olvasnivaló:

Remélhetőleg ez a cikk kicsit részletesebben elmagyarázta a WebKit belsejét és megvilágította, hogy hol végződik a WebKit és hol kezdődnek a WebKit-portok.
A cikk áttekintve Peter Beverloo (Chrome) és Eric Seidel (WebKit) által. Frissíteni fogom további korrekciókkal és módosításokkal.

Kiszivárogtak a Webkites Opera screenshotjai!

Update:További fejlemények: Úgy néz ki, hogy a zoom slider is megmarad. (forrás)

Sajnos nem mutatnak túl sokat, de a semmitől ez is több.

sheepHåkon Wium Lie véletlenül vagy direkt egy eredetileg CSS3 bemutatónak szánt oldalon kiszivárogtatta a WebKites Opera néhány screenshotját.

A jó hír, hogy nem látszik túl sok. És ez egyben a rossz hír is. Ugyanis még a Wand-hoz tartozó kulcs ikon sem látszik. Még 1000%-os nagyítással sem. :) Ahogy a könyvjelzős csillag sem.

A további találgatásokat meghagyom a látogatóknak, mindenki döntse el, hogy a WinGOGI külső vajon mennyire tükrözi a közelgő Opera új irányvonalát.

Egy kép ide, hogy ne kelljen keresni, a többi pedig a fenti oldalon keresztül érhető el:

Viszont további jó hír, hogy Håkon Wium Lie ilyet írt egy levelezőlistára nem rég (az alsó rész, vagyis a válasz az övé):

Michelangelo De Simone wrote:
> it's great to have you in the community, welcome!
> A question, that it's likely to be OT for this list [1]: do you
> guys have any plan to open Presto's source?

It may be that the Presto code will be released, but for now it's all hands on deck making the transition. So far, it looks good :)

Ha ez tényleg megtörténik, akkor kevésbé kell aggódni, mert bár az Opera cég csinálhat bármit, a hagyatékukat továbbfejlesztheti bárki és még jobbá teheti. Ha kellően felkapja a közösség, akkor akár a régi bugokat is javíthatják és régóta várt funkciókkal bővülhet egy új néven és új ikonnal, még ha az Opera be is áll a sorba.

300 millió felhasználóval az Opera Webkitre vált!

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

Webkit-Opera-FusionA 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.