Вендорные префиксы
Что такое вендорные префиксы знают все!
Вкратце: вот они родимые (основные):
Вернее даже не так, правильней задать вопрос: можем ли мы НЕ использовать префиксы? Пожалуй, что нет. А отсюда вытекает другой вопрос: была ли это хорошая идея разработчиков браузерных движков добавлять префиксы?
Прежде чем кивать головами как собачки на панелькой доске, предлагаю обсудить несколько моментов. Начнем с истоков:
Идея была отличная! На тот момент. Но крайне недальновидная.
Потихоньку начали появляться реализации новых свойств css3. Они появлялись в то время, как спецификации css3 ещё не было, не было даже кандидатов релизы, но об этом уже все говорили. Все ждалиCSS3 спасения нововведений и уже начали внедрять новые свойства как модно нынче писать "на свой страх и риск".
Но, как мы знаем,воз и ныне там? w3c не торопилась: то ли из желания впихнуть максимум в новую 3-ю версию, то ли из желания угодить всем, то ли из-за собственной огромной неповоротливости.
Так вот, браузеры начали обзаводится новыми свойства со своими персональными префиксами. Типа и овцы целы, и волки сыты (и новые свойства есть в браузере, и спецификации не противоречат). Парадоксально, но именно благодаря этому браузеры стали на шаг впереди спецификации. И тут на горизонте появляется еще один вопрос: при такой сумасшедшей популярности новых свойств, стоило ли их писать с префиксами?
Рассмотрим несколько вариантов развития сюжета на примере border-radius.
Исходные данные: это новое свойство и его ни у кого ещё нет.
Вариант 1.
Один браузер решил, что это будут выпуклые уголки и реализовал у себя со своими персональными префиксами.
Будут ли верстальщики его использовать? Нет. Зачем использовать то, что работает только в одном браузере, тем более, что с костылем? Потому что для остальных надо по-прежнему использовать картинки.
Вариант 2.
Один браузер решил, что это будут вогнутые уголки, а не выпуклые. Сказано - сделано! А потом другие браузеры это внедрили у себя, только с выпуклыми уголками. Первый браузер-бедолага посмотрел на это дело, подумал, как он нехило лоханулся и в следующем своем релизе поменял вогнутость на выпуклость. Всё равно на данном этапе разработчики не использовали бы данное свойство, а если бы использовали и ругались на неадекватность, то, как модно сейчас писать, "на свой страх и риск", да и вообще какие претензии? Самое главное, что браузер (ну вы поняли, что за ним стоят пчелки-программисты) осознал свою ошибку и исправился.
Вариант 3.
Несколько браузеров реализовало это свойство разными методами. Более сложный случай варианта номер 2. Пока что гипотетический, я еще не встречала настолько разную реализацию. Но в этом случае придется договариваться. Сложно, больно, но что делать? Именно для этого есть официальная спецификация, так что такие сложности можно было бы оставить до выхода кандидата в релизы.
Вариант 4.
Идеальный вариант, когда несколько браузеров одинаково реализовали каждый у себя со своим префиксом. Возникает вопрос: почему бы им изначально не использовать новое свойство без префиксов? Вы скажете, что на это нет спецификации. Ну так ее может и не быть ещё очень долго, но в действительности мы получаем следующие конструкции:
Т.е. по сути все поняли правильно, просто им сложно отказаться от префиксов или они боятся ошибиться, но в этом нет ничего плохого. Как я уже писала, не страшно ошибиться, главное уметь признать ошибку.
Поэтому на этапе разработки считаю префиксы ненужными, если изначально достаточно правильно понять название свойства.
Единственной проблемой может стать только IE. В силу того, что он не часто обновляется и ему тяжелее быть актуальным к новым свойствам. Но в защиту хочу заметить, что некогда он одним из первых обзавелся костылями для реализации специфических свойств с помощью filter.
Как это выглядит на данный момент в винде:
Как мы видим, у каждого своя реализация. Сафари вообще не подумала о выпадающем списке, а две дурацкие "кнопочки" просто листают дни (примечательно, что в
Прелесть html в том, что у них нет "префиксов" и никого это не смущает. Если появится некий стандарт на данную форму, то они просто его внедрят! Всё просто. Css есть чему поучиться ;)
Валидация предназначена для того, чтобы писать правильный код. Но разве она может проверить код на то, что он "с душком"? К тому же отвалидированный код не гарантирует, что сайт будет правильно отображаться и функционировать.
Лет 10 назад было модно ставить на свой сайт значки w3c css & html validation. Сейчас же этим никто не заморачивается.
Почему это происходит? Опера широко распространена в русскоязычном сегмента, но за рубежом ее практически не используют. То же самое происходит и в мобильном пространстве, когда новые браузеры хотят ворваться на рынок, но не хотят портить сайты из-за верстки, предусматривающей только один префикс.
Даже w3c рассматривают как стандарт поддержку префикса -webkit всеми браузерами!
Вкратце: вот они родимые (основные):
- -o- (Opera Software)
- -moz- (проект Mozilla)
- -ms- (Microsoft)
- -webkit- (Apple)
Стоит ли использовать префиксы?
Конечно же стоит!Вернее даже не так, правильней задать вопрос: можем ли мы НЕ использовать префиксы? Пожалуй, что нет. А отсюда вытекает другой вопрос: была ли это хорошая идея разработчиков браузерных движков добавлять префиксы?
Прежде чем кивать головами как собачки на панелькой доске, предлагаю обсудить несколько моментов. Начнем с истоков:
Спецификации и W3C
Префиксы появились в те далекие времена, когда спецификация CSS 2.1 сказала, мол, вот вам индикаторы, пусть они начинаются с "-" или "_", играйтесь на здоровье, это будут ваши персональные, уникальные свойства! И браузеры подумали: "Ачуметь! Дайте две!" Нет, конечно же браузеры не могут думать, если под словом "думать" не подразумевать искусственный интеллект и все такое. Подумали и обрадовались разработчики браузеров, что они могут извращаться по полной, и привнести это в свои детища!Идея была отличная! На тот момент. Но крайне недальновидная.
Потихоньку начали появляться реализации новых свойств css3. Они появлялись в то время, как спецификации css3 ещё не было, не было даже кандидатов релизы, но об этом уже все говорили. Все ждали
Но, как мы знаем,
Так вот, браузеры начали обзаводится новыми свойства со своими персональными префиксами. Типа и овцы целы, и волки сыты (и новые свойства есть в браузере, и спецификации не противоречат). Парадоксально, но именно благодаря этому браузеры стали на шаг впереди спецификации. И тут на горизонте появляется еще один вопрос: при такой сумасшедшей популярности новых свойств, стоило ли их писать с префиксами?
Рассмотрим несколько вариантов развития сюжета на примере border-radius.
Исходные данные: это новое свойство и его ни у кого ещё нет.
Вариант 1.
Один браузер решил, что это будут выпуклые уголки и реализовал у себя со своими персональными префиксами.
Будут ли верстальщики его использовать? Нет. Зачем использовать то, что работает только в одном браузере, тем более, что с костылем? Потому что для остальных надо по-прежнему использовать картинки.
Вариант 2.
Один браузер решил, что это будут вогнутые уголки, а не выпуклые. Сказано - сделано! А потом другие браузеры это внедрили у себя, только с выпуклыми уголками. Первый браузер-бедолага посмотрел на это дело, подумал, как он нехило лоханулся и в следующем своем релизе поменял вогнутость на выпуклость. Всё равно на данном этапе разработчики не использовали бы данное свойство, а если бы использовали и ругались на неадекватность, то, как модно сейчас писать, "на свой страх и риск", да и вообще какие претензии? Самое главное, что браузер (ну вы поняли, что за ним стоят пчелки-программисты) осознал свою ошибку и исправился.
Вариант 3.
Несколько браузеров реализовало это свойство разными методами. Более сложный случай варианта номер 2. Пока что гипотетический, я еще не встречала настолько разную реализацию. Но в этом случае придется договариваться. Сложно, больно, но что делать? Именно для этого есть официальная спецификация, так что такие сложности можно было бы оставить до выхода кандидата в релизы.
Вариант 4.
Идеальный вариант, когда несколько браузеров одинаково реализовали каждый у себя со своим префиксом. Возникает вопрос: почему бы им изначально не использовать новое свойство без префиксов? Вы скажете, что на это нет спецификации. Ну так ее может и не быть ещё очень долго, но в действительности мы получаем следующие конструкции:
.box_rotate {
-webkit-transform: rotate(7.5deg); // Safari 3.1+, Chrome
-moz-transform: rotate(7.5deg); // Firefox 3.5-15
-ms-transform: rotate(7.5deg); // IE9+
-o-transform: rotate(7.5deg); // Opera 10.5-12.00
transform: rotate(7.5deg); // Firefox 16+, Opera 12.50+
}
Т.е. по сути все поняли правильно, просто им сложно отказаться от префиксов или они боятся ошибиться, но в этом нет ничего плохого. Как я уже писала, не страшно ошибиться, главное уметь признать ошибку.
Поэтому на этапе разработки считаю префиксы ненужными, если изначально достаточно правильно понять название свойства.
Единственной проблемой может стать только IE. В силу того, что он не часто обновляется и ему тяжелее быть актуальным к новым свойствам. Но в защиту хочу заметить, что некогда он одним из первых обзавелся костылями для реализации специфических свойств с помощью filter.
Сложности первой реализации
Под первой реализацией будем понимать первую реализацию нового свойства у браузера. И сложность состоит в том, что каждый браузер имеет свое видение. Вспомним пример про вогнутые и выпуклые уголки border-radius. Но это вымышленный пример, лучше посмотрим на реальный: поле даты с выпадающим календариком (прощай datepicker.js!):<input type="date">
Как это выглядит на данный момент в винде:
Chrome:
Opera:
Safari:
Как мы видим, у каждого своя реализация. Сафари вообще не подумала о выпадающем списке, а две дурацкие "кнопочки" просто листают дни (примечательно, что в
<input type="datetime-local" value="2013-01-06 12:01:00"> они листают минуты ^_^). На самом деле это неважно! Это первая, "прикидочная" реализация. И ничто не мешает поменять в следующих версиях, расширить добавить стилизацию через css.Прелесть html в том, что у них нет "префиксов" и никого это не смущает. Если появится некий стандарт на данную форму, то они просто его внедрят! Всё просто. Css есть чему поучиться ;)
Валидация
Важным аргументов для использования вендорных префиксов является валидация, потому что она игнорирует префиксы. Мне интересно почему? т.е. так ли адекватна и востребована валидация, как мы думаем? Если она позволяет по сути вставлять любые конструкции и игнорировать их при валидации?Валидация предназначена для того, чтобы писать правильный код. Но разве она может проверить код на то, что он "с душком"? К тому же отвалидированный код не гарантирует, что сайт будет правильно отображаться и функционировать.
Лет 10 назад было модно ставить на свой сайт значки w3c css & html validation. Сейчас же этим никто не заморачивается.
Поддержка чужих префиксов
На данный момент возникает ещё одна абсурдность, когда браузеры начинают поддерживать чужие префиксы. Так, например, Opera заявила, что будет поддерживать -webkit-.Почему это происходит? Опера широко распространена в русскоязычном сегмента, но за рубежом ее практически не используют. То же самое происходит и в мобильном пространстве, когда новые браузеры хотят ворваться на рынок, но не хотят портить сайты из-за верстки, предусматривающей только один префикс.
Даже w3c рассматривают как стандарт поддержку префикса -webkit всеми браузерами!
Это epic fail префиксов. Из некогда прогрессивной идеи они превращаются в довольно грубый артефакт, от которого следовало бы избавиться.
Из-за этого разработчикам браузеров приходит поддерживать не только утвержденные свойства, но и свои, костыльные, с префиксами, при чем в последнем случае, если они действительно лоханулись с его пониманием (и соотв. реализацией, см. вариант 2), им придется поддерживать их неправильное поведение.
Хочу отметить, что эта сложность в первую очередь для разработчиков браузеров, а не для верстальщиков. Мы уже привыкли использовать less/sass, что даже не задумываемся о том, нуждается ли данное css-свойство в уточнении префиксом или нет. Мы пишем следующие конструкции и порой перегружаем код парой ненужных свойств:
Если посмотреть на те css3-свойства, которые мы уже сейчас используем: css3please.com, то станет ясно, что браузеры правильно и одинаково понимают их. А это значит, что мы развиваемся почти по 4-му идеальному варианту.
Отличие составляют только префиксы-костыли. И я задаюсь вполне очевидным вопросом: может быть, стоит прекратить эту "войну" префиксов и начать внедрять очевидные свойства?
В завершении хотелось бы на примере фильтров и масок познакомить с тем, что скоро будет везде и без префиксов, чтобы вы могли в последний раз насладиться этим "костыльным" сапогом, который работает только в webkit:
1. filters
Позволяют применять простые фильтры как к изображениям, так и блокам (первое изображение - оригинал):
2. masking
Маскирование, тут всё понятно из названия и наглядно из примера ниже:
В целом ужасно хотелось бы посмотреть на css лет эдак через 5.
Станет ли он похож на язык программирования? Введут ли переменные? Что из яваскриптовых функций он перетащит в себя?
Пока ясно одно: не нужно бояться экспериментировать и не нужно тащить артефакты прошлого.
Сложность поддерживать префиксы
Если посмотреть на историю развития браузеров, то она будет пестрить и префиксами (с различными вариантам, вспомним фильтры в ie7 и ie8), и "чистыми" css-свойствами.Из-за этого разработчикам браузеров приходит поддерживать не только утвержденные свойства, но и свои, костыльные, с префиксами, при чем в последнем случае, если они действительно лоханулись с его пониманием (и соотв. реализацией, см. вариант 2), им придется поддерживать их неправильное поведение.
Хочу отметить, что эта сложность в первую очередь для разработчиков браузеров, а не для верстальщиков. Мы уже привыкли использовать less/sass, что даже не задумываемся о том, нуждается ли данное css-свойство в уточнении префиксом или нет. Мы пишем следующие конструкции и порой перегружаем код парой ненужных свойств:
@mixin experimental($property, $value) {
-webkit-#{$property}: $value;
-moz-#{$property}: $value;
-ms-#{$property}: $value;
-o-#{$property}: $value;
#{$property}: $value;
}
@mixin border-radius($radius) {
@include experimental(border-radius, $radius);
}
@mixin box-shadow($bs) {
@include experimental(box-shadow, #{$bs});
}
Будущее, в котором нет префиксов
Итак, что мы имеем на данных момент:Если посмотреть на те css3-свойства, которые мы уже сейчас используем: css3please.com, то станет ясно, что браузеры правильно и одинаково понимают их. А это значит, что мы развиваемся почти по 4-му идеальному варианту.
.box_gradient {
background-color: #444444;
background-image: -webkit-gradient(linear, left top, left bottom, from(#444444), to(#999999)); // Safari 4+, Chrome
background-image: -webkit-linear-gradient(top, #444444, #999999); // Chrome 10+, Safari 5.1+, iOS 5+
background-image: -moz-linear-gradient(top, #444444, #999999); // Firefox 3.6-15
background-image: -o-linear-gradient(top, #444444, #999999); // Opera 11.10-12.00
background-image: linear-gradient(to bottom, #444444, #999999); // Firefox 16+, IE10, Opera 12.50+
}Отличие составляют только префиксы-костыли. И я задаюсь вполне очевидным вопросом: может быть, стоит прекратить эту "войну" префиксов и начать внедрять очевидные свойства?
Новые свойства с префиксами? Fuuuuu!!!
Вебкит активнее других продолжает реализацию новых свойств, но со своей приставкой. Не за горами день, когда эти css-свойства станут нормой и префиксы, как изживший себя элемент, исчезнут навсегда.В завершении хотелось бы на примере фильтров и масок познакомить с тем, что скоро будет везде и без префиксов, чтобы вы могли в последний раз насладиться этим "костыльным" сапогом, который работает только в webkit:
1. filters
Позволяют применять простые фильтры как к изображениям, так и блокам (первое изображение - оригинал):
img { -webkit-filter: brightness(-30%); }
img { -webkit-filter: grayscale(100%); }
img { -webkit-filter: sepia(100%); }
img { -webkit-filter: blur(3px); }
img { -webkit-filter: invert(100%); }
2. masking
Маскирование, тут всё понятно из названия и наглядно из примера ниже:
.mask {
-webkit-mask-box-image: url(mask.png);
}
В целом ужасно хотелось бы посмотреть на css лет эдак через 5.
Станет ли он похож на язык программирования? Введут ли переменные? Что из яваскриптовых функций он перетащит в себя?
Пока ясно одно: не нужно бояться экспериментировать и не нужно тащить артефакты прошлого.
Комментарии