WebKit for developers

Original author: Paul Irish
  • Transfer


For many of us developers, WebKit is a black box . We throw HTML, CSS, JS and a bunch of images into it, and WebKit, somehow ... magically, gives us a web page that looks and works well.
But in fact, as my colleague Ilya Grigorik says :
The web kit is not a black box. This is a white box. And not just white, but also an open box.

So, let's try to figure out some things:
  • What is WebKit?
  • What is WebKit not?
  • How is WebKit used by WebKit browsers?
  • Why are many WebKit not the same?

Now, especially after the news that Opera switched to WebKit , we are surrounded by many WebKit browsers, and it's hard to say what unites them, and where they go their own way. Below, I hope we will try to shed some light on this issue. As a result, you can better determine the differences between the browser, send bugs to the correct tracker, and conduct cross-browser development more efficiently.

Standard web browser components


Let's list a few components of modern browsers:

  • Parsing (Parsing HTML, XML, CSS, Javascript)
  • Layout
  • Text and graphics rendering
  • Image decoding
  • GPU interactions
  • Network access
  • Hardware acceleration

Which of them are common to all WebKit browsers? To a large extent, only the first two.

Each WebKit "port" implements the remaining components in its own way. Let's see what this means.

Webkit ports



There are many WebKit “ports”, and I provide Aria Hideyat, WebKit hacker and those. Director at Sencha the right to talk about it :

The most popular association for WebKit is typically Apple's WebKit, which runs on Mac OS X (the first and original WebKit library). As you can guess, various interfaces are implemented using various native Mac OS X libraries, mainly concentrated in the CoreFoundation component . For example, if you define a color flat button, with a special radius for the outline, WebKit knows where and how to draw this button. At the same time, the final rendering of the button (in the form of pixels on the user's monitor) rests with CoreGraphics .


As I mentioned above, CoreGraphics used is unique for each WebKit port. Chrome for Mac, for example, uses Skia .

At some point, WebKit was “ported” to different platforms, both desktop and mobile. This variation is commonly called the "WebKit port." For Safari Windows, Apple also itself “ported WebKit” to run under Windows, using the Windows version of its (limited implementation) CoreFoundation library.

... despite the fact that Safari on Windows is now dead .

In addition, there were also many other “ports” (see the full list ). Google has created and continues to support its Chromium port. There is also WebKitGtk based on Gtk +. Nokia (and now Trolltech, which outbid it) supports the WebKit Qt port, which has become popular as a QtWebKit module .


Some WebKit Ports



  • Safari
    - Safari for OS X and Safari for Windows are two different ports
    - WebKit Nightly Build is the Mac port code assembly used for Safari, only newer
  • Mobile the Safari
    - develop in the private branch, but later was opened .
    - Chrome for iOS (uses Apple's WebView; a little later about the difference)
  • Chrome (Chromium)
    - Chrome for Android (uses the Chromium “port” directly)
    - Chromium is also the basis for browsers: Yandex , 360 , Sogou , and soon, Opera.
  • Android Browser
    - Uses the latest WebKit source code available at the time of release.
  • Even more ports : Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK +, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Different ports can focus on different tasks. Mac port focus is the separation between the browser and the operating system, and the provision of Obj-C and C ++ binders for embedding the rendering engine in native applications. The focus of the Chromium port is entirely on the browser. QtWebKit offers to use its port along with its cross-platform application architecture as a rendering engine.

What is common in all WebKit browsers



To begin, let's look at the common functions that are used in all WebKit browsers:

You know this is ridiculous, I made several attempts to write this paragraph. And each time, the Chrome team corrected me, as you will see ...

  1. And so, firstly, WebKit parses HTML the same way. Well, except that Chromium is the only port at the moment where stream support for HTML parsing is included .
  2. ... Well, but after parsing the HTML, the DOM tree is constructed the same way. Well, in fact, the Shadow DOM is enabled only for the Chromium port, i.e. the construction of the DOM varies. Also for custom elements.
  3. ... Well, WebKit creates window and document objects the same for everyone. However, although the properties and structures that they provide are dependent on the use of switches functions (feature flags).
  4. ... CSS parsing is the same. Eating your CSS and converting it to CSSOM is pretty standard. Yeah, although Chrome only supports -webkit- prefixes, when Apple and other browsers support legacy -khtml- and -apple- prefixes.
  5. ... Layout ... positioning? It's like bread and butter. It's the same everywhere, right? Well already! Subpixel layout and rich layout arithmetic is part of WebKit, but differs from port to port.
  6. Super.


So it’s difficult.

Just like Flickr and Github hide implemented functions behind special flags, WebKit does the same. This allows ports to enable / disable any functionality at the compilation stage using the WebKit compile-time Feature Flags . Functions can also be enabled in runtime, using options on the command line (for Chromium) or configurations such as about: flags .

Now, let's try to summarize what is common in the world of WebKit ...

What is common to every WebKit port.


  • DOM, window, document
    more or less
  • CSSOM
  • CSS parsing, property / value
    differences in producer prefixes
  • HTML parsing and DOM building
    Equally, if we forget about Web Components.
  • Layout and positioning
    Flexbox, Floats, block formating context ... all in common
  • UI tools and developer tools like Chrome DevTools aka WebKit inspector.
    Although from last April, Safari has been using its own Safari inspector, non-WebKit, with closed source.
  • Functions such as contenteditable, pushState, File API, most SVG, CSS math transformations, Web Audio API, localStorage
    Although the implementation may vary. Each port can use its own storage system for localStorage and can use a different audio API for the Web Audio API.
  • Many other features.

It’s not quite clear, so let's try to look at some of the differences.

Now, what is not common for WebKit ports:


  • Everything related to the GPU
    - 3D transformations
    - WebGL
    - Video decoding
  • 2D rendering to the screen
    - Anti-aliasing technologies
    - Rendering of SVG and CSS gradients
  • Text Rendering and Hyphenation
  • Network technologies (SPDY, pre-rendering, WebSocket transport)
  • JavaScript engine
    - The JavaScriptCore engine lies in the WebKit repository. But there are binders in WebKit for both him and V8.
  • Rendering form elements
  • Behavior of video and audio tags and codec support
  • Image decoding
  • Backward / Forward Navigation
    - Part of pushState ()
  • SSL features like Strict Transport Security and Public Key Pins

Let's take a look at one of them: the 2D graphics depend on the port, we use completely different libraries for rendering to the screen:



Or if you go into details, a recently added function: CSS.supports () was enabled for all ports except win and wincairo, for which css3 conditional features are not enabled.

Now, we go into technical details ... time to become pedantic. Even the above is not entirely correct. This is actually a WebCore, is a common component. WebCore is a layout, rendering, and DOM library for HTML and SVG, and basically what people think when they say WebKit. In fact, “WebKit” is technically a layer of binders between WebCore and “ports”, although in normal conversation this difference is mostly not important.

The diagram should help:



Many of the WebKit components are switchable (shown in gray).

For example, the WebKit JavaScript engine, JavaScriptCore, is the default WebKit engine. It was originally based on KJS (from KDE) from the days when WebKit started as a branch of KHTML. At the same time, the Chromium port switches to the V8 engine and uses unique DOM bindings.

Fonts and text rendering are a very large part of the platform. There are 2 separate paths for text in WebKit: Fast and Complex. Both require platform-specific support (implemented on the port side), but Fast only needs to know how to map glyphs (which WebKit caches for the platform), when Sophisticated completely transfers the rendering of strings to the platform level and just says “draw it please”.

“WebKit is like a sandwich. By the way, in the case of Chromium, it's more like tacos. Delicious tacos from web technology.
Dmitri Glazkov, Chrome WebKit hacker. Champion of Web Componets, and shadow dom.


Now, let's expand the overview, and look at several ports and several subsystems. Below are five WebKit ports, note how the toolkit for each of them differs, despite the common components:

Chrome (OS X) Safari (OS X) QtWebKit Android browser Chrome for iOS
Rendering SkiaCoregraphicsQtGuiAndroid stack / SkiaCoregraphics
Networking Chromium network stackCFNetworkQtNetworkFork of chromium's network stackChromium stack
Fonts CoreText via SkiaCoretextQt internalsAndroid stackCoretext
Javascript V8Javascript coreJSC (V8 is used elsewhere in Qt)V8JavaScriptCore (without JITting) *


* Footnote about Chrome for iOS. It uses a UIWebView, as you probably know. In accordance with the capabilities of UIWebView, this means that it can only use the same rendering engine as Mobile Safari, JavaScriptCore (and not V8) and a single-threaded model. However, some code is borrowed from Chromium, such as a network subsystem, synchronization of bookmarking infrastructure, omnibox, metrics, and crash reporting. (Also, JavaScript is so rarely a bottleneck on mobile devices that the lack of a JITting compiler has minimal impact.)

Okay, so what have we come to?


And so, all WebKit is completely different now. I'm scared.



Not worth it! The coverage of WebKit with layoutTest tests is enormous. (28,000 tests according to the latest estimates), and not only for existing functions, but also for all regressions found. In fact, whenever you study the new or “secret” DOM / CSS / HTML-5 functions, the “layoutTest” test suites usually have an excellent minimal demonstration.

In addition, the W3C is making efforts to standardize the test suite . This means that we can expect that both WebKit ports and all other browsers will be tested with the same test suites, which will lead to a decrease in quirks and a more interoperable web. For all those who made their efforts by attending the Test The Web Forward event ... thank you!

Opera has just moved to WebKit. What will come of it?


Robert Nyman and Rob Hawks have already touched on this topic , but I will add that, one of the important part of the announcement was that Opera is switching to Chromium . This means that WebGL, Canvas, HTML5 forms, the implementation of 2D graphics, all these things will be the same on Chrome and Opera now. Same API, and low-level implementation. Since Opera is based on Chromium, you may feel that you are cutting back on your compatibility checks on Opera and Chrome.
I should also note that all Opera browserswill be transferred to Chromium. That is, Opera for Windows, Mac, Linux and Opera Mobile (full mobile browser). Even Opera Mini, the thin client, will be switched from the current rendering farm based on Presto to another based on Chromium.

... and the nightly build of WebKit. What is it?


This is the Mac port of WebKit, running on the same code as Safari (although some internal libraries have been changed). Basically, Apple leads it, so the behavior and feature set matches what you can find in Safari. In many cases, Apple behaves conservatively when it comes to enabling features that other ports implement or experiment with. In any case, if you use analogies, think ... WebKit nightly build for Safari, it's like Chromium for Chrome.
Chrome Canary also uses the latest WebKit source codes, a day ago or so.

Tell me more about WebKit internals.


Hold on.


Also popular now: