Magyar Opera

Megjelent az Opera Ice - egy korszak lezárul

Ma megjelent végre a mindenki által várva várt WebKit-es Opera, Opera Ice kódnéven. Nevéhez hűen feltehetőleg fagyos hangulatot fog hozni Operás körökben. Aki eddig még reménykedett, most annak most arcára fagy tőle a mosoly. Sajnos.

Nem csak az Opera kódja vett 180°-os fordulatot, de a cég többi projektje is ehhez igazodik. A jövőben nem lesznek fix verziók Operából ugyanis az új Opera átáll a rolling release terjesztési modellre. Az Opera Next-nek is vége (illetve megmarad a 12-es ágnak, erről a postban később bővebben), helyette bevezették az Opera Ice dev, Opera Ice beta és Opera Ice stable ágakat. [vajon honnan olyan ismerős ez a 3 megnevezés? Szerencsére jégkanári (még) nincs - a szerk.]

A Desktop Team blog is megszűnik jelen valójában (illetve megmarad a még támogatott 12-es ághoz tartozó frissítések bejelentésére), helyette már a Dev blogon jelentik majd be az új verziók changelogjait.

opera14beta.png

Amint a screenshoton is látjátok, ez lett az új Operából. Aki még ezek után is kedvet érez, hogy kipróbálja, annak jó hír, hogy x64-es Windows változat is van belőle (bár kétlem, hogy a V8-at átírták volna, szerintem az IE9-hez hasonlóan 32 bites JS motor fut a 64 bitesben) valamint immáron 4 platformra is elérhető: Az eddigi Windows, Mac és Linux mellett ARM-re is. Ez utóbbi valószínűleg az Opera új irányvonalára is hatással van, mivel az eredeti bejelentésben gyanúsan sokszor szerepelt a "tablet" kifejezés.

Igazából nem tudok más egyebet írni róla, siettem a post megírásával, ezért még nem próbáltam ki, egyelőre még Desktop Team post sincs, csak Labs és Press.

Valahol várható volt ez a döntés. Mindannyian reménykedtünk, hogy nem ez lesz, de legtöbbünkben ott volt ez a sejtés. A cikk alján találtok linket a bemutató videóra is, meg természetesen a letöltési linkeket, ha ezek után még van bárkinek kedve kipróbálni. Na de akkor ugorjunk a második nagy bejelentésre, ami egyfajta vigaszdíjként szolgál az Operás közösség részére. Ez pedig nem más, minthogy az Opera 12.1x ágat biztonsági frissítésekkel 2014 végéig támogatni fogják. Új funkció már nem kerül bele, a HWA is félkész marad, kizárólag biztonsági frissítéseket kapunk, de ez azt jelenti, hogy legalább addig használhatjuk, addigra meg hátha lesz valami. A Presto forráskódjának kiadását egyelőre még nem jelentették be, de még halvány reménysugárként bennünk élhet.

Most pedig következzenek a letöltési linkek:

Letöltés (Opera Ice 14 r33271)

Opera 12.15 RC (b1742)

A közelgő WebKites verziót (amiből még pre-alfát sem kaptunk, a végleges pedig még ennél is messzebb van) valószínűleg egy újabb, felfedezett biztonsági rés késlelteti, aminek a következtében a jelenlegi előzetes született. Elvégre mi más indokolná a nagy hajtásban sovány-bugfix verziók kiadását? A mostani RC egyúttal hagyománytörő is, mert sosem volt még x.x5-ös verzió, mindig x.x4-nél befejeződött és jött a következő.

Most következzen a szerény, 3 elemet tartalmazó változáslista:

Változások listája (XXX):

  • Néhány összeomlás-javítás
  • CORE-49411 Opera ignorálta a readAsArrayBuffer argumentumot a FileReader újbóli használatakor
  • CORE-48348 A poszterek lejjebb kerültek IMDb-n, mivel az inline-block egy felesleges <br>-t csinált

Letöltés (Opera 12.15 RC b1742)

Kiegészítő ajánló: TextBoXpander

Sok helyre írsz kommentet, hozzászólást? Néha, gyakran vagy éppen majdnem mindig elég hosszúra sikerül és utálsz hangyaf@sznyi szövegdobozokban fel-le scrollozni? Ha igen a válaszod, akkor a most következő kiegészítőt neked találták ki. Ugyan egy ideje már az Opera is beépítve tartalmazza a szövegdobozok átméretezhetőségét (UserJS és kiegészítő pedig évek óta van rá), de ez folyamatos manuális user interakciót kíván, ami egy idő után egyhangú és idegesítő tud lenni.

Ugyancsak régóta létezik már Autogrow Textarea Plugin, de ezt valahogy nem akaródzik senkinek implementálni a saját oldalára. Így hát ha a hegy nem megy Mohamedhez alapon christoph142 készített egy nagyszerű, hiánypótló kiegészítőt TextBoXpander néven, amely megoldja a fent taglalt problémát.

Nem kell beállítani semmit, annyi a dolgunk, hogy telepítjük és élvezzük a hatását. De ha mégis szeretnénk testre szabni, erre is van lehetőségünk. Egy legördülőmenüből kiválaszthatjuk, hogy milyen irányokba szeretnénk méretezni. Az alapbeállítás "horizontális", de ehhez jobb, ha csak a kísérletező kedvűek nyúlnak, ugyanis a vertikális tud csodákat művelni, tekintettel arra, hogy milyen gányolt weboldalak vannak manapság... Ezen felül még a transition effektus sebességét is meghatározhatjuk egy csúszkával.

Opera 14 béta Androidra megérkezett!

Tipp: Ha neked is bántja a szemedet ez a csúnyán formázott szöveg, elolvashatod itt is. Természetesen a kommenteket ez alá írd, mert az az oldal még nem aktív.

screenshot

Igen, valóban. A verziószám: 14. Úgy gondoljuk, hogy az Opera Presto-ról WebKit-re történő váltása amit néhány hete jelentettünk be, akkora lépés, hogy úgy döntöttünk, kihagyjuk a teljes 13-as számot és egyenesen 14-gyel kezdünk! De a motoron túl más egyéb változásokról is beszélhetünk: valószínűleg a kis képből is észrevettétek, hogy az UI-n nagy változások mentek végbe mindez natív kódban, hogy jobban illeszkedjen a legújabb Android designba és megfeleljen az ottani iránymutatásoknak. Töltsd le a bétát a Google Play-ről vagy az m.opera.com-ról és tegyél vele egy próbát!

Android 2.3 és újabbak

Jelenleg az Android 2.3-től felfelé támogatja a rendszereket a böngésző. Ez fontos, mivel a az Android felhasználók 45%-a még Gingerbread-et használ — most ők is megkaphatják a legújabb fícsöröket és a legjobb teljesítményt!

Jelenleg még nincs Opera 14 összeállítás tabletekre: még dolgozunk különféle UI optimizációkon és csak később lesz publikus build.

Egy teljesen új motor

Ez az első béta kiadás az AppleWebKit/537.22-en és a Chrome/25.0.1364.123-en alapul — a gyors fejlesztési ciklust követjük ezentúl, tehát nagyon valószínű, hogy a végleges Opera 14 termék még újabb mérföldköveken fog alapulni.

Az Operában lévő motor nagyon szorosan szinkronban van a Chrome Beta-jában lévő motorral (amely jelenleg AppleWebKit/537.22 és Chrome/25.0.1364.122), néhány hozzáadott extra szabvány-közeli csiszolással.

Az Opera 14 for Android alapból támogatja a következő dolgokat:

  • input type=color
  • Microdata
  • WebGL 3D context
  • CSS3 @supports

Az Opera 14 for Android nem támogatja a következőket:

  • Custom search providers
  • hozzáférés a chrome://flags-hez

Mindezeken túl új User Agent-et is kapott, a régi szűrési módszereket elkerülendő: ugyanaz a formátum, mint a Chrome UA string-je a végén ezzel a résszel: "OPR/14.0.1025.52315". Természetesen ezt egyáltalán nem kell nézned webfejlesztőként, helyette alkalmazd a feature detection-t, tehát felejtsd is el, hogy említettük.

Új UI és fícsörök

Az első dolog, amit észrevehetsz az új Discover funkció, amely abban segít, hogy érdekes online tartalmakat találj. Ha balra haladsz, a Speed Dial jelenik meg, ami mostantól a könyvjelzőidet is tartalmazza. Kombinálhatod a könyvjelzőidet egy mélységig a drag and drop használatával egymás tetejére dobálva őket. ÉS ha még balra mész, a böngészési előzmények tárulnak eléd. Ez a 3 nézet jó hely, hogy mélyebbre ásd magad a böngészésben, vagy lekérdezhetsz webhelyeket a kombinált címmező+keresősávból.

A vörös O gomb jobb oldalt felülre került, akárcsak a többi Android alkalmazás esetében, és a haladó opciókat lehet vele előhozni, mint Megosztás, Keresés oldalon belül, Letöltések, Beállítások, stb.

Azonban az egyik speciális kiemelt funkció itt az Off-Road mode: ugyanaz, mint az Opera Turbo. Mikor bekapcsolod az Opera Mini szerverein át folyik az adatáramlás, ezzel felgyorsítva a lassabb mobilneteket, valamint csökkentve az adatforgalmat. Úgy gondoltuk: Yo dawg, we heard you like browsing, so we put a browser in your browser! Haver, úgy hallottuk, szeretsz böngészni, szóval teszünk egy böngészőt a böngésződbe!. Tehát nem kell többé böngészőt váltanod, hogy megkapd az Opera Mini funkcionalitását: megkapod ezen a böngészőn belül is.

Természetesen további részletekről is lehetne beszélni — a plusz gomb, privát fülek, browser.js — de meghagyjuk neked, hogy felfedezd ezeket. Jó böngészést és tesztelést!

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.
süti beállítások módosítása