• Перевод

Для многих из нас, разработчиков, WebKit - черный ящик . Мы бросаем в него HTML, CSS, JS и кучу изображений, и WebKit, как-то… магически, выдает нам веб-страницу, которая выглядит и работает хорошо.
Но на самом деле, как говорит мой коллега Илья Григорик :

Веб-кит не является черным ящиком. Это - белый ящик. И не просто белый, но и открытый ящик.

Так-что, давайте попробуем разобраться в некоторых вещах:

• Что такое WebKit?
• Чем WebKit не является?
• Как WebKit используется WebKit-браузерами?
• Почему многие WebKit не одинаковые?

Теперь, особенно после новости, что Опера перешла на WebKit , нас окружает множество WebKit-браузеров, и достаточно сложно сказать, что их объединяет, а где они идут своим путем. Ниже, я надеюсь, мы постараемся пролить немного света на этот вопрос. В итоге, вы сможете лучше определять отличия браузера, отправлять баги в правильный трэкер, и вести кроссбраузерную разработку более эффективно.

Стандартные компоненты веб-браузера

Давайте перечислим несколько компонентов современных браузеров:

• Парсинг (Разбор HTML, XML, CSS, Javascript)
• Макет (Layout)
• Рендеринг текста и графики
• Декодировка изображений
• Взаимодействия с GPU
• Доступ к сети
• Аппаратное ускорение

Какие из них общие для всех WebKit браузеров? В значительной степени только первые два.

Остальные компоненты каждый WebKit «порт» реализует по своему. Давайте разберемся что это значит.

WebKit порты

Существует множество WebKit «портов», и я предоставляю Ария Хидаят, WebKit хакер и тех. директор в Sencha право рассказать об этом :

Самым популярной ассоциацией к понятию WebKit, обычно является вид WebKit от Apple"s, который работает на Mac OS X (первая и оригинальная WebKit библиотека). Как вы можете догадаться, различные интерфейсы реализованы, используя различные нативные библиотеки Mac OS X, в основном сосредоточенные в компоненте CoreFoundation . Например, если вы определяете цветную плоскую кнопку, с особым радиусом контура, WebKit знает где и как рисовать эту кнопку. В тоже время, окончательный рендеринг кнопки (в виде пикселей на мониторе пользователя) ложится на плечи CoreGraphics .

Как я упоминал выше, используемый CoreGraphics, уникален для каждого WebKit порта. Chrome для Mac, к примеру, использует Skia .

В какой-то момент, WebKit был «портирован» под разные платформы, как десктопные, так и мобильные. Такая вариация обычно называется «WebKit порт». Для Safari Windows, Apple также самостоятельно «портировала WebKit» для запуска под Windows, используя своей (с ограниченной реализацией) CoreFoundation библиотеки.

… не смотря на факт, что Safari под Windows теперь мертв .

Кроме этого, также было множество других «портов» (см. полный список). Google создал и продолжает поддерживать свой Chromium порт. Также существует WebKitGtk, основанный на Gtk+. Nokia (а теперь Trolltech, который перекупил его) поддерживает WebKit Qt порт, который стал популярен в качестве QtWebKit модуля .

Некоторые порты WebKit

• Safari
  - Safari под OS X и Safari под Windows два разных порта
  - Ночная сборка WebKit это сборка исходного кода Mac «порта», который используется для Safari, только новее
• Мобильный Safari
  - Развивался в приватной ветке, но позднее был открыт .
  - Chrome под iOS (использует Apple’s WebView; чуть позже о разнице)
• Chrome (Chromium)
  - Chrome под Android (использует непосредственно «порт» Chromium)
  - Chromium также является основой для браузеров: Yandex , , Sogou , и скоро, Opera.
• Android браузер
  - Использует последний исходный код WebKit, доступный на момент релиза.
• Еще большее количество портов : Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Разные порты могут фокусироваться на разных задачах. Фокус Mac порта - разделение между браузером и операционной системой, и предоставление биндигов Obj-C и С++ для встраивание рендеринг движка в нативные приложения. Фокус Chromium порта - всецело на браузере. QtWebKit предлагает свой порт использовать вместе со своей кросс-платформенной архитектурой приложений, в качестве движка для рендеринга.

Что общее во всех WebKit браузерах

Для начала давайте рассмотрим общие функции, которые используются во всех WebKit-браузерах:

Знаете это смешно, я сделал несколько попыток, чтобы написать этот абзац. И каждый раз члены команды Chrome поправляли меня, как вы увидите…

1. И так, во первых, WebKit разбирает HTML одинаково. Ну, за исключением того, что Chromium единственный порт, на данный момент, где включена поддержка потоков для разбора HTML .
2. … Хорошо, но после разбора HTML, DOM дерево конструируется одинаково. Ну, на самом деле Shadow DOM включен только для Chromium порта, тоесть построение DOM варьируется. Тоже для пользовательских элементов (custom elements).
3. … Хорошо, WebKit создает window и document объекты для всех одинаково. Правда, хотя свойства и конструкции которые они предоставляют, могут зависит от использования переключателей функций (feature flags).
4. … Разбор CSS одинаков. Поедание вашего CSS и преобразование его в CSSOM довольно таки стандартно. Ага, хотя Chrome поддерживает только -webkit- префиксы, когда Apple и другие браузеры поддерживают устаревшие префиксы -khtml- и -apple-.
5. … Макет… позиционирование? Это же как хлеб с маслом. Везде одинаково, правильно? Ну уже! Субпиксельный макет и насыщенная макетная арифметика является частью WebKit, но отличается от порта к порту.
6. Супер.

Так что, это сложно.

Теперь, давайте попробуем подвести итог, что общего в мире WebKit…

Что общего для каждого WebKit порта.

• DOM, window, document
  более или менее
• CSSOM
• Разбор CSS, свойство/значение
  различия в префиксах производителей
• Разбор HTML и построение DOM
  Одинаково, если мы забудем про Web Components.
• Макет и позиционирование
  Flexbox, Floats, block formating context… все общее
• Инструменты пользовательского интерфейса, и инструменты разработчика, типа Chrome DevTools он же WebKit inspector.
  Хотя с прошлого апреля, Safari использует свой собственный Safari инспектор, не-WebKit, с закрытыми исходниками.
• Такие функции как contenteditable, pushState, File API, большинство SVG, математика CSS трансформаций, Web Audio API, localStorage
  Хотя реализация может отличаться. Каждый порт может использовать свою собственную систему хранения для localStorage и может использовать разное audio API для Web Audio API.

Становится не совсем понятно, поэтому давайте попробуем взглянуть на некоторые различия.

Теперь, что не является общим для WebKit портов:

• Все связанное с GPU
  - 3D трансформации
  - WebGL
  - Декодирование видео
• Отрисовка 2D на экран
  - Технологии сглаживания
  - Рендеринг SVG и CSS градиентов
• Рендеринг текста и переносы
• Сетевые технологии (SPDY, пре-рендеринг, WebSocket транспорт)
• JavaScript движок
  - Движок JavaScriptCore лежит в репозитории WebKit. Но существуют биндинги в WebKit и для него, и для V8.
• Рендеринг элементов форм
• Поведение тэгов video и audio и поддержка кодеков
• Декодирование изображений
• Навигация назад/вперед
  - Часть pushState()
• SSL функции, такие как Strict Transport Security и Public Key Pins

Давайте взглянем на один из них: 2D графика зависит от порта, мы используем совершенно разные библиотеки для рендеринга на экран:

Или если вдаваться в подробности, недавно добавленная функция: CSS.supports() была включена для всех портов, за исключением win и wincairo, для которых не включены условные функции css3 (css3 conditional features).

Теперь, мы вдаемся в технические подробности… время стать педантичным. Даже сказанное выше не совсем корректно. На самом деле это WebCore, является общим компонентом. WebCore это макет, рендеринг, и DOM библиотека для HTML и SVG, и в основном то, что люди думают, когда они говорят WebKit. В самом деле «WebKit» технически - это слой биндингов между WebCore и «портами», хотя в обычной беседе это различие в основном не важно.

Диаграмма должна помочь:

Многие из компонентов WebKit переключаемые (показаны серыми).

Например, JavaScript движок WebKit, JavaScriptCore, является движком по-умолчанию в WebKit. Изначально он основан на KJS (от KDE) с дней, когда WebKit начинался как ответвление KHTML. В тоже время, Chromium порт, переключается на V8 движок и использует уникальные DOM биндинги.

Шрифты и рендеринг текста являются очень большой частью платформы. Существует 2 отдельных пути для текста в WebKit: Быстрый и Сложный. Оба требуют поддержку специфичную для платформы (реализованную на стороне порта), но Быстрый только должен знать как блитировать глифы (которые WebKit кэширует для платформы), когда Сложный полностью переносит рендеринг строк на уровень платформы и просто говорит «нарисуй это, пожалуйста».

«WebKit это как сэндвич. В прочем, в случае Chromium, это больше как тако. Вкусное тако из веб-технологий.
Dmitri Glazkov, Chrome WebKit hacker. Champion of Web Componets, and shadow dom.

Теперь, давайте расширим обзор, и посмотрим на несколько портов и несколько подсистем. Ниже представлены пять портов WebKit, обратите внимание, как различается набор инструментов для каждого из них, несмотря на общие компоненты:

	Chrome (OS X)	Safari (OS X)	QtWebKit	Android Browser	Chrome for iOS
Rendering	Skia	CoreGraphics	QtGui	Android stack/Skia	CoreGraphics
Networking	Chromium network stack	CFNetwork	QtNetwork	Fork of Chromium’s network stack	Chromium stack
Fonts	CoreText via Skia	CoreText	Qt internals	Android stack	CoreText
JavaScript	V8	JavaScriptCore	JSC (V8 is used elsewhere in Qt)	V8	JavaScriptCore (without JITting) *

* Сноска про Chrome для IOS. Он использует UIWebView, как вы вероятно знаете. В соответствии с возможностями UIWebView, это означает что он может использовать только такой же рендеринг движок, как и Мобильный Safari, JavaScriptCore (а не V8) и однопоточную модель. Тем неменее, некоторый код заимствован из Chromium, такой как подсистема для работы с сетью, синхронизация инфраструктура закладок, omnibox, метрики и отчеты о сбоях (crash reporting). (Также, JavaScript настолько редко является узким местом на мобильных устройствах, что отсутствие JITting компилятора имеет минимальное влияние.)

Хорошо, так к чему же мы пришли?

И так, все WebKit полностью различные теперь. Я напуган.

Не стоит! Покрытие WebKit тестами «layoutTest» огромное. (28,000 тестов по последним подсчетам), и не только для существующих функций, но также для всех найденных регрессий. На самом деле, когда бы вы не изучали новые или «тайные» функции DOM/CSS/HTML-5, наборы тестов «layoutTest» обычно имеют отличную минимальную демонстрацию.

В дополнении, W3C предпринимает усилия для стандартизации набора тестов . Это означает, что мы можем ожидать что и WebKit порты, и все другие браузеры будут тестироваться одинаковыми наборами тестов, что приведет нас к уменьшению quirks and a more interoperable web. Для всех тех, кто приложил свои усилия, посетив событие Test The Web Forward … спасибо вам!

Опера только что переехала на WebKit. Что из этого получится?

Роберт Найман и Роб Хоукс уже коснулись этой темы , но я добавлю что, одной из важной частью анонса было то, что Opera переходит на Chromium . Это означает, что WebGL, Canvas, HTML5 формы, имплементация 2D graphics, все эти вещи будут одинаковыми на Chrome и Opera теперь. Одинаковое API, и низкоуровневая реализация. Так как Opera основана на Chromium, вы можете ощущать, что вы сокращаете свою работу, по проверке совместимости на Opera и Chrome.
Я также должны обратить внимание, что все Opera браузеры будут переведены на Chromium. То есть, Opera для Windows, Mac, Linux и Opera Mobile (полноценный мобильный браузер). Даже Opera Mini, тонкий клиент, будет переключена с текущей рендеринг-фермы основанной на Presto, на другую, основанную на Chromium.

… и ночная сборка WebKit. Что это?

Это WebKit, работающий на том же коде что и Safari (хотя некоторые внутренние библиотеки были изменены). В основном Apple руководит им, так что поведение и набор функций соответствует тому, что вы сможете найти в Safari. Во многих случаях Apple ведет себя консервативно, когда речь заходит о включении функций, которые другие порты реализуют или с которыми ведут эксперементы. В любом случае, если использовать аналогии, думайте что… ночная сборка WebKit для Safari, это как Chromium для Chrome.

веб-браузеры

веб-разработка

Добавить метки

В этой статье мы рассмотрим три браузера на популярном движке WebKit. Когда идет речь о выборе веб-обозревателя, пользователи, как правило, смотрят в сторону самых известных программ: Google Chrome, Opera, Mozilla Firefox, Internet Explorer. При этом многие забывают или не знают о том, что тот же Firefox, Chrome и, с недавних пор, Opera созданы на базе проектов с открытым исходным кодом, а значит, эти программы можно модифицировать.

Эта возможность приводит к тому, что многие программисты создали несколько аналогов популярных браузеров, которые предлагают достаточно интересные возможности. Итак, рассмотрим несколько представителей подобного софта.

Распространяется бесплатно, имеет русский интерфейс, работает на Windows, Android , Mac, iOS. Этот браузер десять лет назад был известен под названием MyIE2 и являлся дополнением к Internet Explorer, но с тех пор многое поменялось и теперь программа использует по умолчанию движок Webkit.

В последней, 4-ой версии, браузер предлагает несколько полезных функций, среди которых самая интересная - возможность хранения информации в «облаке». Это позволяет с помощью учетной записи в программе передавать информацию между разными устройствами, будь-то Android-гаджет, продукт кампании Apple или стационарный ПК.

Интерфейс у Maxthon Cloud Browser хоть и выполнен в стиле Chrome, но имеет гораздо больше возможностей. На боковой панели отображаются значки для доступа к расширениям. Удобно, что одним щелчком мыши можно отключить или включить все установленные дополнения, а скачать новые можно с специального сайта.

Распространяется бесплатно, имеет русский интерфейс, работает на Windows. Продукт компании Comodo, которая более известна как разработчик защитного ПО. Comodo Dragon является более не разработкой, а сборкой, так как по функциональности он мало чем отличается от Chrome.

Отличий от оригинального браузера получилось не много, и все они касаются вопросов безопасности. Первое ключевое отличие от Google Chrome это действительно режим инкогнито, Comodo Dragon не использует уникальный идентификатор пользователя и HTTP-REFERRER что не позволяет отслеживать пользователя в сети.

Второе отличие заключается в ключевом виде деятельности Comodo - безопасности пользователя. Предполагает наличие собственных безопасных DNS-серверов для передачи трафика. Причём по желанию пользователя через них может идти трафик не только Dragon, но и всех остальных приложений. Безопасные DNS-сервера автоматически блокируют доступ к сайтам, которые были отмечены как ненадежные в собственной сети определения веб-угроз Comodo.

Распространяется бесплатно, имеет русский интерфейс, работает на Windows. «Яндекс.Браузер» - вышедший совсем недавно браузер основанный на Chromium от российской компании Яндекс. В этом продукте разработчики просто добавили сервисы «Яндекса» на панель быстрых ссылок. Также был добавлен и доработан режим «Турбо», который можно встретить в Opera. В целом получился не плохой браузер, нацеленный на пользователей Яндекс.

Браузерный движок – это специальная программа, которая работает с веб-страницами. Он обрабатывает загруженную из интернета HTML-страницу, и преобразует ее код в привычное для пользователей представление. Движки интернет-браузеров используются в самих браузерах, а также в почтовых клиентах. Далеко не каждый веб-обозреватель создан на своей собственной уникальной платформе. Многие из них используют популярные и проверенные временем решения. В данной статье рассматривается, какие существуют платформы для создания браузеров, и чем они отличаются друг от друга.

Использование движков (Rendering engine) для создания обозревателей имеет множество преимуществ:

• Облегчается поиск и устранение ошибок кода.
• Удобная возможность улучшить отдельный компонент сразу в нескольких программах.
• Облегчается процесс изменения графического интерфейса приложения.
• Простота создания новых программ под желания конкретного разработчика или нужны конкретного пользователя.

Подобные решения очень часто используются в программировании: при создании видеоигр, операционных систем сложных программ и так далее. Одни специалисты работают над совершенствованием и оптимизацией движка, внесением в него новых возможностей и полезных функций. Другие занимаются созданием самих программ на основе разработанной платформы.

Яркий пример – движок Trident от компании Microsoft. Он один используется в большом множестве приложений данной корпорации. Развивается основа – развиваются и производные проекты.

Каждое решением имеет свои плюсы и минусы. Например, многие пользователи замечают, что Mozilla Firefox гораздо лучше работает с большим количеством открытых вкладок, чем конкуренты. Это достижение платформы, на основе которой создан обозреватель.

Trident

Когда пользователь устанавливает новую операционную систему Windows, первый веб-обозреватель, с которым он сталкивается – это Internet Explorer. Поэтому его движок рассмотрен в обзоре первым.

Trident, или MSHTML – довольно старый программный компонент, разработанный корпорацией Microsoft для своих нужд. Проект непрерывно развивается с 1997 года. Используется в веб-обозревателе от Майкрософт – Internet Explorer, почтовом клиенте Outlook, Проводнике Виндовс (программа для работы с файлами) и множестве других приложений данного разработчика.

Пользователями считается одним из наиболее неудачных движков для браузеров. Не поддерживает сторонние модульные расширения – плагины, некорректно отображает многие интернет-страницы, имеет не самую быструю скорость работы.

С выходом Windows 10 платформа Trident эволюционировала в EdgeHTML.Разработчики взяли устаревший неудачный движок за основу и создали новую, отвечающий всем требованиям современным пользователей. Судя по проведенным бенчмаркам (программный тест производительности и скорости работы), Microsoft Edge (обозреватель, созданный на основе EdgeHTML) догнал и даже перегнал популярные программы, использованные для создания браузеров Google Chrome и Mozilla Firefox.

Gecko

Gecko – движок, используемый в популярном интернет-обозревателе Мозилла Фаерфокс и множестве других программ. Исходный код программы находится в свободном доступе, то есть каждый желающий может абсолютно бесплатно создать на основе Gecko свой собственный браузер или почтовый клиент.

Другое преимущество Геко – кроссплатформенность. Он работает на подавляющем большинстве современных операционных систем: как для персональных компьютеров, так и для мобильных устройств (в отличие от Internet Explorer, который функционирует только на ОС Windows).

Gecko поддерживает все современные стандарты и технологии, используемые при создании вебсайтов. Является одной из двух наиболее популярных браузерных платформ. Поддерживает подключение плагинов. Бенчмарки и личный опыт пользователей показывают, что браузеры на данном движке потребляют меньше всего ресурсов персонального компьютера и стабильно работают с большим количеством вкладок (например, несколько сотен).

На основе Геко создан популярный интернет-обозреватель Mozilla Firefox, почтовый клиент Thunderbird, планировщик задач Sunbird, а также анонимный веб-браузер с встроенной поддержкой VPN-технологий Tor.

KHTML

Не особо известная платформа, используемая для создания Konqueror — файлового менеджера среды KDE. Для пользователей, не знакомых с операционными системами семейства Linux, интересен тем, что на основе данного проекта создан самый популярный движок в мире, речь о котором пойдет дальше.

WebKit

Этот движок разработан всемирно известной корпорацией Apple на основе вышеупомянутого решения – KHTML. Выпущенный в 2001 году, этот проект получил колоссальное развитие и стал одним из самых используемых в мире.

На основе WebKit был создан веб-обозреватель Safari, используемый по умолчанию в iOS-устройствах и лидер по известности среди браузеров – Google Chrome. Подавляющее число современных программ для обработки содержимого веб-страниц имеют в своей основе ВебКит. Кроме того, он используется в популярном приложении Steam, предназначенном для цифровой дистрибуции компьютерных игр от компании Valve.

Аналогично с Gecko, WebKit является кроссплатформенным и отлично запускается на всех популярных платформах. Показывает высокую стабильность и производительность работы. Ввиду огромной известности, под данное решение разрабатывается подавляющее большинство расширений. Также используется в популярных мобильных платформах, таких как Android и iOS. Является свободным движком, то есть может быть бесплатно использован любым человеком для создания собственных приложений.

В 2013 году от WebKit отделилась новая ветка, принадлежащая корпорации Google – Blink. Этот проект лег в основу Chrome 28-й версии (и всех последующих), а также его собрата с открытым исходным кодом – Chromium. Chromium использован для создания популярного в России Yandex Browser. Начиная с 15-й версии на Blink перешел и браузер Opera.

Presto

Созданный в 2003 году, браузерный движок Presto использовался в качестве основы для Opera. Развивался на протяжении 10-ти лет. В 2013 разработчики Оперы решили отказаться от использования Presto в пользу более мощного и популярного Blink от Google. В данный момент развития проекта остановлено.

Статья была полезна?

Что такое Webkit?

На базе движка созданы такие браузеры, как Midori, Maxthon, Konqueror, Arora и другие. Но не только малоизвестные браузеры выбирают Webkit. Представляем вашему вниманию двух «гигантов» в мире браузеров – это Safari от Apple и Chrome от компании Google ( данные браузеры). Вряд ли кто-то станет утверждать, что эти браузеры мало функциональны и имеют низкую скорость работы. Помимо настольных браузеров, Webkit проник и на мобильные платформы, что в очередной раз подтверждает преимущества свободного ПО. Тот же Safari Mobile, разработанный для ОС iOS успешно использует данный движок. Так же на Webkit построены стандартные браузеры платформ Android, HP WebOS, а также Samsung Bada.

Представляет из себя движок, на базе которого разработано немало браузеров. Он является достаточно быстрым и легким, замечательно обрабатывает все стандарты, принятые в среде web.

При всем при этом данный движок является свободно распространяемым программным обеспечением. Вот эти слагаемые и позволили ему стать очень популярным среди разработчиков браузеров.

История Webkit

Возможно, вы задавались вопросом: «А почему – свободное ПО?» Давайте обратимся к истории его создания. Родителем Webkit также является свободно распространяемый движок, разработка которого ведется под графическую среду систем семейства Unix. Движок этот называется KDE. В далеком 98-м году команда программистов, работавших над KDE, решила выпустить свой браузер под эту графическую среду.

Такой браузер был выпущен и назван создателями Konqueror. Движок, лежавший в основе этого браузера получил название KHTML. Спустя 3 года, в 2001 г. корпорация Apple приняла решение создать свой браузер, для чего использовала исходники KHTML, а также JavaScript-движок KJS. В результате этого синтеза, уже под «крылом» Apple был создан проект Webkit. На его основе в начале 2003 года и была выпущена первая версия браузера от Apple – .

Еще один «монстр» в мире информационных технологий – компания Google – также взяла за основу Webkit при создании собственного браузера. А это еще один плюс в копилку достоинств движка. Раз уж в Google решили, что он им подходит, то это о многом говорит. Сами разработчики заявляли, что было принято решение не изобретать велосипед, ибо Webkit полностью удовлетворяет высоким требованиям компании по поддержке стандартов web-среды, а также довольно высокой скорости в работе.

Сегодня движок продолжает активно развиваться и имеет большие перспективы. Это и немудрено, ведь над его улучшением работает как Apple, так и Google. И это помимо официальных разработчиков движка. Те же, в свою очередь, заявили, что находятся в процессе работы, результатом которой станет выход второго поколения их продукта, отличительной особенностью которого будет встроенная архитектура раздельных процессов (на сегодня это реализовано только в ).

• Перевод

Для многих из нас, разработчиков, WebKit - черный ящик . Мы бросаем в него HTML, CSS, JS и кучу изображений, и WebKit, как-то… магически, выдает нам веб-страницу, которая выглядит и работает хорошо.
Но на самом деле, как говорит мой коллега Илья Григорик :

Веб-кит не является черным ящиком. Это - белый ящик. И не просто белый, но и открытый ящик.

Так-что, давайте попробуем разобраться в некоторых вещах:

• Что такое WebKit?
• Чем WebKit не является?
• Как WebKit используется WebKit-браузерами?
• Почему многие WebKit не одинаковые?

Теперь, особенно после новости, что Опера перешла на WebKit , нас окружает множество WebKit-браузеров, и достаточно сложно сказать, что их объединяет, а где они идут своим путем. Ниже, я надеюсь, мы постараемся пролить немного света на этот вопрос. В итоге, вы сможете лучше определять отличия браузера, отправлять баги в правильный трэкер, и вести кроссбраузерную разработку более эффективно.

Стандартные компоненты веб-браузера

Давайте перечислим несколько компонентов современных браузеров:

• Парсинг (Разбор HTML, XML, CSS, Javascript)
• Макет (Layout)
• Рендеринг текста и графики
• Декодировка изображений
• Взаимодействия с GPU
• Доступ к сети
• Аппаратное ускорение

Какие из них общие для всех WebKit браузеров? В значительной степени только первые два.

Остальные компоненты каждый WebKit «порт» реализует по своему. Давайте разберемся что это значит.

WebKit порты

Существует множество WebKit «портов», и я предоставляю Ария Хидаят, WebKit хакер и тех. директор в Sencha право рассказать об этом :

Самым популярной ассоциацией к понятию WebKit, обычно является вид WebKit от Apple"s, который работает на Mac OS X (первая и оригинальная WebKit библиотека). Как вы можете догадаться, различные интерфейсы реализованы, используя различные нативные библиотеки Mac OS X, в основном сосредоточенные в компоненте CoreFoundation . Например, если вы определяете цветную плоскую кнопку, с особым радиусом контура, WebKit знает где и как рисовать эту кнопку. В тоже время, окончательный рендеринг кнопки (в виде пикселей на мониторе пользователя) ложится на плечи CoreGraphics .

Как я упоминал выше, используемый CoreGraphics, уникален для каждого WebKit порта. Chrome для Mac, к примеру, использует Skia .

В какой-то момент, WebKit был «портирован» под разные платформы, как десктопные, так и мобильные. Такая вариация обычно называется «WebKit порт». Для Safari Windows, Apple также самостоятельно «портировала WebKit» для запуска под Windows, используя своей (с ограниченной реализацией) CoreFoundation библиотеки.

… не смотря на факт, что Safari под Windows теперь мертв .

Кроме этого, также было множество других «портов» (см. полный список). Google создал и продолжает поддерживать свой Chromium порт. Также существует WebKitGtk, основанный на Gtk+. Nokia (а теперь Trolltech, который перекупил его) поддерживает WebKit Qt порт, который стал популярен в качестве QtWebKit модуля .

Некоторые порты WebKit

• Safari
  - Safari под OS X и Safari под Windows два разных порта
  - Ночная сборка WebKit это сборка исходного кода Mac «порта», который используется для Safari, только новее
• Мобильный Safari
  - Развивался в приватной ветке, но позднее был открыт .
  - Chrome под iOS (использует Apple’s WebView; чуть позже о разнице)
• Chrome (Chromium)
  - Chrome под Android (использует непосредственно «порт» Chromium)
  - Chromium также является основой для браузеров: Yandex , , Sogou , и скоро, Opera.
• Android браузер
  - Использует последний исходный код WebKit, доступный на момент релиза.
• Еще большее количество портов : Amazon Silk, Dolphin, Blackberry, QtWebKit, WebKitGTK+, The EFL port (Tizen), wxWebKit, WebKitWinCE, etc

Разные порты могут фокусироваться на разных задачах. Фокус Mac порта - разделение между браузером и операционной системой, и предоставление биндигов Obj-C и С++ для встраивание рендеринг движка в нативные приложения. Фокус Chromium порта - всецело на браузере. QtWebKit предлагает свой порт использовать вместе со своей кросс-платформенной архитектурой приложений, в качестве движка для рендеринга.

Что общее во всех WebKit браузерах

Для начала давайте рассмотрим общие функции, которые используются во всех WebKit-браузерах:

Знаете это смешно, я сделал несколько попыток, чтобы написать этот абзац. И каждый раз члены команды Chrome поправляли меня, как вы увидите…

1. И так, во первых, WebKit разбирает HTML одинаково. Ну, за исключением того, что Chromium единственный порт, на данный момент, где включена поддержка потоков для разбора HTML .
2. … Хорошо, но после разбора HTML, DOM дерево конструируется одинаково. Ну, на самом деле Shadow DOM включен только для Chromium порта, тоесть построение DOM варьируется. Тоже для пользовательских элементов (custom elements).
3. … Хорошо, WebKit создает window и document объекты для всех одинаково. Правда, хотя свойства и конструкции которые они предоставляют, могут зависит от использования переключателей функций (feature flags).
4. … Разбор CSS одинаков. Поедание вашего CSS и преобразование его в CSSOM довольно таки стандартно. Ага, хотя Chrome поддерживает только -webkit- префиксы, когда Apple и другие браузеры поддерживают устаревшие префиксы -khtml- и -apple-.
5. … Макет… позиционирование? Это же как хлеб с маслом. Везде одинаково, правильно? Ну уже! Субпиксельный макет и насыщенная макетная арифметика является частью WebKit, но отличается от порта к порту.
6. Супер.

Так что, это сложно.

Теперь, давайте попробуем подвести итог, что общего в мире WebKit…

Что общего для каждого WebKit порта.

• DOM, window, document
  более или менее
• CSSOM
• Разбор CSS, свойство/значение
  различия в префиксах производителей
• Разбор HTML и построение DOM
  Одинаково, если мы забудем про Web Components.
• Макет и позиционирование
  Flexbox, Floats, block formating context… все общее
• Инструменты пользовательского интерфейса, и инструменты разработчика, типа Chrome DevTools он же WebKit inspector.
  Хотя с прошлого апреля, Safari использует свой собственный Safari инспектор, не-WebKit, с закрытыми исходниками.
• Такие функции как contenteditable, pushState, File API, большинство SVG, математика CSS трансформаций, Web Audio API, localStorage
  Хотя реализация может отличаться. Каждый порт может использовать свою собственную систему хранения для localStorage и может использовать разное audio API для Web Audio API.

Становится не совсем понятно, поэтому давайте попробуем взглянуть на некоторые различия.

Теперь, что не является общим для WebKit портов:

• Все связанное с GPU
  - 3D трансформации
  - WebGL
  - Декодирование видео
• Отрисовка 2D на экран
  - Технологии сглаживания
  - Рендеринг SVG и CSS градиентов
• Рендеринг текста и переносы
• Сетевые технологии (SPDY, пре-рендеринг, WebSocket транспорт)
• JavaScript движок
  - Движок JavaScriptCore лежит в репозитории WebKit. Но существуют биндинги в WebKit и для него, и для V8.
• Рендеринг элементов форм
• Поведение тэгов video и audio и поддержка кодеков
• Декодирование изображений
• Навигация назад/вперед
  - Часть pushState()
• SSL функции, такие как Strict Transport Security и Public Key Pins

Давайте взглянем на один из них: 2D графика зависит от порта, мы используем совершенно разные библиотеки для рендеринга на экран:

Или если вдаваться в подробности, недавно добавленная функция: CSS.supports() была включена для всех портов, за исключением win и wincairo, для которых не включены условные функции css3 (css3 conditional features).

Теперь, мы вдаемся в технические подробности… время стать педантичным. Даже сказанное выше не совсем корректно. На самом деле это WebCore, является общим компонентом. WebCore это макет, рендеринг, и DOM библиотека для HTML и SVG, и в основном то, что люди думают, когда они говорят WebKit. В самом деле «WebKit» технически - это слой биндингов между WebCore и «портами», хотя в обычной беседе это различие в основном не важно.

Диаграмма должна помочь:

Многие из компонентов WebKit переключаемые (показаны серыми).

Например, JavaScript движок WebKit, JavaScriptCore, является движком по-умолчанию в WebKit. Изначально он основан на KJS (от KDE) с дней, когда WebKit начинался как ответвление KHTML. В тоже время, Chromium порт, переключается на V8 движок и использует уникальные DOM биндинги.

Шрифты и рендеринг текста являются очень большой частью платформы. Существует 2 отдельных пути для текста в WebKit: Быстрый и Сложный. Оба требуют поддержку специфичную для платформы (реализованную на стороне порта), но Быстрый только должен знать как блитировать глифы (которые WebKit кэширует для платформы), когда Сложный полностью переносит рендеринг строк на уровень платформы и просто говорит «нарисуй это, пожалуйста».

«WebKit это как сэндвич. В прочем, в случае Chromium, это больше как тако. Вкусное тако из веб-технологий.
Dmitri Glazkov, Chrome WebKit hacker. Champion of Web Componets, and shadow dom.

Теперь, давайте расширим обзор, и посмотрим на несколько портов и несколько подсистем. Ниже представлены пять портов WebKit, обратите внимание, как различается набор инструментов для каждого из них, несмотря на общие компоненты:

	Chrome (OS X)	Safari (OS X)	QtWebKit	Android Browser	Chrome for iOS
Rendering	Skia	CoreGraphics	QtGui	Android stack/Skia	CoreGraphics
Networking	Chromium network stack	CFNetwork	QtNetwork	Fork of Chromium’s network stack	Chromium stack
Fonts	CoreText via Skia	CoreText	Qt internals	Android stack	CoreText
JavaScript	V8	JavaScriptCore	JSC (V8 is used elsewhere in Qt)	V8	JavaScriptCore (without JITting) *

* Сноска про Chrome для IOS. Он использует UIWebView, как вы вероятно знаете. В соответствии с возможностями UIWebView, это означает что он может использовать только такой же рендеринг движок, как и Мобильный Safari, JavaScriptCore (а не V8) и однопоточную модель. Тем неменее, некоторый код заимствован из Chromium, такой как подсистема для работы с сетью, синхронизация инфраструктура закладок, omnibox, метрики и отчеты о сбоях (crash reporting). (Также, JavaScript настолько редко является узким местом на мобильных устройствах, что отсутствие JITting компилятора имеет минимальное влияние.)

Хорошо, так к чему же мы пришли?

И так, все WebKit полностью различные теперь. Я напуган.

Не стоит! Покрытие WebKit тестами «layoutTest» огромное. (28,000 тестов по последним подсчетам), и не только для существующих функций, но также для всех найденных регрессий. На самом деле, когда бы вы не изучали новые или «тайные» функции DOM/CSS/HTML-5, наборы тестов «layoutTest» обычно имеют отличную минимальную демонстрацию.

В дополнении, W3C предпринимает усилия для стандартизации набора тестов . Это означает, что мы можем ожидать что и WebKit порты, и все другие браузеры будут тестироваться одинаковыми наборами тестов, что приведет нас к уменьшению quirks and a more interoperable web. Для всех тех, кто приложил свои усилия, посетив событие Test The Web Forward … спасибо вам!

Опера только что переехала на WebKit. Что из этого получится?

Роберт Найман и Роб Хоукс уже коснулись этой темы , но я добавлю что, одной из важной частью анонса было то, что Opera переходит на Chromium . Это означает, что WebGL, Canvas, HTML5 формы, имплементация 2D graphics, все эти вещи будут одинаковыми на Chrome и Opera теперь. Одинаковое API, и низкоуровневая реализация. Так как Opera основана на Chromium, вы можете ощущать, что вы сокращаете свою работу, по проверке совместимости на Opera и Chrome.
Я также должны обратить внимание, что все Opera браузеры будут переведены на Chromium. То есть, Opera для Windows, Mac, Linux и Opera Mobile (полноценный мобильный браузер). Даже Opera Mini, тонкий клиент, будет переключена с текущей рендеринг-фермы основанной на Presto, на другую, основанную на Chromium.

… и ночная сборка WebKit. Что это?

Это WebKit, работающий на том же коде что и Safari (хотя некоторые внутренние библиотеки были изменены). В основном Apple руководит им, так что поведение и набор функций соответствует тому, что вы сможете найти в Safari. Во многих случаях Apple ведет себя консервативно, когда речь заходит о включении функций, которые другие порты реализуют или с которыми ведут эксперементы. В любом случае, если использовать аналогии, думайте что… ночная сборка WebKit для Safari, это как Chromium для Chrome. Добавить метки