Пришло время переосмыслить вендорные префиксы в CSS

Префиксы конкретных браузеров

Ранее упоминалось, что спецификация CSS3 – это набор модулей, которые постепенно интегрируются производителями браузеров. Иногда интеграция включает в себя экспериментальную поддержку. Это означает, что пока спецификацию пишут, обсуждают и критикуют в W3C, изготовитель браузера может решить добавить поддержку для какихто свойств, чтобы опробовать их на практике. В последнее время такая практика стала естественной частью процесса, и обратная связь, получаемая во время экспериментального использования, часто применяется, чтобы внести поправки в спецификацию.

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

Для такой экспериментальной поддержки свойств CSS часто вводятся браузерные префиксы – например, так:

– webkit – border-radius

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

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

В табл. 1.03 перечислены самые широко используемые браузеры и связанные с ними префиксы. Мы будем использовать префиксы WebKit, Mozilla и Opera в части, касающейся CSS3 в примерах из следующих глав.

Д. Сидерхолм. «CSS3 для веб-дизайнеров»

Таблица 1.03. Наиболее широко используемые браузеры и связанные с ними префиксы

Как работают браузерные префиксы

Вот как CSS работает на практике с браузерными префиксами. Возьмем свойство border-radius в качестве примера. Положим, мы хотим скруглить углы элемента с радиусом 10 пикселей; вот как это делается:

– webkit-border-radius: 10px;

– moz-border-radius: 10px; border-radius: 10px;

Webkit (движок, используемый в браузерах Chrome, Safari, и в Safari для мобильных

устройств) и Gecko (движок браузера Firefox) поддерживают свойство border-radius посредством собственных префиксных свойств; Opera поддерживает это свойство без префикса. IE9 также будет поддерживать border-radius без браузерного префикса.

На момент подготовки издания (август 2012 года) все упомянутые браузеры поддерживают свойство border-radius без префикса, в том числе и IE9.Прим. ред.

Оптимальный порядок

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

Д. Сидерхолм. «CSS3 для веб-дизайнеров»

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

Не пугайтесь браузерных префиксов!

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

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

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

Кто-то может сравнить браузерные префиксы с эксплойтами синтаксиса, которые многим из нас приходилось использовать, чтобы дать команду конкретным версиям браузеров (например, синтаксисw\idth: 200px или_width: 200px , который позволяет обращаться к конкретной версии IE). Но, напротив, браузерные префиксы – это важная часть процесса стандартизации, позволяющая развивать свойство, внедряя его для практического применения.

Эрик Мейер, эксперт по CSS, объясняет разницу в статье «Префикс или постхак» на

A List Apart (http://bkaprt.com/css3/2/)3 :

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

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

…заставить производителей браузеров и рабочую группу трудиться вместе, чтобы разрабатывать тесты, необходимые для проверки интероперабельности. Затем эти тесты могут помочь тем (разработчикам браузеров. Прим. перев.), которые следуют за остальными, намного быстрее достичь интероперабельности. Они могут буквально выкатить реализацию с префиксом в одной публичной бета-версии и опустить префикс в следующей версии.

3 http://www.alistapart.com/articles/prefix-or-posthack/

Д. Сидерхолм. «CSS3 для веб-дизайнеров»

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

А как насчет повторений?

Можно думать, что довольно глупо повторять трижды или четырежды то, что выглядит как одно и то же свойство, и я могу согласиться.

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

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

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

Процитирую фрагмент из книги Леа Веру "Секреты 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 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:

  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 свойства . Поставим задачу реализовать для ссылки плавное изменение цвета фона при наведении курсора, не используя 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 или автоматически генерировать префиксы браузеров для CSS3. Обычно для решения такой задачи требуется дополнительная утилита, которая может быть достаточно неудобной в использовании. В данном уроке мы рассмотрим, как такая задача может быть решена с помощью PHP.

Разберем три вопроса:

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

Приведем пример, который показывает, насколько прост в использовании результат нашего урока.

В CSS файле вместо префиксов используется подчеркивание:

Border-radius: 10px;

Код скрипта сгенерирует полный список свойств с префиксами:

O-border-radius: 10px; -moz-border-radius: 10px; -webkit-border-radius: 10px; border-radius: 10px;

Одним тегом link загружается сразу три CSS файла. Скрипт css.php читает перечисленные файлы (css_file1.css , css_file2.css , and css_file3.css), комбинирует их и возвращает один единый файл.

Теперь посмотрим, как устроен скрипт.

Пишем код

Создаем файл css.php со следующим кодом:

Скрипт сначала получает список CSS файлов для обработки в виде строки из параметра URL (доступного в PHP как $_GET["f"]). Каждый файл отделен вертикальной чертой. Функция explode() разделяет строку по символу вертикальной черты и возвращает массив имен файлов.

Функция file_get_contents() получает содержание каждого файла, одного за другим, и мы добавляем его в переменную $contents .

После того как содержание CSS файлов было получено, начинается поиск свойств, которые начинаются с подчеркивания, которое заменяется на префикс браузера. Функция preg_match_all() находит в тексте все части, которые соответствуют регулярному выражению, и помещает их как массив в $matches .

Рисунок описывает шаблон для регулярного выражения:

Массив $prefixes содержит префиксы браузеров. Вы может добавить или удалить то, что нужно. Каждое свойство в $matches wбудет трансформировано в набор свойств CSS3 с префиксами браузеров. Код обрабатывает каждое свойство и создает буфер результата, заменяя подчеркивание в свойстве на очередной префикс, а затем заменяя оригинальное свойство содержанием буфера.

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

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

Свойства, которые соответствуют регулярному выражению будут сильно сжиматься:

Результат в переменной $contents является готовым к отправке CSS файлом. Первый вызов функции header() информирует браузер о том, что передаваемую информацию надо воспринимать как CSS файл. Второй вызов функции header() указывает браузеру, что файл действует в течении часа, чтобы браузер поместил копию в свой кэш и не запрашивал файл повторно с сервера.

Использование скрипта

Приведем простой пример использования нашего скрипта. Поместим файл css.php в каталог css вашего проекта вместе с тремя CSS файлами.

Первый файл header.css:

#header { width: 800px; height: 100px; padding: 20px; _border-radius: 10px; _box-shadow: 0px 0px 10px #000000; background: _linear-gradient(#D30000, #3D0000); }

The second file is center.css:

#center { width: 800px; height: 400px; padding: 20px; margin: 20px 0px; _border-radius: 10px; _box-shadow: 0px 0px 10px #000000; background: _linear-gradient(#8ED300, #213D00); }

The third file is footer.css:

#footer { width: 800px; height: 100px; padding: 20px; _border-radius: 10px; _box-shadow: 0px 0px 10px #000000; background: _linear-gradient(#006ED3, #00203D); }

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

Теперь создаем файл index.html , который использует данные стили.

example

Центр

Обратите внимание на атрибут href в теге link . Каждый файл CSS отдлен вертикальной чертой.

Заключение

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

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. Генераторы

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

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

  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то