WebKit для разработчиков
Для многих из нас, разработчиков, WebKit — черный ящик. Мы бросаем в него HTML, CSS, JS и кучу изображений, и 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, используя Windows версию своей (с ограниченной реализацией) CoreFoundation библиотеки.
… не смотря на факт, что Safari под Windows теперь мертв.
Кроме этого, также было множество других «портов» (см. полный список). Google создал и продолжает поддерживать свой Chromium порт. Также существует WebKitGtk, основанный на Gtk+. Nokia (а теперь Trolltech, который перекупил его) поддерживает WebKit Qt порт, который стал популярен в качестве QtWebKit модуля.
Некоторые порты WebKit
Что общее во всех WebKit браузерах
Для начала давайте рассмотрим общие функции, которые используются во всех WebKit-браузерах:
Знаете это смешно, я сделал несколько попыток, чтобы написать этот абзац. И каждый раз члены команды Chrome поправляли меня, как вы увидите…
Так что, это сложно.
Точно также как Flickr и Github прячут реализованные функции за специальными флагами, WebKit делает тоже самое. Это позволяет портам включать/выключать любую функциональность на стадии компиляции с помощью WebKit compile-time Feature Flags. Функции также могут быть включены в режиме работы, с помощью параметров в командной строке (для Chromium) или конфигураций, таких как about:flags.
Теперь, давайте попробуем подвести итог, что общего в мире WebKit…
Что общего для каждого WebKit порта.
Теперь, что не является общим для WebKit портов:
Или если вдаваться в подробности, недавно добавленная функция: 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. Что это?
Это mac порт WebKit, работающий на том же коде что и Safari (хотя некоторые внутренние библиотеки были изменены). В основном Apple руководит им, так что поведение и набор функций соответствует тому, что вы сможете найти в Safari. Во многих случаях Apple ведет себя консервативно, когда речь заходит о включении функций, которые другие порты реализуют или с которыми ведут эксперементы. В любом случае, если использовать аналогии, думайте что… ночная сборка WebKit для Safari, это как Chromium для Chrome.
Chrome Canary также использует последние исходные коды WebKit, однодневной давности или около того.
WebKit
Apple Inc., Google Inc., команда разработчиков KDE и другие.
WebKit — свободный движок для отображения веб-страниц, разработанный на основе кода библиотек KHTML и KJS, используемых в графической среде KDE.
Исходный код открыт на условиях LGPL, то есть любой из компонентов или все компоненты сразу, в неизменном или измененном виде, можно использовать в проектах любого назначения (в том числе коммерческих) с одним условием: библиотеки или их производные должны быть опубликованы с открытым исходным кодом на условиях лицензии LGPL. WebKit входит в состав «публичных» фреймворков (динамических библиотек особой структуры), поставляющихся с каждой копией Mac OS X с июня 2003 года.
На данный момент осуществляет наиболее полную поддержку HTML в соответствии с рекомендациями W3C.
Содержание
История
В ноябре 2000 года на сайте Apple в разделе «Требуются» появилось несколько вакансий. От соискателей требовалось хорошее владение Интернет-технологиями, опыт разработки web-движков и тому подобные качества. Иными словами, в конце 2000 года было принято решение о разработке собственного браузера. Изучив доступные варианты, инженеры компании остановили свой выбор на движке с открытым исходным кодом KHTML/KJS, который, по их мнению, был лучшим.
В 2001 году инженеры Apple создали собственную ветку проекта KHTML и KJS, переименовали свой вариант библиотек в WebCore и JavaScriptCore и, сохранив все достоинства оригинала, полностью их переписали.
В январе 2003 года на Macworld Expo Стив Джобс анонсировал веб-браузер Safari, разработанный на основе WebKit.
В апреле 2008 года команда разработчиков веб-браузера Epiphany для среды GNOME заявила [1] о том, что собирается использовать в своем браузере исключительно WebKit, тем самым отказываясь от поддержки движка Gecko, разрабатываемого Mozilla Foundation.
В мае 2010 года компания Apple Inc. подала [2] в профильное ведомство США заявку на регистрацию торговой марки WebKit. В случае утверждения заявки только Apple Inc. будет вправе использовать название WebKit в своих продуктах, а остальным придется использовать другое название для браузерного движка. [источник не указан 62 дня]
Компоненты
WebCore
Отображение и библиотека Document Object Model (DOM) для HTML и SVG.
JavaScriptCore
JavaScriptCore — движок JavaScript. Также здесь находится библиотека WTF (Web Template Framework), предоставляющая вспомогательные функции общего назначения для всего WebKit. JavaScriptCore является кроссплатформенным и может использоваться как отдельный компонент без зависимостей от других компонентов WebKit.
В новых версиях WebKit Apple заменит JavaScriptCore более современным и быстрым SquirrelFish.
Drosera
Отладчик ошибок, входящий в состав ночных сборок WebKit.
СОДЕРЖАНИЕ
Происхождение
Раздельное развитие
Обмен кодом между WebCore и KHTML становился все труднее, поскольку кодовая база расходилась, поскольку в обоих проектах использовались разные подходы к кодированию и совместному использованию кода. В какой-то момент разработчики KHTML заявили, что они вряд ли примут изменения Apple, и заявили, что отношения между двумя группами были «горьким провалом». Apple представила свои изменения большими патчами, содержащими очень много изменений с неадекватной документацией, часто связанной с будущими дополнениями. Таким образом, разработчикам KDE было сложно интегрировать эти исправления обратно в KHTML. Кроме того, Apple потребовала, чтобы разработчики подписали соглашения о неразглашении, прежде чем просматривать исходный код Apple, и даже тогда они не могли получить доступ к базе данных ошибок Apple.
Команда WebKit также отменила многие специфические для Apple изменения в исходной кодовой базе WebKit и реализовала уровни абстракции для конкретной платформы, чтобы значительно упростить передачу основного кода рендеринга на другие платформы.
В июле 2007 года Ars Technica сообщила, что команда KDE перейдет с KHTML на WebKit. Вместо этого после нескольких лет интеграции в августе 2010 года была выпущена KDE Development Platform версии 4.5.0 с поддержкой как WebKit, так и KHTML, и разработка KHTML продолжается.
Открытый исходный код
7 июня 2005 года разработчик Safari Дэйв Хаятт объявил в своем блоге, что Apple открыла исходный код WebKit (ранее только WebCore и JavaScriptCore были с открытым исходным кодом) и открыла доступ к дереву контроля версий WebKit и системе отслеживания проблем.
В середине декабря 2005 года поддержка масштабируемой векторной графики (SVG) была включена в стандартную сборку.
Компоненты WebKit JavaScriptCore и WebCore доступны по лицензии GNU Lesser General Public License, а остальная часть WebKit доступна по лицензии BSD 2-Clause.
Дальнейшее развитие
WebKit2
8 апреля 2010 года было объявлено о проекте под названием WebKit2 по редизайну WebKit. Его цель состояла в том, чтобы полностью абстрагировать компоненты, обеспечивающие веб-рендеринг, от окружающего их интерфейса или оболочки приложения, создавая ситуацию, когда «веб-контент (JavaScript, HTML, макет и т. Д.) Находится в отдельном процессе от пользовательского интерфейса приложения». Эта абстракция была предназначена для того, чтобы сделать повторное использование более простым процессом для WebKit2, чем для WebKit. В WebKit2 было «несовместимое изменение API по сравнению с исходным WebKit», что и послужило причиной изменения его названия.
Исходный API WebKit был переименован в API WebKitLegacy. WebKit2 API был переименован в простой WebKit API.
Использовать
Установленная база
Порты
В июне 2007 года Apple объявила, что WebKit был перенесен на Microsoft Windows как часть Safari. Хотя Safari для Windows был прекращен компанией, порты WebKit на операционную систему Microsoft все еще активно поддерживаются. Порт Windows использует собственные библиотеки Apple для работы и используется для iCloud и iTunes для Windows, тогда как порт «WinCairo» является полностью распространяемым портом с открытым исходным кодом.
Веб-платформа для встроенных
Форкинг от Google
Компоненты
WebCore
WebCore это макет, рендеринг и Объектная модель документа (DOM) библиотека для HTML и Scalable Vector Graphics (SVG), разработанный в рамках проекта WebKit. Его полный исходный код находится под лицензией GNU Lesser General Public License (LGPL). Инфраструктура WebKit включает WebCore и JavaScriptCore, обеспечивая интерфейс прикладного программирования Objective-C для основанного на C ++ механизма рендеринга WebCore и скриптового движка JavaScriptCore, что позволяет легко ссылаться на него приложениям, основанным на Cocoa API ; более поздние версии также включают кроссплатформенную абстракцию платформы C ++, а различные порты предоставляют больше API.
WebKit проходит тесты Acid2 и Acid3 с точным отображением пикселей и отсутствием проблем с синхронизацией или плавностью на эталонном оборудовании.
JavaScriptCore
Инженер Google рассказал, почему на iOS нет нормальных браузеров
Большинство пользователей iOS искренне считают Safari самым лучшим браузером для iPhone. Он удобен, интуитивно понятен и, что самое главное, очень экономичен и быстр. В отличие от Google Chrome, Safari расходует меньше оперативной памяти, а работает при этом быстрее. Что и говорить о нагрузке на процессор, который при работе с Safari явно тратит меньше ресурсов и не разогревается как доменная печь. В общем, если у вас iPhone, то ваш выбор – это Safari. Но в Google считают, что Apple просто пускает пыль в глаза, а на iOS вообще нет нормальных браузеров.
Safari быстр и интуитивен, но недостаточно производителен и функционален
По словам Алекса Рассела, инженера-программиста из команды разработки Google Chrome, браузеры под iOS уникально непроизводительны и нефункциональны. Им недостаёт вычислительных способностей, из-за чего они не в состоянии реализовать весь потенциал веб-приложений, которые сегодня вполне могли бы заменить собой нативные. Поэтому, утверждает Рассел, заявление Тима Кука о том, что пользователи iOS могут выбирать между софтом из App Store и PWA, не соответствует действительности.
Чем WebKit хуже Chromium
Все проблемы браузеров на iOS — от WebKit
Основная проблема браузеров на iOS заключается в том, что они все работают на базе движка WebKit. Даже Google Chrome, который в классическом исполнении написан на Chromium, на iOS использует собственный движок Apple. Просто в Купертино не оставляют разработчикам других возможностей, требуя, чтобы они писали свои браузеры на WebKit. А этот движок сильно ограничивает их в развитии, не позволяя развиваться должным образом и идти в ногу со временем.
Вот какие проблемы есть у WebKit:
Недостатки PWA на iOS
Даже Google Chrome на iOS работает на WebKit
Рассел уверяет, что Apple намеренно ограничивает совместимость WebKit с прогрессивными веб-приложениями, чтобы пользователи не могли рассматривать их в качестве альтернативы традиционному ПО. На это прямо указывает несколько факторов:
По большому счёту разработчик всё говорит по делу. Да, кое-где он чрезмерно драматизирует, например, как в случае с производительностью WebKit. Однако почти все его претензии к совместимости PWA с WebKit и iOS в целом довольно адекватны. Ведь Apple, в отличие от Google, даже не пытается вывести прогрессивные веб-приложения в легальное поле.
iOS не предлагает ни кнопок установки, как Android, где сразу видно, что это нормальное приложение, пусть и работающее на мощностях браузера, ни доступа ко многим системным функциям и аппаратным компонентам устройства. В результате пользоваться PWA на iOS становится в лучшем случае затруднительно.
Но главный недостаток браузеров на iOS – это отсутствие поддержки сторонних движков. Понятное дело, для чего Apple изначально установила это ограничение. Она хотела добиться высокой производительности, и добилась её. Однако теперь, когда всем кругом мерещатся монополии, Apple явно нужно отказаться от этого принципа и разрешить на iOS работу сторонних движков.
Что такое WebKit и как это связано с CSS?
в последнее время я вижу вопросы с тегом «webkit». Такие вопросы, как правило, веб-вопросы, связанные с CSS, jQuery, макеты, кросс-браузеры вопросы совместимости и т.д.
обновление
Итак, из ответов до сих пор. В WebKit представляет собой HTML/веб-УСБ механизм рендеринга браузера для Safari / Chrome. Существуют ли такие движки для IE/Opera / Firefox и каковы различия, плюсы и минусы использования одного над другим? Могу ли я использовать функции WebKit в Firefox, например?
главный вопрос. Поддерживается ли webkit IE?
обновление 2
все основные браузеры используют разные движки. Я думаю, это большая причина, почему существует так много кросс-браузер проблемы совместимости!
Итак, есть какой-то проект или движение к стандартному движку рендеринга, который будут использовать все браузеры? Будет ли HTML5 положить конец проблемам совместимости между браузерами?
14 ответов
Update: по-видимому, WebKit-это движок рендеринга веб-браузера HTML/CSS для Safari/Chrome. Существуют ли такие движки для IE/Opera / Firefox и каковы различия, плюсы и минусы использования одного над другим? Могу ли я использовать функции WebKit в Firefox, например?
каждый браузер поддерживается движком рендеринга для рисования веб-страницы HTML/CSS.
посмотреть сравнение движков веб-браузера в список сравнений в разных области.
главный вопрос. поддерживается ли webkit IE?
дополнение к тому, что @KennyTM сказал:
1) 12 февраля 2013 Opera (версия 15+)объявляет они отходят от собственного движка Presto к WebKit с именем Блинк.
2) В Апреле 3 2013 Google (Chrome версии 28+)объявляет они собираются использовать WebKit-based Блинк двигатель.
Webkit-это движок рендеринга веб-браузера, используемый Safari и Chrome (среди прочих, но это популярные).
для вашего обновления:. нет, это не связано с IE на самом деле, IE, по крайней мере, до 9 использует другой движок рендеринга под названием Тризуб.
на это был дан ответ и принят, но если кто-то все еще задается вопросом, почему сегодня все немного испорчено, вам придется прочитать это:
Это дает хорошее представление о том, как развивались Gecko, webkit и другие основные движки рендеринга и что привело к текущему состоянию испорченных строк пользовательского агента.
цитирование последнего абзаца для целей TL; DR:
главный вопрос. Поддерживается ли webkit IE?
вид. Проверьте Хромированная Рама, это плагин для Internet Explorer, который заставляет его использовать движок Webkit. Единственная причуда заключается в том, что вы должны убедить своих посетителей установить плагин.
обновление
Chrome Frame больше не поддерживается и не поддерживается.
WebKit-это механизм компоновки, предназначенный для Разрешить веб-браузерам отображать web страницы. Движок WebKit обеспечивает набор классов для отображения веб-контента в windows и реализует браузер такие функции, как следующие ссылки, когда щелкните пользователем, управляя back-forward list и управление a история недавно посещенных страниц.
WebKit был первоначально создан как вилка KHTML как движок компоновки для Apple Safari; это портативный для многих другие вычислительные платформы. Также используется в браузере Chrome от Google.
WebCore WebKit и JavaScriptCore компоненты доступны под GNU Меньшая общественная лицензия, и остальная часть WebKit доступна под Лицензия в стиле BSD.
для получения дополнительной информации о движках компоновки вы можете посмотреть здесь
Webkit-это движок рендеринга HTML, используемый Chrome и Safari.
Webkit-это движок рендеринга, используемый в популярных браузерах Safari и Chrome, а также других.
Webkit-это движок рендеринга html/css, используемый в браузере Safari от Apple и в Chrome от Google. префиксы значений css с-webkit-специфичны для webkit, обычно это CSS3 или другие нестандартные функции.
чтобы ответить на обновление 2 w3c-это тело, которое пытается стандартизировать эти вещи, они пишут правила, а затем программисты пишут свой механизм рендеринга, чтобы интерпретировать эти правила. Таким образом, в основном w3c говорит, что DIVs должен работать «таким образом», двигатель-писатель затем использует это правило для напишите свой код, любые ошибки или неправильные интерпретации правил вызывают проблемы совместимости.
общей проблемой, с которой я столкнулся как веб-дизайнер, является то, что многие люди используют IE6+. Обычно ничего особенного, кроме CSS, мне нужно добавить несколько синтаксисов рендеринга, чтобы проанализировать каждый запрос в браузере. Было бы очень хорошо, если бы была универсальная настройка рендеринга для CSS, которую IE может читать так же легко, как Chrome/FF/Opera и webkit. Проблема с IE заключается в том, что если я не использую все правильные стили CSS и рендеринга, чем мои веб-сайты выглядят и работают отлично, используя каждый браузер, кроме IE. Этот может сделать для несчастного, твердолобого клиента IE.
пример таков: скажем, мне нужна 1px, серая граница с радиусом границы 10%. Для Chrome и других я использую свойство webkit. Теперь, для IE, я должен добавить отдельные стили CSS, используя простые старые значения CSS «border: 1px solid #E5E5E5» и «border-radius: 10%». Положительный результат не всегда гарантирован за всех версиях браузера IE, но по большей части этот метод отлично работает для меня и многих других.
-webkit-это просто группа, в которую вписываются браузеры Chrome, Safari, Opera и iOS. Все они имеют общего предка, поэтому часто их возможности/ограничения (когда дело доходит до запуска CSS и Javascript) ограничены группой.
разработчик разместит-webkit-с последующим кодом, что означает, что код будет работать только в браузерах Chrome, Safari, Opera и iOS. Вот полный список:
попробуйте использовать Modernizr, HTML5 Shiv и ответить.js. Это удивительные IE-совместимые скрипты polyfill, которые используют polyfills, и другие ресурсы, которые помогут лучше визуализировать элементы HTML5 в IE9 и Под.
чтобы использовать эти поля, просто добавьте логику HTML boolean, чтобы разместить их, если браузер меньше, чем версия IE желания. Пример кода:
хорошая документация о WebEngines особенно webKit и его разработчики вы можете прочитать на: WebKit
Webkit-это движок рендеринга, используемый в популярных браузерах Safari и Chrome, а также других Каждый браузер поддерживается движком рендеринга для рисования веб-страницы HTML/CSS.
IE → Trident (прекращено) Edge → EdgeHTML (очистка вилки трезубца) В Firefox → Геккон Opera → Presto (больше не использует Presto с февраля 2013 года, рассмотрим Opera = Chrome в настоящее время) Сафари → В WebKit Chrome → Blink (вилка WebKit).
