CSS - Префиксы браузеров. Как работают браузерные префиксы. Причины появления префиксов

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

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

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

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

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

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

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

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

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

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

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

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. Идеальные решения ежедневных задач".

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

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

За прошедшие годы было предложено множество вариантов выхода из этой непростой ситуации, но все они далеки от идеала. Повсеместно презираемые браузерные префиксы - один из них. Идея заключалась в том, что для каждого браузера могут быть реализованы экспериментальные (или даже патентованные) возможности, к названиям которых необходимо добавлять специальный префикс. Наиболее распространенные префиксы - это -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, которые позволяют быть на острие прогресса за счёт многословных объявлений:

Background-image: -webkit-linear-gradient(#fff, #000); background-image: -moz-linear-gradient(#fff, #000); background-image: -ms-linear-gradient(#fff, #000); background-image: -o-linear-gradient(#fff, #000); background-image: linear-gradient(#fff, #000);

Это хорошо работает в теории, но вот что происходит в реальности.

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

Вы всё чаще будете находить сайты использующие только один префикс -webkit, даже если другие браузеры поддерживают свойство или оно имеет широкое распространение без префикса (вроде border-raduis ). Chrome и Safari поэтому выглядят лучше чем конкурирующие браузеры и другие производители этому не рады.

Была поднята проблема и её обсуждение на заседании W3C 7 февраля 2012 года .

Активисты стандартов учат людей использовать Webkit. Вы увидите по презентациям сторонников веб-стандартов, что они агитируют людей использовать префикс webkit.

Наша работа заключается в поиске совместного решения.

На данный момент мы пытаемся выяснить, сколько и какие свойства с префиксом webkit реально поддерживаются в Mozilla.

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

Давайте на мгновение заглянем в эту клоаку.

Браузеры не на движке Webkit будут поддерживать префикс -webkit. Такое решение рассматривается W3C.

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

Но я больше озабочен непоправимым ущербом, который случится, если решение будет принято. Как только разработчики обнаружат что префикс webkit работает в Firefox, IE и Opera, они станут ожидать, что префиксы работают во всех свойствах. Принятие одного только Webkit будет расти экспоненциально и производители браузеров будут вынуждены внедрять префиксы. В этот момент свойства с webkit станут стандартом де-факто независимо от спецификации W3C. Игра окончена: открытый веб закроется.

Кто виноват?

Мы можем указать пальцем на следующих.

Рабочая группа W3C

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

Производители браузеров

В погоне продвинуть новые технологии производителям легко добавить префикс и забыть о нём. Веб-разработчики требуют больше информации: это свойство рассматривается W3C и когда префикс будет удалён?

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

Apple и Google

Обе компании виновны в продвижении префиксов webkit, словно они являются стандартной частью ежедневной разработки HTML5. Apple обвиняется в активной работе против W3C.

Mozilla, Microsoft и Opera

Другие производители месяцами следуют за браузерами на основе Webkit, если не годами. Добавление префиксов webkit нелепое решение, пора играть в свою игру.

Технологи веб-сайтов и евангелисты

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

Веб-разработчики

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

Вы помните последний раз, когда разработчики ориентировались на определённый браузер? Это был IE6. Мы до сих пор живём с наследием этого решения спустя десятилетие. Вы действительно хотите, чтобы история повторилась?

Время действовать

Я против не-Webkit браузеров, которые поддерживают префиксы webkit. В лучшем случае, они делают префиксы непригодными для использования. В худшем случае это нарушает весь процесс стандартизации. Вы можете соглашаться или не соглашаться, но дайте знать о своём мнении коллегам через блоги и социальные сети. W3C и производители браузеров прислушаются к вашему мнению, вы просто должны показать им это.

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

Существует множество способов сжать файл 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 , который использует данные стили.

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

Заключение

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

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

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

Что такое вендор

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

Что такое вендорные префиксы в CSS

В случае с CSS префиксами, вендорами являются производители браузеров, которые используют свою торговую марку в сокращенном виде как приставку (префикс) к тем или иным CSS свойствам для идентификации. "А зачем использовать эти префиксы? ", - спросите вы. Вендорные префиксы используются различными браузерами для внедрения в список CSS свойств и поддержки их работы собственными движками новых экспериментальных свойств, которые пока еще официально не вошли в оборот и не были добавлены в спецификацию W3C. Иными словами, какое-то свойство может выполнять совершенно новую и часто очень даже полезную функцию, которую раньше приходилось реализовывать с помощью специальных хаков, хитростей, уловок или даже джаваскриптов. Однако это свойство еще не было добавлено к стандартным и может интерпретироваться далеко не всеми браузерами, для этого перед этим свойством и добавляется префикс с названием вендора, которому он принадлежит и в дальнейшем, при интерпретации браузером CSS кода, свойство будет правильно понято и выполнит функцию, для которой оно собственно и было предназначено.

Перечень основных вендорных префиксов

А теперь давайте приведем перечень основных вендорных префиксов, существующих на данный момент и известных нам.

• -o- - браузер Опера
• -moz- - браузеры семейства Мозилла (компания-производитель знаменитого Мозилла Файерфокс)
• -ms- - Майкрософт Эксплорер
• -webkit- - браузеры, использующие движок Вебкит - Гугл Хром, Сафари
• -icab- - официальный альтернативный браузер Эппл - Айкаб
• -khtml- - редко используемый KHTML интерпретатор для KDE

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

Вот, к примеру, код, который отключает автоматическую трансформацию (ресайз) текста *:

Text-size-adjust: none; -moz-text-size-adjust: none; -ms-text-size-adjust: none; -webkit-text-size-adjust: none;

* Свойство text-adjust-none есть смысл использовать для мобильных устройств, браузеры которых могут автоматически изменять размеры текста на странице, делая его более читаемым, но нанося при этом ущерб верстке и эстетике.

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

Немного уходя от темы, хочется сказать, что существует такой метод программирования, который называется ООП (объекто-ориентированное программирование). Так вот, его главная задача - сократить код, используя классы, функции и т. д. главным образом этот метод существует для того, чтобы выполнение какого-то определенного действия в разных участках программы не требовало написания одинаковых кусков кода. В случае ООП можно просто обращаться к заранее определенному классу и его функциям. Это упрощает работу и значительно сокращает и оптимизирует код. Почти то же самое происходит и в случае CSS с вендорными префиксами - когда их нет, код выглядит оптимизированным под все браузеры, а когда они приходят на помощь нетерпеливым верстальщикам, которые хотят бежать впереди медленного паровоза под названием W3C, код превращается в кашу, состоящую из копированных по 5 раз одних и тех же строк, отличающихся друг от друга каким-то непонятными префиксами.

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