Браузерные префиксы CSS. Вендорные префиксы

Запасной вариант для всех браузеров Браузеры, которые пока что не поддерживают множественные фоны, проигнорируют свойство background целиком. Вот почему мы определили свойство background-color отдельно.На рис. 5.05 показано, как сайт выглядит в IE7: множественные фоны игнорируются, и

А как насчет других браузеров? Открывая форму в Internet Explorer 7 – браузере с нулевой поддержкой CSS3, – мы видим вполне приемлемую рабочую форму (рис. 6.15). Это замечательно! Все улучшения, добавленные свойствами CSS3, были проигнорированы; остался скелет формы, работающий так, как

А как насчет остальных браузеров? Добавление CSS-анимации – это первый раз в этой книге – когда мы улучшали пользовательский опыт только для одного производителя браузеров: WebKit. Одна из основных причин, по которой CSS3 используется все больше и больше, – новые свойства

7 альтернативных браузеров для iPad Олег Нечай Опубликовано 15 мая 2014 Строго говоря, для iOS существует только один полноценный браузер - Safari. Все альтернативы - это фактически графические надстройки и наборы Java-скриптов для движка с открытым

12.3. Разрешение и блокировка конкретных программ Еще один очень эффективный способ ограничить доступ к программам – это создание списка программ, которые можно запускать. Все программы, которые не попали в этот список, соответственно, запускать запрещено.Чтобы получить

Процитирую фрагмент из книги Леа Веру "Секреты 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! (http://css3please.com) и pleeease (http:// pleeease.io/playground.html), вы можете вставить CSS-код без префиксов и получить обратно CSS со всеми необходимыми префиксами. Подобные приложения стали одними из первых реализаций автоматического добавления браузерных префиксов, но быстро растеряли свою популярность, так как по сравнению с другими решениями довольно неудобны в использовании;

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

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

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

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

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

Личное мнение:

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

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

Вендорные префиксы представляют собой надпись, которая начитается с «-» или с «_» и для каждого браузера имеет смысл специального маркера, написанного перед CSS свойством.

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

Как их отличать?

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

Рассмотрим самые популярные браузеры и их префиксы. Те которые написанны на движке WebKit, а именно Safari выше третьей версии и GoogleChrome, считывают префикс -webkit- , а Safari до третьей версии -khtml- , так как имеет в своей основе движок KHTML. Для Opera можно использовать следующие префиксы: -o-, -op-, -xv- . Firefox воспримет свойства имеющие приставку -moz- , а браузеры корпорации Microsoft те, перед которыми написано -ms- .

Как это выглядит на практике?

Рассмотрим на примере для свойства transition-duration:

Webkit- transition- duration: 0. 76s; - moz- transition- duration: 0. 76s; - o- transition- duration: 0. 76s; - ms- transition- duration: 0. 76s; transition- duration: 0. 76s;

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

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

Большинство производителей называют несколько причин, когда нужно использовать вендорные префиксы. Основные, из которых:

• Свойство, которое было написано только для конкретного браузера и не содержится в стандартном списке css.
• Свойство ещё разрабатывается или по каким-то причинам не имеет рекомендаций к использованию
• Css задаёт только часть возможностей стиля.

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

Дополнительные возможности

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

Уже сейчас для верстки своих проектов можно исключить некоторые скрипты, заменив их стилями CSS.

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

Подводя итоги

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

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