Webkit css что это

Webkit css что это

• 
• 
• 

Webkit Browser Engine

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

Проще говоря механизм рендеринга — это компонент, который отвечает за то, что видно в браузере, где берет данные из HTML или PHP, форматирует их в соответствии с CSS или XSL и передает их браузеру пользователя.

Не все веб-браузеры используют один и тот же механизм рендеринга. Internet Explorer использует движок Trident, продукты Mozilla, такие, как Firefox, используют Gecko, Opera использует движок Presto, а движок WebKit используется браузерами Safari и Chrome.

Из-за различных движков рендеринга в веб-браузере иногда возникают проблемы перекрестной совместимости для макета контента. Другими словами, это контент, который возможно был разработан для Internet Explorer, может не отображаться так, как задумал дизайнер в другом браузере, таком как Mozilla Firefox.

Webkit в синтаксисе CSS3

Таким образом термин «webkit» также является частью синтаксиса CSS, используемого для визуализации контента для браузеров Safari и Chrome. Из-за отсутствия кросс-совместимости, код webkit, возможно, должен быть включен в CSS, чтобы гарантировать, что он будет отображаться так, как задумано в Chrome и Safari.

Актуальность webkit связана с CSS3, где с модулями CSS нового поколения, которые предоставляют такие функции, как эффекты перехода, макеты с несколькими столбцами и анимация. Хотя все браузеры могут отображать старые спецификации CSS в значительной степени в одинаковой степени, это не относится к новым модулям CSS3.

Например в коде CSS3 расположенном ниже зеленого квадрата, он расширяется по горизонтали в течение 2 секунд, когда на него наведена мышь.

Чтобы тот же эффект перехода отображался в браузерах с использованием механизма WebKit, где код CSS будет следующим:

WebKit для разработчиков

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

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

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

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

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

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

WebKit порты

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

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

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

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

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

Что общее во всех 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. Супер.

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

Точно также как Flickr и Github прячут реализованные функции за специальными флагами, WebKit делает тоже самое. Это позволяет портам включать/выключать любую функциональность на стадии компиляции с помощью WebKit compile-time Feature Flags. Функции также могут быть включены в режиме работы, с помощью параметров в командной строке (для Chromium) или конфигураций, таких как about:flags.

Теперь, давайте попробуем подвести итог, что общего в мире 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

Или если вдаваться в подробности, недавно добавленная функция: 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, обратите внимание, как различается набор инструментов для каждого из них, несмотря на общие компоненты:

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, однодневной давности или около того.

CSS — Префиксы браузеров

Веб-разработчик начинающий изучать теоретические основы CSS и использующий данные знания на практике может столкнуться с проблемами при рассмотрении реальных примеров. Это может вызвать у него непонимание происходящего и отбить дальнейшее желание изучать данную технологию.

Например, при рассмотрении стилей какого-нибудь сайта веб-разработчик может столкнуться со свойствами, содержащими впереди некоторые непонятные слова: -webkit- , -moz- , -ms- и др.

Что же это такое? На самом деле всё просто, эти непонятные слова являются префиксами следующих браузеров:

• -webkit- : браузеры Chrome, Safari, Opera;
• -moz- : браузер Mozilla Firefox;
• -ms- : браузер Internet Explorer.

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

Причины появления префиксов

Причин для появления префиксов было достаточно много:

• Для включения в браузер экспериментальных свойств CSS, которые стандартом ещё не утверждены. Таким образом, производители браузеров производят тестирование и вносят предложения перед утверждением свойств CSS в стандарте.
• Для решения проблем с кроссбраузерностью.
• Для создания собственных свойств, которые не входят в стандарт CSS, но возможно появятся в нём через некоторое время.

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

Как использовать префиксы

Рассмотрим в качестве примере следующий код:

Данный код применяет свойства CSS, которые изменяют алгоритм расчёта ширины и высоты для всех элементов веб-страницы. Первое CSS свойство -webkit-box-sizing со значением border-box предназначено для браузеров, использующих движок webkit (Safari) или blink (Chrome, Opera, Яндекс.Браузер). Второе CSS свойство -moz-box-sizing со значением border-box предназначено для браузеров, использующих движок Gecko (Mozilla Firefox). Последнее CSS свойство предназначено для браузеров, в которых это свойство уже протестировано и внедрено в соответствии со стандартом.

При использовании префиксов для свойств CSS, необходимо помнить, что их следует располагать до свойства CSS без префикса. Почему это так важно? Это важно потому, что если когда-то в браузере будет реализовано оригинальное свойство (без префикса), то будет использоваться именно оно (т.к. оно располагается последним), а не его экспериментальная версия.

Например: применение свойства CSS ко всем элементам веб-страницы в браузере Google Chrome версии 40.

На рисунке выше видно, что оригинальное свойство box-sizing уже внедрено в этот браузер, и из-за того, что оно располагается последним, браузер использует именного его, а не вышеприведенное свойство -webkit-box-sizing .

Как проверить поддержку определенного свойства в браузере

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

Например: проверим, как реализовано свойство transform в браузерах.

На сайте «CanIUse» браузеры отмечаются различными цветами, в зависимости от того в каком состоянии находится поддержка определённых свойств или тегов:

WebKit CSS extensions

Applications based on WebKit or Blink, such as Safari and Chrome, support a number of special WebKit extensions to CSS. These extensions are generally prefixed with -webkit- . Most -webkit- prefixed properties also work with an -apple- prefix. A few are prefixed with -epub- .

WebKit-only properties

Note: Avoid using on websites. These properties will only work in WebKit applications.

* A few are on the standards, unprefixed track ** New syntax has been standardized. Property links to the new syntax. Old prefixed syntax is still supported in some browsers. *** WebKit supports without -webkit prefix, but not standard or on standards track

WebKit-prefixed properties on the standards track

Formerly proprietary properties that are now standard

Note: To maximize the compatibility of your CSS, you should use the unprefixed standard properties instead of the prefixed ones listed below.

Supported in non-webkit browsers without a prefix, but not standard

The following properties are supported in at least one browser without a prefix, but are not on the standards track.

* Supported unprefixed in Firefox, with prefix in Safari.

Supported in Firefox with -webkit- prefix

The following properties are supported with the -webkit- prefix in Firefox. Many of these are supported with no prefix as well: see Formerly proprietary properties that are now standard above.

Note: Due to the legacy code in a multitude of web sites that used -webkit- prefixed properties, Edge and Firefox redirect many -webkit- prefixed properties to -moz-, -ms-, and unprefixed equivalents.

* Supported with -moz- and -webkit- prefix in Firefox, but not supported without a prefix. ** These values are supported even though they are not standard and are not on track to becoming standard. *** Use flex-box properties instead.

Deprecated -webkit- properties

The following properties were once supported with the -webkit- prefix but are no longer supported in evergreen browsers, with or without the -webkit- prefix.

• -webkit-alt*
• -webkit-border-fit
• -webkit-color-correction
• -webkit-flow-from
• -webkit-flow-into
• -webkit-grid-columns (See grid-column)
• -webkit-grid-rows (See grid-row)
• -webkit-hyphenate-charset
• `-webkit-image-set (See image-set )
• -webkit-mask-attachment
• -webkit-match-nearest-mail-blockquote-color
• -webkit-region-break-after
• -webkit-region-break-before
• -webkit-region-break-inside
• -webkit-region-fragment
• -webkit-shape-inside (See touch-action)
• background-origin-x (unprefixed!)
• background-origin-y (unprefixed!)

* Still supported in the Safari Technology Preview, but not in a generally released browser.

Pseudo-classes

Note: If there is an invalid pseudo-class within in a chain or group of selectors, the whole selector list is invalid.

Pseudo-elements

For web-compatibility reasons, Blink, WebKit, and Gecko browsers treat all pseudo-elements starting with ::-webkit- as valid.

Note: Generally, if there is an invalid pseudo-element or pseudo-class within in a chain or group of selectors, the whole selector list is invalid. If a pseudo-element (but not pseudo-class) has a -webkit- prefix, As of Firefox 63, Blink, WebKit and Gecko browsers assume it is valid, not invalidating the selector list.