Для каких свойств css нужно указывать префикс разных браузеров

Для каких свойств css нужно указывать префикс разных браузеров thumbnail

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

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

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

* {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}

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

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

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

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

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

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

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

* {
-webkit-box-sizing: border-box;
-moz-box-sizing: border-box;
box-sizing: border-box;
}

Данный код применяет свойства 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.

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

Сайт “Can I Use…”

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

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

  • Красный прямоугольник – браузер, в котором данное свойство не реализовано;
  • Зелёный прямоугольник с дефисом, расположенным в правом верхнем углу – браузер, в котором данное свойство используется через префикс;
  • Светло-зелёный прямоугольник – браузер, в котором данное свойство реализовано частично;
  • Зелёный прямоугольник – браузер, в котором данное свойство реализовано в соответствии со стандартом.

Источник

Всякому такому автору сайта, который

когда-либо

снабжал своё детище стилями CSS3, уж конечно доводилось сталкиваться с необходимостью многократно повторять одно и то же свойство CSS3 и давать ему одно и то же значение, но указывая перед именем свойства различные префиксы разработчиков браузеров (vendor prefixes).

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

префикс «-moz-»,

в Google Chrome и в Apple Safari (и в других браузерах на основе

Webkit) —префикс «-webkit-»,

в Опере —

префикс «-o-»,

в IE —

префикс «-ms-»,

а в Konqueror (и в наиболее ранних версиях

Safari) —префикс «-khtml-».

На практике, однако же, автор сайта чаще всего использует своего рода «общий знаменатель» возможностей нескольких браузеров — значения свойств CSS3, работающие одинаково (или почти одинаково) во всех современных браузерах. Да и записываются все они также одинаково. Указание префиксов сводится поэтому ко многократному повторению свойств. Например, чтобы придать нескольким кнопкам

jQuery-плагина

ColorBox закруглённые края и заставить их отбрасывать тень, поневоле придётся записать в CSS вот что:

#cboxPrevious, #cboxNext, #cboxClose {
-webkit-box-shadow: 0 0 6px #000;
-moz-box-shadow: 0 0 6px #000;
box-shadow: 0 0 6px #000;
-webkit-border-radius: 6px;
-moz-border-radius: 6px;
border-radius: 6px;
}

Читайте также:  Какие свойства могут проявлять аминокислоты

Во-первых, это задалбывает.

Во-вторых, это неэкономично.

В-третьих, всегда существует риск забыть о необходимости указать тот или иной префикс. (В списке «How to avoid common CSS3 mistakes» эта ошибка — на первом месте.)

Поэтому рано или поздно должно было появиться

какое-нибудь

средство, позволяющее автору

CSS-кода

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

CSS-свойстви CSS-значений —

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

И такое средство появилось — благодаря Lea Verou. Вот оно:

Скрипт

«-prefix-free»,

который занимает всего лишь 2 Kb в сжатом виде, обрабатывает свойства CSS3 и адаптирует их ко браузерам.

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

«User-Agent»,

да и не зависеть от готового (возможно, устаревшего) списка неподдерживаемых свойств, как это было бы на сервере.

Скрипт обрабатывает стили, указанные внутри элементов <style> и в атрибутах

style=”…”,

а также внешние стили, подключённые элементами <link> (но только не из других доменов). Тому примером — стиль самогó сайта

«-prefix-free».

Однако

«-prefix-free»

не умеет обрабатывать стили, подключённые директивою @import.

В браузерах Opera и Google Chrome по умолчанию не поддерживается обработка стилей, подключённых из локальных файлов (она требует донастройки браузера вручную). В браузере IE (а также в Mozilla Firefox

версии 3.6

и более ранних) не работают безпрефиксные значения свойств в атрибутах

style=”…”,

причём в этих старых Файерфоксах — не только значения,

но и имена

свойств.

К скрипту

«-prefix-free»

прилагается пара плагинов: меньший из них позволяет библиотекою jQuery (с помощью

метода .css(…))

считывать и устанавливать свойства CSS3 без префиксов,

а другой плагин

следит за появлением новых элементов <style>

и <link>,

за изменениями атрибутов

style=”…”,

за вызовами методов CSSOM (объектной

модели CSS) —

и оперативно снабжает нужные свойства префиксами.

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

style=”…”

(совершаемыми методом

setAttribute())

не удаётся проследить в Webkit, а в Google Chrome к тому же не сработает задание беспрефиксных свойств через CSSOM (например, element.style.transform =’rotate(5deg)’), хотя чтение сработает.

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

что «-prefix-free»

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

style=”…”,

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

С другой стороны, конечно, не надо забывать, что префиксы появились не на пустом месте — у них есть своя цель в жизни: преодоление взаимной несовместимости браузеров (в том числе старой и новой версии одного и того же браузера). Подробнее об этом поведал Эрик Мейер в статье «Prefix or Posthack» («A List Apart», 6 июля 2010 года). От подпирания свойств CSS3 «костылём» следует отказываться, когда оно может создать такую несовместимость.

С третьей стороны, употребление префиксов не следует доводить до фанатизма: когда оно лишается смысла, хороший «костыль» всего лишь экономит время автора сайта, не будучи способен привести к проблемам совместимости. Тот же Эрик Мейер у себя в Твиттере похвалил скрипт

«-prefix-free»

и поблагодарил Lea Verou.

Источник

Процитирую фрагмент из книги Леа Веру “Секреты CSS. Идеальные решения ежедневных задач”.

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

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

За прошедшие годы было предложено множество вариантов выхода из этой
непростой ситуации, но все они далеки от идеала. Повсеместно
презираемые браузерные префиксы — один из них. Идея заключалась в том,
что для каждого браузера могут быть реализованы экспериментальные (или
даже патентованные) возможности, к названиям которых необходимо
добавлять специальный префикс. Наиболее распространенные префиксы —
это -moz- для Firefox, -ms- для IE, -o- для Opera и -webkit-
для Safari и Chrome. Разработчикам предлагалось свободно
экспериментировать с этими специальными возможностями и делиться
своими впечатлениями с рабочей группой. Рабочая группа, в свою
очередь, должна была учитывать обратную связь от разработчиков при
подготовке спецификаций, постепенно доводя соответствующую
функциональность до совершенства. Так как у финальной,
стандартизированной версии должно было быть другое название (без
префикса), ее добавление не должно было порождать коллизии в
продуктах, использующих уже существующие, обремененные префиксом
эквиваленты.

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

Читайте также:  Какие имеет свойства боярышника

В конце концов разработчики осознали, что если использовать только
существующие браузерные префиксы, то к уже имеющемуся коду необходимо
возвращаться и добавлять новые объявления каждый раз, когда в новом
браузере появляется поддержка их любимой классной возможности CSS. Не
говоря уж о том, что все префиксы, необходимые для той или иной
возможности, вообще довольно сложно держать в памяти. Решение? Конечно
же, всегда использовать все возможные браузерные префиксы, в конце
заодно добавляя версию без префикса, для того чтобы гарантировать
правильную обработку кода в будущем. В результате код стал выглядеть
примерно так:

-moz-border-radius: 10px;
-ms-border-radius: 10px;
-o-border-radius: 10px;
-webkit-border-radius: 10px;
border-radius: 10px;

Среди этих объявлений два избыточны: -ms-border-radius и
-o-border-radius никогда ни в каком браузере не существовали, так
как в IE и Opera с самого начала было реализовано свойство
border-radius безо всякого префикса. Очевидно, что повторять каждое
объявление до пяти раз невероятно утомительно, а результирующий код не
приспособлен для нормальной поддержки. Появление инструментов, которые
автоматизировали бы это, было исключительно вопросом времени:

  • на таких веб-сайтах, как CSS3, Please! (https://css3please.com)
    и pleeease (https:// pleeease.io/playground.html), вы можете вставить
    CSS-код без префиксов и получить обратно CSS со всеми необходимыми
    префиксами. Подобные приложения стали одними из первых реализаций
    автоматического добавления браузерных префиксов, но быстро растеряли
    свою популярность, так как по сравнению с другими решениями довольно
    неудобны в использовании;

  • Autoprefixer (https://github.com/ai/autoprefixer) использует базу
    данных из Can I Use… (https://caniuse.com) для определения, какие
    префиксы необходимо добавить к коду без браузерных префиксов, и
    компилирует его локально, как препроцессор;

  • моя собственная утилита -prefix-free
    (https://leaverou.github.io/prefixfree) выполняет тестирование
    возможностей в браузере, определяя, какие префиксы требуются. Ее
    преимущество в том, что она крайне редко требует обновления, так как
    получает всю необходимую информацию, включая список свойств, из
    окружения браузера;

  • такие препроцессоры, как LESS (https://lesscss.org) и Sass
    (https://sass-lang.com), не предлагают стандартной функциональности
    добавления префиксов, но многие разработчики создают собственные
    подборки для возможностей, с которыми они чаще всего используют
    браузерные префиксы, и в обращении можно найти несколько подобных
    библиотек.

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

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

Не добавляйте бреузерные префиксы без веской на то причины. Просто погуглите новое для вас свойство на предмет поддержки браузеров. Слишком часто вижу добавление префиксов, которые нужны были в очень старых браузерах, которые вряд ли кто-то поддерживает (к примеру, которые нужны были в самых первых версиях Firefox или Chrome) на том же StackOverflow.

Источник

Подготовила: Татьяна Шкабко

Дата публикации: 07.09.2010

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

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

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

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

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

Вендорный префиксПроизводительБраузерБраузерный движок
-o-, -op-, -xv-Opera SoftwareOperaPresto
-moz-проект MozillaFirefox, SeaMonkey, Camino и др.Gecko
-ms-MicrosoftInternet Explorer 8Trident
-khtml-проект KDESafari до версии 3, Konqueror и др.KHTML послужил основой для WebKit
-webkit-AppleSafari 3+, Google Chrome и др.WebKit
Читайте также:  Какие свойства молекул углеводов могут обеспечивать им выполнение строительной функции

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

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

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

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:

  1. Если это свойство разработано только для Microsoft IE и не описано в спецификации или CSS модуле
  2. Если CSS модуль, к которому относится это свойство находится в разработке W3C и еще не достиг статуса кандидата в рекомендацию (Candidate Recommendation)
  3. Если свойство только частично реализует функции свойства, описанного в 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 свойства на свой страх и риск.

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

Наглядным примером такой реализации может быть использование CSS3 свойства transition. Поставим задачу реализовать для ссылки плавное изменение цвета фона при наведении курсора, не используя 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;/* в прямом виде не поддерживает ни один браузер */

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

Проверено в:

  • Opera 10.5
  • Safari 4
  • Chrome 5

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

Подытожим

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

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

Заметка

Свойства по спецификации всегда пишем последними.

Материалы

  • CSS 2.1 Specification:: Vendor-specific extensions
  • MSDN:: Microsoft CSS Vendor Extensions
  • developer.mozilla.org:: Mozilla CSS Extensions
  • quirksmode.org:: CSS vendor prefixes considered harmful
  • alistapart.com:: Prefix or Posthack by Eric Meyer

Источник