От автора: префикс -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, даже если другие браузеры поддерживают свойство или оно имеет широкое распространение без префикса (вроде 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 и когда префикс будет удалён?
В идеальном мире экспериментальные префиксы исчезали бы, как только браузер начинает поддерживать стандартное свойство. Производители не станут так делать, потому что это сломает сайты, но они могут сделать больше чтобы привлечь внимание к проблеме, например, выпустить инструменты выявления морального устаревания и вывод сообщений об ошибке в консоли разработчика.
Обе компании виновны в продвижении префиксов webkit, словно они являются стандартной частью ежедневной разработки HTML5. Apple обвиняется в активной работе против W3C.
Другие производители месяцами следуют за браузерами на основе Webkit, если не годами. Добавление префиксов webkit нелепое решение, пора играть в свою игру.
Мы все любим классные демонстрации, но евангелисты часто забывают упомянуть, что свойства являются экспериментальными и, возможно, никогда не будут полностью поддерживаться браузером. В идеале, код должен работать как минимум в двух браузерах, по меньшей мере это означает, что требуется несколько вендорных префиксов.
Мы слишком ленивы. Мы пишем специфичный для браузера код, и, хотя у нас могут быть хорошие намерения относительно его исправления в дальнейшем, мы редко это делаем.
Вы помните последний раз, когда разработчики ориентировались на определённый браузер? Это был IE6. Мы до сих пор живём с наследием этого решения спустя десятилетие. Вы действительно хотите, чтобы история повторилась?
Я против не-Webkit браузеров, которые поддерживают префиксы webkit. В лучшем случае, они делают префиксы непригодными для использования. В худшем случае это нарушает весь процесс стандартизации. Вы можете соглашаться или не соглашаться, но дайте знать о своём мнении коллегам через блоги и социальные сети. W3C и производители браузеров прислушаются к вашему мнению, вы просто должны показать им это.
Затем протестируйте свой сайт в разных браузерах. Немного изящной деградации не повредит, но пренебрежение одним или несколькими современными браузерами это плохо. Исправьте код, в противном случае ваш сайт вносит свой вклад в эту проблему.
На первый взгляд кажется, что вендорные префиксы это что-то из разряда грамматики... Вендорные префиксы, вендорные суффиксы и вендорные окончания... Но какое отношение это имеет к верстке?
Оказывается, самое прямое! Вендорные префиксы — это приставки к названию 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:
Остальные разработчики используют вендорные префиксы по схожим причинам. Например 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.
Веб-разработчик начинающий изучать теоретические основы CSS и использующий данные знания на практике может столкнуться с проблемами при рассмотрении реальных примеров. Это может вызвать у него непонимание происходящего и отбить дальнейшее желание изучать данную технологию.
Например, при рассмотрении стилей какого-нибудь сайта веб-разработчик может столкнуться со свойствами, содержащими впереди некоторые непонятные слова: -webkit- , -moz- , -ms- и др.
* { -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; }
Что же это такое? На самом деле всё просто, эти непонятные слова являются префиксами следующих браузеров:
Таким образом, если перед названием свойства стоит некоторый префикс, то это означает, что данное свойство реализовано и будет применяться исключительно в указанном браузере. Все остальные браузеры данное свойство будут игнорировать, т.к. для них данный префикс неизвестен.
Причин для появления префиксов было достаточно много:
Когда экспериментальное свойство утверждено в стандарте и прошло тестирование в браузере, у него обычно убирается префикс.
Рассмотрим в качестве примере следующий код:
* { -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" браузеры отмечаются различными цветами, в зависимости от того в каком состоянии находится поддержка определённых свойств или тегов:
Процитирую фрагмент из книги Леа Веру "Секреты 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.
