Пора пересмотреть вендорные префиксы в CSS. Зачем нужны вендорные префиксы

02.08.2019

Что такое CSS хаки или Вендорные префиксы
Если браузер не поддерживает и не понимает какое-то определённое CSS свойство, то каким образом начинает вдруг понимать это свойство после применения хака?
Благодаря вендорным префиксам производители браузеров уже внедряют экспериментальные CSS3 свойства на свой страх и риск.

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

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

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

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

Основные причины использования вендорных префиксов:

1. Если это свойство разработано только для определённого браузера и не описано в спецификации или CSS модуле
2. Если CSS модуль, к которому относится это свойство находится в разработке W3C и еще не достиг статуса кандидата в рекомендацию (Candidate Recommendation)
3. Если свойство только частично реализует функции свойства, описанного в CSS модуле или спецификации

Благодаря вендорным префиксам производители браузеров уже внедряют экспериментальные CSS3 свойства на свой страх и риск.

Верстальщик уже сейчас может реализовать большинство возможностей предоставляемых CSS3, в том числе разнообразные переходы и анимации без использования скриптов, но используя вендорные префиксы.

Вендорные префиксы самых распространенных браузеров:

Вендорный префикс	Производитель	Браузер	Браузерный движок
-o-, -op-, -xv-	Opera Software	Opera	Presto
-moz-	проект Mozilla	Firefox, SeaMonkey, Camino и др.	Gecko
-ms-	Microsoft	Internet Explorer 8	Trident
-khtml-	проект KDE	Safari до версии 3, Konqueror и др.	KHTML
-webkit-	Apple	Safari 3+, Google Chrome и др.	WebKit
-icab-	Apple	iCab	WebKit

Пример написания:

border-radius:15px 0 15px 0; /* Валидное свойство CSS 3 скругление углов, значение(цифра) задаёт радиус скругления*/
-moz- border-radius:15px 0 15px 0; /* Firefox */
-webkit- border-radius:15px 0 15px 0; /* Safari, Chrome */
-khtml- border-radius:15px 0 15px 0; /* Konqueror */

На первый взгляд кажется, что вендорные префиксы это что-то из разряда грамматики... Вендорные префиксы, вендорные суффиксы и вендорные окончания... Но какое отношение это имеет к верстке?

Оказывается, самое прямое! Вендорные префиксы — это приставки к названию CSS свойства, которые добавляют производители браузеров для нестандартизированных свойств.

Согласно спецификации CSS 2.1 CSS идентификаторы, которые начинаются с "-" или "_" зарезервированы для CSS расширений браузеров. Наличие этих знаков в начале свойства гарантирует то, что в будущем расширения браузеров никогда не пересекутся со стандартными CSS свойствами. Т.е. ни один браузер не начнет «случайно» понимать свойство, которое для него не предназначено.

Какие они бывают?

Вендорные префиксы самых распространенных браузеров приведены в таблице ниже:

Как это работает?

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

Например, CSS свойство , отвечающее за прозрачность элемента, кроссбраузерно используется так:

Filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50); /* IE 5.5-7*/ -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";/* IE 8*/ -moz-opacity:0.5;/* Mozilla 1.6 */ -khtml-opacity:0.5;/* Konqueror 3.1, Safari 1.1 */ opacity:0.5/* Safari 2.0+ , Chrome, Firefox Opera, */

Для чего это нужно?

В своем блоге разработчики Internet Explorer называют три причины использования вендорного префикса -ms- для браузера IE8:

Если это свойство разработано только для Microsoft IE и не описано в спецификации или CSS модуле
Если CSS модуль, к которому относится это свойство находится в разработке W3C и еще не достиг статуса кандидата в рекомендацию (Candidate Recommendation)
Если свойство только частично реализует функции свойства, описанного в CSS модуле или спецификации

Остальные разработчики используют вендорные префиксы по схожим причинам. Например Mozilla имеет огромный перечень индивидуальных CSS свойств и их значений с вендорными префиксами -moz-, которые разработаны специально для Firefox, и не описаны ни в модуле CSS ни в спецификации.

Кроме того, разработчики Microsoft ухитрились с помощью вендорных префиксов скрывать от валидатора невалидные конструкции. Это касается, прежде всего, фильтров. Для IE 5.5-7 фильтр выглядел так:

Filter:progid:DXImageTransform.Microsoft.Alpha(opacity=50); /* IE 5.5-7*/

Такая конструкция пройти валидацию в принципе не может! Но ее преспокойно проходит новая конструкция того же фильтра, но уже для IE 8:

Ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)";/* IE 8*/

Конечно, не очень хочется в коде писать несколько строчек кода с вендорными свойствами под каждый браузер вместо одной строчки кода со стандартными свойствами. Но не нужно забывать, что спецификация CSS3 пока еще находится в разработке. Возможно, что в описании свойства при стандартизации что-то поменяется, либо его совсем не будет в спецификации. Тогда безусловно разработчикам будет легче отказаться от вендорного свойства и поддерживать стандарты. Согласитесь, если в разных версиях браузера одно и то же свойство будет работать по-разному, ничего хорошего из этого не получится. Пускай лучше в старых версиях браузеров будут работать вендорные свойства, а новые версии будут поддерживать спецификацию в прямом виде, а свойства с вендорными префиксами будут игнорироваться.

Приятный бонус

Наглядным примером такой реализации может быть использование CSS3 свойства . Поставим задачу реализовать для ссылки плавное изменение цвета фона при наведении курсора, не используя JavaScript. Для этого в CSS для ссылки нужно дописать следующий код

Webkit-transition:background-color 5s ease-in 3s;/* работает в Safari 3.1+, Chrome 1+ */ -o-transition:background-color 5s ease-in 3s;/* работает в Opera 10.5+ */ -moz-transition:background-color 5s ease-in 3s;/* планируется для Firefox 4.0+ */ transition:background-color 5s ease-in 3s;/* в прямом виде не поддерживает ни один браузер */

Живой пример можно посмотреть .

Браузерные префиксы CSS

Когда разработчики браузера внедряют новое свойство, значение или селектор, еще

не перешедшее в статус Candidate Recommendation (Кандидат в рекомендации), они

добавляют в начале свойства префикс с кодом механизма рендеринга. Например,

Moz-border-radius — это версия свойства border-radius, которая в настоящее

время используется в браузерах на базе Mozilla, таких как Firefox. В табл. 1.4 при-

веден список всех доступных префиксов.

Таблица 1.4. Браузерные префиксы свойств CSS

* В механизме рендеринга Presto свойства, связанные с речью, предваряются пре-

фиксом -xv-, а не -o-.

В этой книге мы будем использовать префиксы -moz-, -o- и -webkit-. Прочие не

так широко используются и не потребуются для рассматриваемых методов.

Зачем они нужны

Уникальные для производителей префиксы позволяют разработчикам испытывать

новые свойства, значения и селекторы до того, как соответствующие спецификации

будут завершены, — это отличный способ протестировать их «в полевых условиях»,

понять, требуют ли они корректировки и доработки. Если бы разработчики сразу

начали использовать стандартные свойства, не дополненные префиксами, им при-

шлось бы ограничиваться исключительно поведением, предусмотренным для этих

свойств первоначально.

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

бы, что их поведение останется единообразным и предсказуемым. Если через какое-

то время создатели браузеров поменяют то или иное свойство — например, из-за

ошибок в первоначальной реализации или изменений самой спецификации — это

поставит под угрозу целостность всех существующих сайтов, на которых данное

свойство уже используется. Получается, что не только разработчики оказываются

в плену у первой несовершенной реализации — пример с них приходится брать

и создателям всех браузеров, и даже самому консорциуму W3C. Эрик Мейер (Eric

Meyer) в своей превосходной статье «Prefix or Posthack» приводит два примера такого

неудачного развития событий, взятых из реальной жизни (http://www.alistapart.

com/articles/prefix-or-posthack).

Но даже если создатели одного браузера не меняют реализацию свойств, чтобы не сло-

мать существующие сайты, это может сделать W3C. Что произойдет, если создатели

остальных браузеров станут применять новое поведение, описанное в обновленной

спецификации? В разных браузерах одно и то же стандартное свойство будет ото-

бражаться по-разному. Именно так обстояли дела во времена Netscape 4, Mac IE 5 и

Windows IE 6. Число сложных и нестабильных исправлений посторонних ошибок,

совершенно не связанных со свойствами, первоначально требовавшими коррек-

тировки, быстро увеличивалось, потому что нестандартное поведение браузера не

изолировалось от окружающего мира в уникальных для этого браузера свойствах.

Разработчики понимают, что свойства с префиксами — экспериментальные и могут

быть изменены. Это дает создателям браузеров дополнительную свободу, позволяя

при необходимости вносить изменения и, следовательно, быстрее выпускать и ис-

правлять новые свойства. Разработчики сайтов и приложений, в свою очередь,

скорее получают возможность применить новые свойства и поучаствовать в про-

цессе доработки путем тестирования в реальных условиях.

Когда спецификация достигает более стабильного состояния, а разработчикам

браузеров удается добиться правильной реализации свойства, от префикса можно

избавляться. Если разработчики сайтов добавили в свои таблицы стилей версию

свойства без префикса — а делать это весьма полезно, чтобы не создавать проблем

с совместимостью в будущем, — веб-страницы автоматически начинают отобра-

жаться в соответствии с последними изменениями в спецификации свойства. Если

же они не предусмотрели версию свойства без префикса, то ничего страшного не

произойдет — она продолжает работать так же, как раньше. Ни один из сайтов, где

используется версия с префиксом, не сломается.

6 февраля 2012 в 14:14

CSS3: жизнь без префиксов

Разработка веб-сайтов

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

Проблема очевидна. Нужен способ облегчить работу с префиксами.

Естественно, перестать использовать префиксы было бы неразумно. Но переложить обязанность по их генерации на существующие специально для этого инструменты вполне возможно. Я попробовал перечислить возможные варианты.

1. Препроцессоры

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

Самые известные препроцессоры CSS это LESS и SASS .

Они являются прямыми конкурентами, хотя разница между ними есть. Оба могут использовать на стороне сервера, но LESS еще и доступен в виде javascript-файла, поэтому можно на эту особенность обратить отдельное внимание.

LESS

Этот препроцессор обладает синтаксисом, который проще, чем у конкурента. Существует возможность обрабатывать файлы стилей на стороне сервера, но нас интересует сейчас вариант работы на стороне клиента через файл javascript.

Подключение

Миксин
.border-radius(@radius: 3px) {
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
border-radius: @radius;
}

Использование
#shape1{
.border-radius(10px);
}

Для того, чтобы работать с префиксами, нужно использовать миксины (тот самый код, который знает что и где заменять). Существуют готовые наборы миксинов и библиотеки для CSS3
lesselements.com
github.com/jdmiller82/-lessins-
snipplr.com/view/47181/less-classes
roel.vanhintum.eu/more-less

Не обязательно компилировать файлы.less на сервере или в браузере, можно локально получить готовый файл CSS и уже его использовать на сайте
SimpLESS - приложение, которое автоматически компилирует.less в стандартный CSS. Бесплатно для всех платформ.
Less App - аналогичное приложение, но только для Мака.

На сервер происходит обработка файлов SASS, компьютер-клиент получает уже готовый файл.css

Достоинства препроцессоров:
+ Кроме префиксов, можно делать куда больше вещей
+ Возможность автоматически обрабатывать файл CSS (например, сжимать, удаляя лишнее)
+ Нормальное кэширование (правда, LESS кэшируется с помощью localStorage)

Недостатки препроцессоров:
– Для варианта с javascript - зависимость от включенных скриптов в браузере
– Генерируется код со всеми возможными префиксами, не только теми, которые нужны конкретному браузеру

3. Генераторы

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

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

Оглавление:

Префикс -webkit- доминирует в CSS настолько, что некоторые сайты без него работают неправильно. Это свидетельствует о следовании разработчиков не самым лучшим практикам в последние годы и это привело к неудачному, но практически вынужденному решению со стороны Mozilla. В Firefox версии 46 или 47 (это апрель или май 2016 года), Mozilla планирует реализовать поддержку нестандартных префиксов -webkit- , чтобы улучшить совместимость Firefox с сайтами, активно использующими -webkit (как правило, это сайты, ориентированные на мобильные устройства).

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

Подход Mozilla и Microsoft безопасен для большинства сайтов. На многих сайтах будет использоваться префикс -moz- или же не потребуется никаких действий для совместимости с будущим обновлением Firefox. Но как профессиональные веб-разработчики, мы должны тщательно рассмотреть и понять, какие последствия это повлечет. Вы наверняка знаете, какие из ваших сайтов могут пострадать от этого обновления.

Итак, пришло время переосмыслить подход к префиксам и протестировать сайты с ними.

Поддерживаемые префиксы

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

Разработчики Firefox также близки к аналогичному подходу:

Текущий тренд в Mozilla это избегание вендорных префиксов за счет отключения не готовых свойств и использовании непрефиксной версии при достаточной стабильности. Это общая политика: в отдельных случаях возможны исключения - Борис из Mozilla

Microsoft Edge также собирается отказаться от вендорных префиксов:

“Microsoft также собирается отказаться от вендорных префиксов в Edge. Это значит, что разработчики, которые стремятся использовать специфичные возможности HTML и CSS не будут использовать специфичный префикс для Edge. Вместо этого они будут просто писать код в соответствии со стандартами” - Mashable

Постепенной деградации, основанной на префиксах больше не будет

Этот уход от вендорных префиксов означает одну вещь - постепенная деградация с помощью вендорных префиксов не имеет перспектив.

Использование вендорных префиксов для применения стилей для конкретного браузера (например, только для Chrome) не являлось целью их введения; рекомендацией для разработчиков всегда было использование всех префиксов (от -webkit- до -o-). Если вы используете возможности, которые зависят от префиксных свойств и используете префиксы для постепенной деградации вашего дизайна в других браузерах, то это больше не работает.

Заключение

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