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)
  • Chrome Android-ra (közvetlenül a Chromium portot használja)
  • A Chromium alapjául szolgál a Yandex Browser-nek, 360 Browser-nek, Sogou Browser-nek, és hamarosan az Operának.
• 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: 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) *

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ó:

• WebKit internals technical articles | webkit.org
• WebKit: An Objective View | Robert Nyman & Rob Hawkes
• your webkit port is special (just like every other port) | Ariya Hidayat
• Getting Started With the WebKit Layout Code | Adobe Web Platform Blog
• WebKit Documentation Overview | Arun Patole
• Rendering in WebKit, by Eric Seidel | YouTube
• web performance for the curious | Ilya Grigorik

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.