Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
WebKit
WebKit также является основой экспериментального браузера, включенного в электронную книгу Amazon Kindle, а также для браузера по умолчанию в Apple iOS, BlackBerry Browser в ОС 6 и выше и мобильных операционных систем Tizen. Интерфейс прикладного программирования (API) WebKit предоставляет набор классов для отображения веб-контента в окнах и реализует функции браузера, такие как следующие ссылки при нажатии пользователем, управление списком перемотки назад и управление историей недавно посещенных страниц.
HTML и JavaScript-код WebKit изначально были вилкой KHTML и KJS-библиотек от KDE и теперь были дополнительно разработаны людьми из KDE, Apple, Google, Nokia, Bitstream, BlackBerry, Igalia и других. macOS, Windows, Linux и некоторые другие UNIX-подобные операционные системы поддерживаются проектом. 3 апреля 2013 года компания Google объявила о том, что она использовала WebCore, компонент WebKit, который будет использоваться в будущих версиях Google Chrome и браузера Opera под названием Blink.
WebKit доступен под лицензией BSD-формы, за исключением компонентов WebCore и JavaScriptCore, которые доступны по лицензии GNU Lesser General Public License. По состоянию на 7 марта 2013 года WebKit является товарным знаком Apple, зарегистрированным в ведомстве США по патентам и товарным знакам.
Содержание
Истоки
Согласно Apple, некоторые изменения включали специфические для OS X функции (например, Objective-C, KWQ, OS X-вызовы), которые отсутствуют в KHTML KDE, которые требуют различной тактики разработки.
Разделение разработки
Обмен кода между WebCore и KHTML стал все более трудным, поскольку база кода расходилась, потому что оба проекта имели разные подходы к кодированию и совместному использованию кода. В какой-то момент разработчики KHTML заявили, что вряд ли согласятся с изменениями Apple и заявили, что отношения между этими двумя группами были «горькой неудачей». Apple представила свои изменения в больших исправлениях, содержащих очень много изменений, с неадекватной документацией, часто связанной с будущими дополнениями. Таким образом, эти исправления были трудными для разработчиков KDE для интеграции обратно в KHTML. Кроме того, Apple потребовала от разработчиков подписывать соглашения о неразглашении, прежде чем смотреть на исходный код Apple, и даже тогда они не смогли получить доступ к базе данных ошибок Apple.
Во время опубликованного «развода» разработчик KDE Курт Пфайфл (pipitas) опубликовал статью, в которой разработчикам KHTML удалось заархивировать многие (но не все) улучшения Safari от WebCore до KHTML, и они всегда оценили улучшения, приходящие от Apple, и все еще делают так. В статье также отмечается, что Apple начала связываться с разработчиками KHTML о том, как улучшить взаимоотношения и пути будущего сотрудничества. Фактически, проект KDE смог включить некоторые из этих изменений, чтобы улучшить скорость рендеринга KHTML и добавить функции, включая соответствие с тестом на рендеринг Acid2.
Поскольку в новостях появилась новость о новостях, Apple опубликовала изменения исходного кода вилки WebKit в публичном репозитории контроля версий. Поскольку передача исходного кода в общедоступный репозиторий системы параллельных версий (CVS), разработчики Apple и KHTML расширяют сотрудничество. Многие разработчики KHTML стали рецензентами и отправителями для репозитория контроля версий WebKit.
Команда WebKit также отменила многие изменения, внесенные Apple в исходную базу кода WebKit, и реализовала уровни абстракции для конкретной платформы, чтобы значительно упростить передачу кода рендеринга ядра на другие платформы.
В июле 2007 года Ars Technica сообщила, что команда KDE переместится с KHTML на WebKit. Вместо этого, после нескольких лет интеграции, KDE Development Platform версии 4.5.0 была выпущена в августе 2010 года с поддержкой как WebKit, так и KHTML, а развитие KHTML продолжается.
Опенсорсинг
7 июня 2005 года разработчик Safari Дэйв Хаатт объявил в своем блоге, что Apple является открытым сайтом WebKit (ранее только WebCore и JavaScriptCore были с открытым исходным кодом) и открывали доступ к дереву контроля версий WebKit и к трекеру проблем. Об этом было объявлено на конференции Apple Worldwide Developers Conference 2005, старшим вице-президентом Apple по программной инженерии Бертраном Серлетом.
Компоненты JavaScriptCore и WebCore от WebKit доступны в рамках лицензии GNU Lesser General Public License, а остальная часть WebKit доступна под лицензией BSD.
Дальнейшее развитие
Начиная с начала 2007 года команда разработчиков начала внедрять расширения Cascading Style Sheets (CSS), включая анимацию, переходы и 2D и 3D-преобразования, такие расширения были выпущены в качестве рабочих проектов в консорциум World Wide Web (W3C) в 2009 для стандартизации.
В ноябре 2007 года проект объявил о том, что он добавил поддержку мультимедийных функций спецификации черновика HTML5, позволяя встроенное видео визуально визуализироваться и контролироваться скриптом в WebKit.
2 июня 2008 года проект WebKit объявил, что они переработали JavaScriptCore как «SquirrelFish», интерпретатор байт-кода. Проект превратился в SquirrelFish Extreme (сокращенно SFX), объявленный 18 сентября 2008 года, который компилирует JavaScript в собственный машинный код, устраняя необходимость в интерпретаторе байт-кода и тем самым ускоряя выполнение JavaScript. Первоначально единственной поддерживаемой архитектурой процессора для SFX был x86, но в конце января 2009 года SFX был включен для OS X на x86-64, когда он прошел все тесты на этой платформе.
WebKit2
8 апреля 2010 года был анонсирован проект WebKit2 для перепроектирования WebKit. Цель состоит в том, чтобы абстрагироваться от компонентов, которые обеспечивают рендеринг веб-страниц, из своего окружающего интерфейса или оболочки приложения, создавая ситуацию, когда «веб-контент (JavaScript, HTML, макет и т.д.) Живет в отдельном процессе из пользовательского интерфейса приложения». Эта абстракция предназначена для повторного использования более простого процесса для WebKit2, чем для WebKit. WebKit2 имеет «несовместимое изменение API от исходного WebKit», которое мотивировало его изменение имени.
WebKit2 будет нацелен на MacOS, Windows, GTK+ и MeeGo-Harmattan. Safari для OS X переключился на новый API с версией 5.1. Safari для iOS переключился на WebKit2 с iOS 8.
Использование
WebKit используется как механизм рендеринга в Safari и ранее использовался браузером Google Chrome в Windows, MacOS, iOS и Android до версии 4.4 KitKat (Chrome использовал только WebCore и включал свой собственный движок JavaScript с именем V8 и многопроцессорную систему). Другие приложения на macOS используют WebKit, такие как почтовый клиент электронной почты от Safari и версия 2008 года менеджера личных данных Entourage от Microsoft, оба из которых используют WebKit для рендеринга сообщений электронной почты с содержимым HTML.
Установленная база
Новые веб-браузеры были созданы вокруг WebKit, таких как браузер S60 на мобильных телефонах Symbian, браузере BlackBerry (версия 6.0+), Midori, браузере Chrome, в браузере Android до версии 4.4 KitKat и браузер, используемый в системном программном обеспечении PlayStation 3 версии 4.10. Веб-браузер KDE’s Rekonq и Plasma Workspaces также используют его как собственный механизм рендеринга веб-страниц. WebKit был принят как движок рендеринга в OmniWeb, iCab и Web (ранее назывался Epiphany) и Sleipnir, заменив их исходные механизмы рендеринга. В течение некоторого времени веб-сайт GNOME поддерживал как Gecko, так и WebKit, но команда решила, что цикл выпуска Gecko и планы дальнейшего развития сделают его слишком громоздким, чтобы продолжать поддерживать его. WebOS использует WebKit в качестве основы для его времени выполнения. В последнем обновлении интерфейса для Steam Valve используется WebKit для отображения его интерфейса и встроенного браузера. WebKit используется для рендеринга HTML и запуска JavaScript на платформе приложений Adobe Integrated Runtime. В Adobe Creative Suite CS5 WebKit используется для отображения некоторых частей пользовательского интерфейса. По состоянию на первое полугодие 2010 года аналитик оценил совокупное количество мобильных телефонов, поставляемых с браузером на основе WebKit, на уровне 350 миллионов. К середине апреля 2015 года доля рынка браузера WebKit составляла 50,3%.
Порты
В июне 2007 года Apple объявила, что WebKit был перенесен в Microsoft Windows как часть Apple.
Форк от Google
3 апреля 2013 года компания Google объявила о выпуске вилки компонента WebCit WebCore под названием Blink. Разработчики Chrome решили использовать форк, чтобы обеспечить большую свободу в использовании функций WebCore в браузере, не вызывая конфликтов вверх по течению, и чтобы упростить свою кодовую базу, удалив код для компонентов WebCore, не используемых Chrome. В связи с объявлением Opera Software в начале года, когда он переключился на WebKit с помощью базы данных Chromium, было подтверждено, что браузер Opera также переключится на Blink. После анонса, разработчики WebKit начали обсуждения по удалению кода, специфичного для Chrome, для оптимизации его кодовой базы. WebKit больше не имеет какого-либо конкретного кода [Google Chrome|Chrome]] (например, buildsystem, V8 JavaScript-движки, код платформы и т.д.).
Компоненты
WebCore
WebKit передает тесты Acid2 и Acid3 с идеальным рендерингом в пикселях и отсутствием сроков или проблем с гладкостью на эталонном оборудовании.
JavaScriptCore
2 июня 2008 года проект WebKit объявил, что они переработали JavaScriptCore как «SquirrelFish», интерпретатор байт-кода. Проект превратился в SquirrelFish Extreme (сокращенно SFX, продаваемый как Nitro), объявленный 18 сентября 2008 года, который компилирует JavaScript в собственный машинный код, устраняя необходимость в интерпретаторе байт-кода и тем самым ускоряя выполнение JavaScript.
Что такое 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).
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, однодневной давности или около того.