WebKit

Split development

The exchange of code between WebCore and KHTML became increasingly difficult as the code bases diverged, because both projects used different coding approaches and had different approaches to code sharing.^[22] At one point KHTML developers said they were unlikely to accept Apple's changes and claimed the relationship between the two groups was a "bitter failure".^[23] They claimed Apple submitted their changes in large patches containing multiple changes with inadequate documentation, often in relation to future additions to the codebase. Thus, these patches were difficult for the KDE developers to integrate back into KHTML.^[24] Also, Apple had demanded that developers sign non-disclosure agreements before looking at Apple's source code, and even then, they were unable to access Apple's bug database.^[25]

During the publicized "divorce" period, KDE developer Kurt Pfeifle (pipitas) posted an article claiming KHTML developers had managed to backport many (but not all) Safari improvements from WebCore to KHTML, and they always appreciated the improvements coming from Apple and still do so. The article also noted that Apple had begun contacting KHTML developers to discuss improving the relationship and future cooperation.^[26] In fact, the KDE project was able to incorporate some of these changes to improve KHTML's rendering speed and add features, including compliance with the Acid2 rendering test.^[27]

Following the appearance of a story of the fork in the news, Apple released the source code of the WebKit fork in a public revision-control repository.^[28]

The WebKit team also reversed many Apple-specific changes in the original WebKit codebase and implemented platform-specific abstraction layers, making it significantly easier to commit the core rendering code to other platforms.^[29]

In July 2007, Ars Technica reported that the KDE team would move from KHTML to WebKit.^[30] Instead, after several years of integration, KDE Development Platform version 4.5.0 was released in August 2010 with support for both WebKit and KHTML, and development of KHTML continued until 2016 before it was officially discontinued in 2023.^[31][32]

Open-sourcing

On June 7, 2005, Safari developer Dave Hyatt announced on his weblog that Apple was open-sourcing WebKit (formerly, only WebCore and JavaScriptCore were open source) and opening up access to WebKit's revision control tree and the issue tracker.^[28]

In mid-December 2005, support for Scalable Vector Graphics (SVG) was merged into the standard build.^[33]

WebKit's JavaScriptCore and WebCore components are available under the GNU Lesser General Public License, while the rest of WebKit is available under the BSD 2-Clause license.^[8]

Further development

This section needs to be updated. Please help update this article to reflect recent events or newly available information. (July 2015)

Beginning in early 2007, the development team began to implement Cascading Style Sheets (CSS) extensions, including animation, transitions and both 2D and 3D transforms;^[34] such extensions were released as working drafts to the World Wide Web Consortium (W3C) in 2009 for standardization.^[35]

In November 2007, the project announced that it had added support for media features of the HTML5 draft specification, allowing embedded video to be natively rendered and script-controlled in WebKit.^[36]

On June 2, 2008, the WebKit project announced that they had rewritten JavaScriptCore as "SquirrelFish", a bytecode interpreter.^[37][38] The project evolved into SquirrelFish Extreme (abbreviated SFX), announced on September 18, 2008, which compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution.^[39] Initially, the only supported processor architecture for SFX was the x86, but at the end of January 2009, SFX was enabled for macOS on x86-64 as it passes all tests on that platform.^[40]

WebKit2

On April 8, 2010, a project named WebKit2 was announced to redesign WebKit. Its goal was to abstract the components that provide page layout and rendering cleanly from their surrounding interface or application shell, creating a situation where "web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI". This abstraction was intended to make reuse in WebKit2 simpler than in WebKit. WebKit2 had "an incompatible API change from the original WebKit", which motivated its name change.^[41]

The WebKit2 targets were set to Linux, macOS, Windows, GTK, and MeeGo-Harmattan.^[42][43] Safari for macOS switched to the new API with version 5.1.^[44] Safari for iOS switched to WebKit2 with iOS 8.^[45]

The original WebKit API has been renamed WebKitLegacy API.^[46] WebKit2 API has been renamed just plain WebKit API.^[47]

Installed base

New web browsers have been built around WebKit such as the S60 browser^[50] on Symbian mobile phones, BlackBerry Browser (ver 6.0+), Midori, Chrome browser,^[51][52] the Android Web browsers before version 4.4 KitKat, and the browser used in PlayStation 3 system software from version 4.10.^{[53][unreliable source?]} KDE's Rekonq web browser and Plasma Workspaces also use it as the native web rendering engine. WebKit has been adopted as the rendering engine in OmniWeb, iCab, Web (formerly named Epiphany), and Sleipnir, replacing their original rendering engines. GNOME's Web supported both Gecko and WebKit for some time. Still, the team decided that Gecko's release cycle and future development plans would make it too cumbersome to continue supporting it.^[54] webOS uses WebKit as the basis of its application runtime.^[55] WebKit is used to render HTML and run JavaScript in the Adobe Integrated Runtime application platform. In Adobe Creative Suite CS5, WebKit is used to render some parts of the user interface. By the first half of 2010, an analyst estimated that 350 million mobile handsets had shipped with a WebKit-based browser.^[56] By mid-April 2015, WebKit browser market share was 50.3%.^[57]

Ports

The week after Hyatt announced WebKit's open sourcing, Nokia announced that it had ported WebKit to Symbian and was developing a WebKit-based browser for mobile phones running S60. Named Web Browser for S60, it was used on Nokia, Samsung, LG, and other Symbian S60 mobile phones. Apple has also ported WebKit to iOS for the iPhone, iPod Touch, and iPad, where it is used to render content in the device's web browser and e-mail software.^[58] The Android mobile phone platform used WebKit (and later versions its Blink fork) as the basis of its web browser^[59][60][61] and the Palm Pre, announced January 2009, has an interface based on WebKit.^[62] The Amazon Kindle 3 includes an experimental WebKit based browser.^[63]

In June 2007, Apple announced that WebKit had been ported to Microsoft Windows as part of Safari. Although the company silently discontinued Safari for Windows,^[64] WebKit's ports to Microsoft's operating system are still actively maintained.^[65][66] The Windows port uses Apple's proprietary libraries to function and is used for iCloud^[67] and iTunes^[68] for Windows, whereas the "WinCairo" port is a fully open-source and redistributable port.^[69][70]

WebKit has also been ported to several toolkits that support multiple platforms, such as the GTK toolkit for Linux, under the name WebKitGTK which is used by Eolie,^{[71][full citation needed]} GNOME Web,^[72][73] Adobe Integrated Runtime, Enlightenment Foundation Libraries (EFL), and the Clutter toolkit.^[74] Qt Software included a WebKit port in the Qt 4.4 release as a module called QtWebKit^[75] (since superseded by Qt WebEngine, which uses Blink instead). The Iris Browser on Qt also used WebKit. The Enlightenment Foundation Libraries (EFL) port – EWebKit – was developed (by Samsung and ProFusion^[76]) focusing the embedded and mobile systems, for use as stand alone browser, widgets-gadgets, rich text viewer and composer.^{[citation needed]} The Clutter port is developed by Collabora and sponsored by Robert Bosch GmbH.

There was also a project synchronized with WebKit (sponsored by Pleyo)^{[77][not specific enough to verify]} called Origyn Web Browser, which provided a meta-port to an abstract platform to make porting to embedded or lightweight systems quicker and easier.^[78] This port is used for embedded devices such as set-top boxes and PMP^{[further explanation needed]} and it has been ported into AmigaOS,^[79] AROS,^[80] and MorphOS. MorphOS version 1.7 is the first version of Origyn Web Browser (OWB) supporting HTML5 media tags.^[81][82]

Forking by Google

On April 3, 2013, Google announced that it would produce a fork of WebKit's WebCore component, to be named Blink. Chrome's developers decided to fork WebCore to allow greater freedom in implementing its features in the browser without causing conflicts upstream, and to simplify its codebase by removing code for WebCore components unused by Chrome. In relation to Opera Software's announcement earlier in the year that it would switch to WebKit by means of the Chromium codebase, it was confirmed that the Opera web browser would also switch to Blink.^[48] Following the announcement, WebKit developers began discussions on removing Chrome-specific code from the engine to streamline its codebase.^[83] WebKit no longer has any Chrome specific code (e.g., buildsystem, V8 JavaScript engine hooks, platform code, etc.).^{[citation needed]}

WebCore

WebCore is a layout, rendering, and Document Object Model (DOM) library for HTML and Scalable Vector Graphics (SVG), developed by the WebKit project. Its full source code is licensed under the GNU Lesser General Public License (LGPL). The WebKit framework wraps WebCore and JavaScriptCore, providing an Objective-C application programming interface to the C++-based WebCore rendering engine and JavaScriptCore script engine, allowing it to be easily referenced by applications based on the Cocoa API; later versions also include a cross-platform C++ platform abstraction, and various ports provide more APIs.^{[citation needed]}

WebKit passes the Acid2 and Acid3 tests, with pixel-perfect rendering and no timing or smoothness issues on reference hardware.^[84]

JavaScriptCore

JavaScriptCore is a framework that provides a JavaScript engine for WebKit implementations, and provides this type of scripting in other contexts within macOS.^[20][85] JavaScriptCore is originally derived from KDE's JavaScript library KJS (which is part of the KDE project) and the PCRE regular expression library. Since forking from KJS and PCRE, JavaScriptCore has added many new features^{[example needed]} and greatly improved performance.^[86]

On June 2, 2008, the WebKit project announced they rewrote JavaScriptCore as "SquirrelFish",^[37][38] a register-based bytecode interpreter replacing the original AST-walking interpreter. The project later evolved into SquirrelFish Extreme (abbreviated SFX, marketed as Nitro), announced on September 18, 2008, further speeding up JavaScript execution by introducing Just-in-time compilation.^[39]

An optimizing just-in-time (JIT) compiler named FTL was announced on May 13, 2014.^[87] It uses LLVM to generate optimized machine code. "FTL" stands for "Fourth-Tier-LLVM", and unofficially for faster-than-light, alluding to its speed.^[88] As of February 15, 2016, the backend of FTL JIT is replaced by "Bare Bones Backend" (or B3 for short).^[89]