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

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

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

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

Что такое 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 */

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

Идея не нова, Microsoft Edge также поддерживает различные -webkit- префиксы для совместимости. Opera начала поддерживать -webkit- префиксы в 2012, а затем перешла на Webkit движок Blink. W3C и разработчики браузеров не планировали использовать данный префикс в разработке сайтов:

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

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

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

Новые префиксы

Mozilla собирается включить ряд –webkit- префиксов. Из того, что я собрал, видно, что Mozilla не собирается сопоставлять свой список со свойствами Edge. Не всем свойствам нужна совместимость с движком Mozilla. Среди префиксов, которые Mozilla собирается добавить, судя по странице вики Compatibility/Mobile/Non Standard Compatibility будут следующие:

Webkit- для градиентов

Webkit-transforms

Webkit-transitions

Webkit-appearance

Webkit-background-clip

Webkit-device-pixel-ratio

Webkit-animation

Некоторые другие свойства могут быть в @-webkit-keyframes.

Тест на кроссбраузерность будет иметь решающее значение

Если вы, веб-разработчик не стали включать –moz- префикс, чтобы не проверять новые свойства CSS в Firefox, а срок сдачи подходит к концу, и заказчик заставляет вас добавить данный префикс, то вам придется заново тестировать сайт в Firefox 46 или 47. Данные версии выйдут в апреле или мае, так что у вас еще есть немного времени.

Чтобы протестировать свой веб-сайт, не дожидаясь выхода Firefox 46/47, можно активировать данные изменения в Firefox Nightly при помощи настройки layout.css.prefixes.webkit в about:config. Если у вас установлена последняя версия Nightly, то по умолчанию должно стоять true. Пока что в Firefox Nightly работают не все изменения –webkit- префиксов, но все же это хорошая площадка, чтобы протестировать, как ваш сайт скоро будет выглядеть. Я бы подождал марта перед серьезным тестированием сайта в Firefox Nightly.

Намного важнее, что Microsoft Edge уже интерпретирует и отображает –webkit- префиксы похожим образом. А это означает, что любые WebKit стили вашего сайта уже отображаются в браузере, от которого этого совершенно не ожидали. Если вы еще не работали с данным браузером, то установите себе Windows 10 и получите к нему доступ для тестирования сайтов.

Вендорные префиксы постепенно уходят

К счастью, вендорные префиксы постепенно уходят параллельно с тем, как команды разработчиков находят новые решения. Команда Chrome/Blink немного изменили свой подход:

«Забегая наперед, вместо включения вендорных префиксов по умолчанию мы будем держать обычные свойства за флагом «активировать экспериментальные свойства веб-платформы» в about:flags до тех пор, пока данные свойства не будут включены по умолчанию.» — Команда The Chrome/Blink

Команда Firefox пошла по схожему пути: «Основное направление работы в Mozilla сейчас это уход от вендорных префиксов, путем их отключения или же перевод их в состояние обычных свойств, если они уже стабильны. Это как минимум наша общая политика, отдельные случаи заслуживают исключений. » — Борис из Mozilla

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

Изящная деградация при помощи префиксов больше не работает

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

Заключение

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

Перевод: Влад Мержевич

Разработчики с любовью и ненавистью относятся к вендорным префиксам 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 и производители браузеров прислушаются к вашему мнению, вы просто должны показать им это.

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