Már éppen lefekvéshez készülődtem, amikor tudomásomra jutott, hogy megjelent az új Opera első előzetese. Pedig már jó ideje elérhető volt a Desktop Team blogon, de ez is jellemzi az utóbbi időket. Olyan régen jelent meg érdemi verzió, hogy már teljesen elszoktam az oldal látogatásáról. Mindenesetre a hír hallatán mindjárt indultam is hogy letöltsem azt az Operát, amit - ilyen vagy olyan előjellel - minden Opera rajongó úgy várt, mint talán még soha egyetlen verziót sem.
Ennek oka értelemszerűen az volt, hogy az Opera korábban bejelentette: szakít az általa közel 20 éve fejlesztett motorral - aminek mostanában Presto a neve - és WebKit-re cseréli azt. Aztán kiderült, hogy az már nem is WebKit lesz, hanem Blink, amely névvel a Google illeti a saját képére formált WebKitet. Sejthető volt, hogy az új változat komoly mértékben változtatja meg kedvenc böngészőnket. Szóval sok minden, ami az újdonság megjelenésével kiderült, tulajdonképpen nem meglepetés, de mégiscsak furcsa az Opera kontextusában rájuk tekinteni.
Nulladik benyomások
Az első kisebb meglepetést a bejelentő cikk okozta: rendben, hogy kihagyják a 13-as verziót, de a 14-est is átugrották, nem hittem volna, hogy még a Google-nél is gyorsabban tudnak verziószámokat emelni... Gondolom azért ez a nagy ugrás, hogy a viszonylag kerek 15-ös szám könnyebben megjegyezhető legyen. Kb. mint a 8.5, ami annak idején szintén nagy ugrásnak számított, pedig egyetlen új "funkciója" az ingyenessége volt.
A másik nem váratlan, de mégiscsak keserű meglepetés a letöltés során ért: a jövevény mérete nem kevesebb, mint 24,3MB. Ez gyakorlatilag duplája a 12.15-ös - és nagyjából az összes eddigi - Opera verziónak. Pedig ebben már a megcsupasztott Blink motor dübörög, és a cikkből előre kiderült, hogy kikerült belőle az M2 kliens. Később az is, hogy nem csak az...
Szerintem elmondható, hogy a jelenlegi - mármint a 12-es - Opera rendelkezik talán a böngészők között a legösszeszedettebb telepítővel. Ez a legkisebb, mégis ez rejti a legfunkciógazdagabb programot. Ráadásul tetszetős és letisztult, mégis számos beállítási lehetőséget rejt.
Szerencsére a méreten túl más hátrányunk nem származik a váltásból: a telepítő most is szép, és - ami még fontosabb - továbbra is lehet hordozható változatként telepíteni, ami egyetlen más böngészőről sem mondható el. Mármint gyári kivitelben. Azt is a javára kell írnom, hogy az amúgy sem lassú mostani verzióhoz képest is gyorsabban települt, nagyobb méret ide vagy oda, éppen csak bevillant a folyamatot jelző csík.
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ő:
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.
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…
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.
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.
… 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.
… 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.
… 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-.
… 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.
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.
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: 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: Sok 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)
QtWebKit
Android Browser
Chrome 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:
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.
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.
Hå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.
Elsőként is békés, boldog karácsonyi ünnepeket és eredményekben gazdag új évet kívánunk minden Olvasónknak.
Egy felemás esztendő
Bizonyára sokan, sokféleképpen tudnák értékelni, összefoglalni a norvég böngészőfejlesztő idei teljesítményét. Nincs könnyű helyzetben a szerkesztő sem, hiszen egyfelől a 9 megjelent asztali Opera kiadás nem nevezhető kevésnek - arányosan elosztva ez azt jelenti, hogy nagyjából 6(!) hetenként kaptunk egy új verziót -, másrészről viszont ebből 7 minor frissítés és csak kettő "major release". Előbbi kategóriába tartozik az Opera 11.61, 11.62, 11.64, 12.01, 12.02, 12.11 és a 12.12, utóbbi listára pedig az Opera 12.00 és a 12.10 iratkozhat fel. A teljes korrektség jegyében érdemes megjegyezni, hogy Macre elkészült a 11.63-as verziószámmal felvértezett összeállítás is, azzal együtt már 10 példánynál járunk.
Az első dobbantás
Kétségtelenül hatalmas várakozás, ebből kifolyólag igen komoly elvárások övezték a 12-es Operát. A fejlesztés sokáig elhúzódott, azonban a hardveres gyorsítást így sem sikerült tökéletesre csiszolni. Windows alatt alapértelmezetten már DirectX-et használt a rendszer, de ez még nem minden esetben múlta felül a szoftveres kimenetet. Sebaj, kaptunk helyette out-of-process beépülő-kezelést, jobb szabványtámogatást (Drag&Drop implementáció, CSS animációk), natív 64 bites verziót és felhasználóbarátabb témázhatóságot. Az Opera 12 jól példázza a Desktop Team kétarcú teljesítményét, hiszen ezzel párhuzamosan kikerült a hangvezérlés támogatása és az Unite, jobblétre szenderültek a minialkalmazások, ezenkívül megmaradt az azóta is be nem váltott ígéret: WebGL és hardveres gyorsítás.
A szokásos menetrend
Rutinosabb Operások valószínűleg ekkortájt még talonba tartották a 11.64-et, mert az új nagyágyú ismételten hemzsegett a hibáktól. Augusztus végére a 12.02 személyében sikerült stabilizálni a helyzetet, ekkor ismét felcsillant a remény: karácsonyra valamilyen formában (alfa, béta) talán már elérhető lesz a 12.50, mely a 10.50-nél felmutatott erényekkel kecsegtet!
Lefokozva
Az Opera 12.10 bétája végérvényesen eloszlatta az előbbi gondolatokat, ám a november elején megjelenő újonc annyi fejlesztést vonultatott fel, ami szinte már irreális volt a Desktop Team erőforrásaihoz mérten. Az oldalbetöltés az SPDY és a DNS-előtöltés révén gyorsult, előtérbe kerültek az érintőkijelzőt érintő újítások és ismét javult a szabványok kezelése (HTML5, Flexbox, alapértelmezetten bekapcsolt WebSocket). Persze a gyors tempó megint a stabilitás kárára ment, így nem volt kérdés, hogy megjelenik az Opera 12.11, talán még a 12.12 fontosságát sem sokan kérdőjelezték meg. Szép lassan eltelt a november, majd december 18-án a megkésett télapó beállított a második hibajavításra szakosodott frissítéssel.
Jóslásokba végképp nem bocsátkoznék, de az utolsó sorokkal mégiscsak illene valamilyen keretbe foglalni az összefoglalót. A két major frissítés tekintélyes számú újítást hozott, illetve a 7 stabilitás és hibajavító változásokra szakosodott verzió sem nevezhető elenyészőnek. Az összkép viszont távolról sem rózsás, hiszen még mindig sokan tudnának kellemetlenkedő bugokat megnevezni és bizony az Opera 12.12 kevés eséllyel pályázna a legstabilabb böngésző címre.
A vállalat pénzügyi elemzéséből kirajzolódó statisztikákat nézve is vegyesen értékelhető képet látni, az alapján az asztali változatot használó felhasználók száma valamelyest csökkent. Egy nagyon halovány tendencia indult el tavaly a harmadik negyedévben, ami 2012 első hónapjaiban 60 milliónál csúcsosodott ki. Azóta ez a szám 55 millióra esett, ráadásul előrelépés továbbra sem várható, egy másfél százalékos táborra pedig sokan csak legyintenek.
Legutóbb 9 hónapja tekintettük át az Opera Software pénzügyi helyzetét. Azóta eltelt 3 negyedév, ami ugyanennyi jelentést takar. Mint ismert, az Opera egy részvénytársaság, amely évente négy alkalommal beszámol a részvényeseknek a saját anyagi állapotáról, jövőbeli terveiről.
Ilyenkor egy előadásra kerül sor, amit egy jelentés kiadása követ. Ezeket bárki közvetlenül letöltheti az Opera befektetőknek szánt oldaláról. Nézzük, hogy laikusként mit tudunk kiolvasni belőle.
Egy Operához hasonló vállalkozás esetében a legfontosabb cél a profit, méghozzá a hosszú távú profit. Ehhez azonban először is mindenkor bevételek szükségesek. Az Opera több pillérre támaszkodhat, amelyek így vagy úgy a böngészőhöz illetve magához az internethez kapcsolódnak. A bevétel az alábbi grafikon szerint oszlik meg az egyes ágak között:
Desktop
Az általunk legjobban ismert és használt termék az asztali böngésző, ami a PC-ken fut. Itt elsősorban a keresőkkel kapcsolatos megállapodással lehet pénzt termeli, de például az alapértelmezett gyorshívó bejegyzés is hozhat némi pénzt. Előbbi téren leginkább a Google-re támaszkodik a cég, de az elmúlt időszakban is több más szolgáltatóval kötött megállapodásokat: Booking.com, Groupon, Ozon.ru, Hungama, Amazon.com és Ebay. Mindezek együtt az összbevétel kb. harmadára voltak elegendők, miközben a felhasználói létszám 54 millió fő körül stagnált.
Mobil operátorok
Összhangban az Opera stratégiájával, az egykor komoly bevételt jelentő mobilgyártók (OEM-ek) egyre inkább háttérbe szorulnak, az utóbbi időszakban is csak egy Spreadtrum (vezető kínai chipset gyártó) szerződésre futotta, helyüket pedig a mobilszolgáltatók veszik át. Számukra az Opera egyik legfontosabb terméke az Opera Mini, és leginkább annak operátorosított verziója. Már mi is láthatjuk testközelből, miről is van szó, hiszen a Telenor által reklámozott Klikk csomag pontosan a Minin alapul.