Содержание

Зачем нужны вендорные префиксы | Vaden Pro

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

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

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

Как их отличать?

Каждый движок, на котором написан браузер, имеет свой вендорный префикс.

Рассмотрим самые популярные браузеры и их префиксы. Те которые написанны на движке WebKit, а именно Safari выше третьей версии и GoogleChrome, считывают префикс -webkit-, а Safari до третьей версии

-khtml-, так как имеет в своей основе движок KHTML. Для Opera можно использовать следующие префиксы: -o-, -op-, -xv-. Firefox воспримет свойства имеющие приставку -moz-, а браузеры корпорации Microsoft те, перед которыми написано -ms-.

Как это выглядит на практике?

Рассмотрим на примере для свойства transition-duration:

-webkit-transition-duration:0.76s;	
-moz-transition-duration:0.76s;	
-o-transition-duration:0.76s; 
-ms-transition-duration:0.76s;
transition-duration:0.76s; 

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

Для чего это нужно?

Большинство производителей называют несколько причин, когда нужно использовать вендорные префиксы. Основные, из которых:

  • Свойство, которое было написано только для конкретного браузера и не содержится в стандартном списке css.
  • Свойство ещё разрабатывается или по каким-то причинам не имеет рекомендаций к использованию
  • Css задаёт только часть возможностей стиля.

Разработчики компании Microsoft, помимо выше перечисленных причин, при помощи своего вендорного префикса -ms-, прячут от валидатора те конструкции, которые его не пройдут.

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

Дополнительные возможности

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

Уже сейчас для верстки своих проектов можно исключить некоторые скрипты, заменив их стилями CSS.

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

Подводя итоги

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

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

Оценок: 25 (средняя 4 из 5)

  • 25668 просмотров

Понравилась статья? Расскажите о ней друзьям:

Курсы по CSS (в открытом доступе)

Уровень сложности:

Средний

Еще интересное

Префиксы поставщиков и их использование

Если вести речь о спецификациях CSS3-модулей, то либо их еще предстоит утвердить (чем занимается консорциум W3C), либо полностью реализовать все предлагаемые ими функции в браузерах, из-за чего поставщики браузеров используют для тестирования новых «экспериментальных» CSS-параметров префиксы поставщиков. Несмотря на то что это помогает разработчикам браузеров реализовывать новые CSS3-модули, нам, как занимающимся написанием CSS3-кода, это немного усложняет жизнь. Взгляните на приведенный далее код для создания скругленного угла:

.round{

-khtml-border-radius: 10px; /* Konqueror */

-rim-border-radius: 10px; /* RIM */

-ms-border-radius: 10px; /* Microsoft */

-o-border-radius: 10px; /* Opera */

-moz-border-radius: 10px; /* Mozilla (например, Firefox) */ — webkit-border-radius: 10px; /* Webkit (например, Safari и Chrome) */ border-radius: 10px; /* W3C */

}

В этом примере вы можете видеть свойства с префиксами поставщиков (причем это далеко не исчерпывающий список), каждое из которых обладает собственным уникальным префиксом, например — webkit-, что означает основанные на WebKit браузеры, или — ms- префикс такого поставщика, как Microsoft, подразумевающий Internet Explorer, и т. д. Из-за особенностей работы CSS браузер будет двигаться вниз по таблице стилей строка за строкой, применяя соответствующие свойства и игнорируя те, которые не может распознать.

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

ВЫРЕЗАННЫЕ ФРАГМЕНТЫ КОДА И JAVASCRIPT-РЕШЕНИЯ ДЛЯ БЫСТРОГО ДОБАВЛЕНИЯ ПРЕФИКСОВ CSS3.

Возможно, вам покажется удобным сохранять вырезанные фрагменты кода распространенных CSS3-правил, которые содержат все необходимые свойства с префиксами поставщиков. Таким образом, вы сможете просто вставлять их без необходимости заново печатать каждый раз. Во многих программах для редактирования кода (или интегрированных средах разработки (IDE — Integrated Development Environment), как их часто называют) имеется функция сохранения вырезанных сегментов кода и доступа к ним, которая при использовании CSS3 позволяет сэкономить массу времени. Кроме того, существуют JavaScript-решения, которые автоматически добавляют префиксы в CSS-файлы, и по адресу http://leaverou. github.com/prefixfree/ вы сможете отыскать прекрасное решение такого рода под названием — prefix-free.

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

.round{

-moz-border-radius: 10px; /* Mozilla (например, Firefox) */ — webkit-border-radius: 10px; /* Webkit (например, Safari и Chrome) */ border-radius: 10px; /* W3C */

}

В этом примере охватываются Firefox, Chrome, Safari и любые браузеры, которые полностью реализуют данное правило.

Я знаю, что вы думаете: «А разве указание версий одного и того же свойства, но с разными префиксами поставщиков не приведет к “раздутию” кода?» Что ж, приведет, но в небольшой степени. Независимо от того, сколько свойств с префиксами мы добавим, это все равно будет более быстрое, изящное и надежное решение, чем использование изображений.

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

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

КОГДА ИМЕННО МОЖНО ИСПОЛЬЗОВАТЬ ОПРЕДЕЛЕННЫЕ CSS3- И HTML5-ФУНКЦИИ?

Поскольку мы все больше и больше углубляемся в CSS3, я очень рекомендую вам посетить сайт http://caniuse.com. Он поможет, если вам когда-нибудь потребуется узнать текущий уровень поддержки браузерами определенной CSS3- или HTMLS-функции (рисунок 5.1). Помимо отображения версий браузеров, поддерживающих определенную функцию (которые можно выяснить, введя название этой функции), на этом веб-ресурсе приводится самая свежая глобальная статистика использования с сайта http://gs. statcounter.com.

Страница сайта When can I use.

Вам также могут быть интересны следующие статьи:

Онлайн сервис генерации префиксов для CSS свойств

Сегодня речь пойдет об онлайн сервисе для генерации CSS кода с префиксами. Пара слов о том, что такое префиксы в CSS свойствах, откуда они взялись и зачем их нужно ставить. Дело в том что современные возможности спецификации CSS2-3  внедрялись браузерами постепенно. Этот путь имеет поступательный характер и дабы дать своим пользователям новые возможности, браузеры внедряли эти свойства добавляя к ним свои особенные префиксы -webkit, -ms, -o, -moz.

Для не терпеливых ссылка на сервис: 

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

Следовательно мы приходим к пониманию того факта, что одна версия браузера может использовать свойство CSS без префиксов, в то время как более старая версия этого же браузера требует использование CSS префиксов для корректной работы свойства стилей. Проверить необходимость использования CSS префиксов для того или иного свойства стилей, можно на следующем полезном ресурсе: //caniuse.com, этот сайт я описывал в своем другом посте “Про поддержку HTML5” – в общем советую посмотреть этот ресурс.

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

Не долго я искал нужный мне сервис и найденное меня вполне устраивает 🙂

И так представляю вашему вниманию сервис по генерации префиксов для CSS свойств: ссылка (откроется в новом окне).

Что примечательно, так это интуитивно понятный интерфейс данного ресурса:

  1. Вставляем свой CSS код (без префиксов) в левую часть
  2. Справа получаем сгенерированный CSS код с автоматически добавленными свойствами с префиксами, которые проставлены на основании ваших требований по количеству поддерживаемых версий браузеров – этот параметр вы ставите в поле под цифрой три
  3. В этом поле ставим значения поддерживаемых версий браузеров. В моем примере число 3, означает что я хочу чтобы префиксы были проставлены на основании требований к трем последним версиям каждого браузера
  4. Это кнопка для удобства выделения полученного результата 🙂

 

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

Префиксы. Зачем и как правильно

Программный комитет еще не принял решения по этому докладу

Вадим Макеев: Добрый день! Я работаю в компании Opera Software, мы делаем разные браузеры. В своем докладе я буду не рекламировать какие-то крутые новинки, а расскажу о технологиях, которые мы используем повседневно. Поговорим о префиксах.

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

Что может быть проще стула? Если в реальной жизни нам нужен стул, требуется одно простое действие – взять и поставить его. Но многие из вас пишут код, и вы периодически замечали, что некоторые свойства приходится повторять. Если у вас есть свойство «стул», вам нужно написать «-о-стул», чтобы все это нормально отобразилось в Opera. Потом вам понадобится «-ms-стул», «-moz-стул» и «-webkit-стул». Получается нагромождение, и совершенно непонятно, что с ним делать. И сесть на такой «стул» нельзя, и переносить неудобно.

Если вы каждый день сталкиваетесь с префиксами, то, честно говоря, они портят вам жизнь. 99 % людей мечтает, чтобы они исчезли и никогда не появлялись. Отчасти они правы, отчасти нет. Я объясню, почему.

Что собой представляют префиксы? Префикс, как правило, ставится перед значимым элементом и указывает на определенный браузер или производителя какой-либо техники. Префиксов существует очень много. Они могут начинаться как с дефиса, так и с нижнего подчеркивания. Префиксы – появились не в CSS 3, где они используются для таких вещей как градиент или “border-radius”, а еще в CSS 2.1. Это один из способов расширить CSS, добавляя туда собственные свойства, которые впоследствии можно стандартизировать.

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

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

Откуда вообще берутся префиксы? Давайте представим такую историю…

Где-то в Калифорнии, в Силиконовой долине утром просыпается разработчик webkit. Может быть, в офисе Google он заснул – бывает, трудоголики с работы не уходят. И во сне этому разработчику пришла идея свойства “lol-cat”. Он подумал, что классным значением для этого свойства будет вот такой милый смайлик.

«Надо бы внедрить это свойство», — решает разработчик. Но свойство нельзя внедрять в том виде, в котором оно ему приснилось. Сначала он должен спрятать его за пространством имен webkit.

Через некоторое время в Европе просыпаются разработчики из компании Mozilla. Они говорят: «Ага, ребята из Калифорнии придумали классное свойство “lol-cat”, давайте-ка мы тоже что-то придумаем. На самом деле, у нас в Европе принято другие смайлики рисовать. Поэтому нам нужно сделать другое значение!» И они вместо «домиков» делают «кругляшки». Кот у нас получается менее счастливым – может, он француз?

Но это неважно. Важно, что разработчики в Европе считают, что значение у свойства должно быть другим. Они очень вовремя добавляют префикс «-moz-», чтобы это свойство ни с чем не конфликтовало, чтобы только их браузер «понимал» это свойство и его значение. Браузер Mozilla префиксы «-moz-» «понимает».

Потом дело доходит до Норвегии, где нашего «кота» захотели сделать удивленным, и придумали свойству ещё одно значение.

Просто у каждого разработчика есть свое мнение относительно того, как все должно быть. Именно поэтому у нас был адский ад лет 10-15 назад – как раз из-за того, что разработчики не могли договориться друг с другом. Это нормальный процесс, это конкуренция. Есть масса людей, каждый из которых создает что-то, что, по его мнению, будет работать лучше. Для тех, кто живет в Калифорнии, лучше оказываются одни вещи, а для тех, кто живет в Европе, — другие.

Префиксы позволяют «прятать» все эти различия под браузерными пространствами имен и не мешать друг другу.

Но проходит полгода или год, проходит два года, три года, пять лет, и просыпаются разработчики из Консорциума всемирной паутины (W3C). Они говорят: «Никаких смайликов в значении не будет. У нас там будет стоять слово “smile”, потому что оно читаемо, понятно представителям всех культур и выглядит серьезно».

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

Допустим, у нас есть свойство “box-shadow”. Когда совместимость была неполной, нам был нужен префикс. Мы писали вот так. Но это неправильно. Казалось бы, это естественно: пирамида должна стоять на самой широкой грани, чтобы быть устойчивой. Сначала идет “box-shadow”, потом “-moz- box-shadow”, затем “webkit-box-shadow”. Казалось бы, какая разница, в каком порядке свойства записывать, все равно каждое свойство адресуется каждому браузеру. Если ПО «понимает» свойство без префикса, оно «поймет» его без префикса, если оно «понимает» webkit, то оно «поймет» webkit. Но нет, все должно быть вот в таком порядке.

«Пирамида» должна «висеть» острием вниз. Необязательно, чтобы сначала шла часть с “webkit-…”, а потом часть с “-moz-”, их можно поменять местами. Главное, чтобы свойство “box-shadow” шло последним. Организация ровной «пирамиды» просто помогает визуально определить, все ли у вас в порядке с префиксами.

Зачем это вообще нужно? Представьте, что производители браузеров не успели отказаться от префиксов. Допустим, webkit-браузеры практически не отбрасывают префиксы, у них такая политика. То есть они сознательно не поступают так, как им рекомендует W3C. Думаю, они не делают этого потому, что есть старые версии iTunes, которые частично используют webkit, и надо, чтобы они справлялись с рендерингом страниц.

В итоге браузер, который сделал нормальную реализацию свойства, применит “smile”. А если это Mozilla Firefox, он дойдет до свойства с префиксом “-moz-”, то он может после правильного “smile” применить старое значение – возникнет ошибка. Если в браузере реализовано 2 типа свойств (с префиксом и без него), то будут применены те свойство и значение, которые расположены последними. Поэтому в конце должно стоять новое свойство без префикса.

Это главное правило, которое нужно знать при использовании префиксов. Многие этого не понимают. Свойство без префикса идет последним.

Кто-то может задать вопрос: иначе что? Я покажу, что произойдет в этом случае. Допустим, у элемента есть свойство “webkit-box-shadow”, размер тени 400 пикселей, отступ от центра 200 пикселей, тень черного цвета. Есть свойство “box-shadow” с теми же самыми значениями, они абсолютно одинаковы. Вот в таком порядке мы их записали – сначала с префиксом, потом без.

Текущий Chrome или Safari рендерят это вот так.

У нас есть блок нулевых размеров, к которому применена такая тень. Если мы поменяем порядок свойств (сначала свойство без префикса, а потом свойство с префиксом), то у нас получится вот что.

Рендеринг тени зависит от порядка свойств, потому что под версией без префикса «спрятана» более качественная и совместимая реализация. Возможно, она даже быстрее работает. Но главная ее ценность в том, что она совместима с другими браузерами.

То есть во всех браузерах будет вот такая хорошая тень.

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

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

Что можно порекомендовать при работе с префиксами? У нас есть множество свойств для разных старых браузеров. Если вы делаете градиенты, применяете “transform”, “transition origin”, кода становится очень много. Есть варианты того, как этого можно избежать.

Самый интересный вариант из тех, что мне попадались за последнее время, это Prefix Free. Лия Веру, которая тоже выступала здесь на конференции РИТ++, написала JavaScript-библиотеку, которая находит свойства без префиксов и добавляет к ним префиксные свойства, притом не все, а только необходимые.

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

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

Допустим, если вы делаете какой-то JS-fiddle, чтобы быстро посмотреть, как работает ваш код, такая библиотека будет идеальным вариантом. Лия Веру даже создала свой сервис для просмотра демонстраций – Tablet.Com. Там используется эта библиотека. Если вы напишите там градиент без префиксов, он заработает во всех браузерах, потому что библиотека автоматически его подставит.

Это быстрое JavaScript-решение. Для серьезных вещей оно не годится. Для них используются препроцессоры. Связка Sass и Compass работает на Ruby, они просто запускаются на локальной машине и обрабатывают ваши файлы. Less и Stylus могут работать как в качестве запущенных скриптов с чтением из файлов, так и при подключении в браузере. Это позволяет легко выполнять отладку без необходимости каждый раз переписывать файлы заново. Но у них есть некоторые особенности.

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

Начнем с Compass. Compass позволяет писать свойства в двух нотациях. Через «собаку» — @include border-radius, также можно писать свойство через знак «плюс», что заодно поможет отказаться от фигурных скобок. В обоих случаях мы получим добавление префиксов для данного свойства. Это позволит получить и “-webkit-border-radius”, и “-moz-border-radius”, и так далее. Значение вы указываете тут же.

Какие провалы есть у Compass? Когда Compass добавляет префиксы, у нас появляются 2 свойства, которых не существует в природе. Их никогда не было и никогда не будет. Свойства “-o-border-radius” и “-ms-border-radius” не нужны в принципе. У нас есть избыточность в виде 2 лишних строк кода. Создатели не потратили лишних полчаса, чтобы изучить, какие свойства действительно нужно разворачивать. Modernizer, кстати, отказался от свойств khtml, потому что браузера под Linux, из идеи которого «родился» webkit, не существует. Разработчики khtml сами сказали, что будут использовать последний webkit для своего браузера Conqueror. Таким образом, три свойства с префиксами, которые предлагает Compass, лишние.

Какие еще провалы Compass стоит упомянуть? Забыт префикс “-ms-“ для свойств “transform” и “transition. У свойства “box-shadow” масса ненужных префиксов. Есть ненужный префикс “-o-“ для свойства “column”, которое делает несколько колонок. Для свойства “background-size” тоже есть ненужный префикс “-o-“, мы его поддерживаем без префикса. Если вы используете в коде “opacity”, Compass автоматически понапишет там “filter:progid:DXImage…”, причем он использует старую и невалидную версию, без “-ms-filter-…”, без кавычек и так далее. Ваш код будет испорчен.

Кстати, на поиск всех этих ошибок у меня ушло не более 15 минут. Не знаю, сколько времени нужно, чтобы их поправить. Минут 10, наверное. Несмотря на все ошибки, это по-прежнему одна из самых популярных библиотек для работы с префиксами.

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

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

Stylus – это, на мой взгляд, самый гибкий из существующих препроцессоров. Это одна из самых адекватных библиотек для работы с префиксами, потому что она позволяет писать код очень гибко. Можно использовать массу нотаций, убирать фигурные скобки, точки с запятой, объявлять переменные без всяких префиксов. В моем примере “fonts” – это переменная, не нужно значка доллара, подчеркиваний или еще чего-то. Просто пишете «равно» и можете эту переменную дальше использовать.

Stylus – самый «молодой» препроцессор. В нем есть проблемы. Например, если вы поставите такие скобки, все поломается. Я «отбиваю» последнюю скобку, мне удобнее читать код, когда скобка «отбита». А здесь получается так: «отбил» скобку – сломал целый файл. Это несерьезно, хотя в остальном библиотека хорошая. Всем, кто делает такие библиотеки, советую писать пул запросов.

Префиксы можно использовать не только в CSS, но и в JavaScript. Если у вас есть какая-то анимация, например.

Как мы привыкли работать со свойствами в JavaScript? Если свойство состоит из двух слов, разделенных дефисом, мы берем и убираем дефис, а следующую букву делаем заглавной. Это называется «верблюдизацией» (Lower Camel Case), то есть первая буква строчная, а все остальные буквы заглавные. Это много где описано, мы привыкли работать с этим.

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

По идее, все просто. Надо написать несколько строк кода, чтобы свойства заработали во всех браузерах. Допустим, нам нужно задать Transition Timing Function.

На первый взгляд, все нормально. Тестируем в браузере… Строки для префиксов “-moz-“ и “-o-“ не работают. Само свойство браузер поддерживает, но строки не работают.

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

Тогда перестает работать строка, начинающаяся с “Ms” для IE.

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

А по факту в браузерах есть различия. Mozilla и Opera буквально следуют спецификации,  Firefox и Opera «понимают» префиксы только тогда, когда первая буква прописная. Internet Explorer «понимаeт» их только тогда, когда первая буква строчная. Webkit «понимаeт» оба варианта.

Тем не менее, написанная только прописными буквами строка GETELEMENTBYID в JavaScript не сработает. Появляются какие-то двойные стандарты: в одном месте есть гибкость, в другом ее нет. Почему бы не сделать JavaScript независимым от регистра?

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

Грядет страшное!

А сейчас я вынужден предупредить вас о том, что скоро все будет очень плохо. Opera, Mozilla и Microsoft собираются поддерживать свойства с префиксом “-webkit-”. Компания Mozilla заявила об этом. Они в этом заинтересованы, потому что им кажется, что их игнорируют разработчики, пишущие для iPhone. Opera и Microsoft тоже заинтересовались поддержкой этого префикса. На мероприятии CSS Working Group это обсуждалось. Возможно, я сейчас выдаю инсайдерскую информацию, но этот вопрос уже решен. Это случится очень скоро.

Безусловно, когда мы начнем поддерживать свойства с префиксом “-webkit-”, мы выпустим тестовую сборку, чтобы все могли проверить, что «отвалится» у них на сайтах, что начнет работать лучше, и так далее.

На самом деле, это не просто какая-то вольность. Было проведено специальное исследование. Аналитики компании Alexa взяли Топ 100 сайтов по всему миру и посчитали, какие свойства там используются. Свойств “-webkit-box-shadow” оказалось почти 800 штук. Свойств “-moz-border-radius” чуть меньше, “- webkit-border-radius» практически столько же. Дальше уже разрыв гораздо больше. Тут нет ни свойств Opera, почти нет свойств Microsoft Internet Explorer.

На диаграмме в процентном содержании показано распределение свойств, которые в целом используют разработчики. То есть про “-moz-» помнят, про “-webkit-” помнят, а про “-o-» и “-ms-» практически никогда не помнят, даже если браузер поддерживает эти свойства.

Поэтому нужно что-то делать. У нас в компании есть целый отдел Open Relations, там идет работа над проектом “Open the Web», где люди занимаются тем, что пишут разработчикам: «Пожалуйста, не блокируйте Opera! Мы поддерживаем это свойство. Напишите строчку кода!» А разработчики нам отвечают: «Да? А мы думали, что Opera – это мобильный браузер… Окей!» Иногда они не соглашаются, ссылаясь на малую распространенность Opera. Да, наш браузер по-разному распространен в разных регионах мира, но это не повод не давать ему то, что он может «понять»!

Поэтому и мы, и компания Mozilla (которую упоминают часто), решили заняться этим сомнительным делом с поддержкой свойств “-webkit-”. Возможно, от этого многое поломается, но многое и исправится.

Мы уже делали так раньше. Посмотрите любой User Agent браузера – что там написано? Там написано “like Mozilla”, то есть все идентично. Это способ сделать User Agent совместимым с сайтами, которые его проверяют и так далее. Сейчас User Agent каждого браузера представляет собой «кашу». Там множество строк, которые отвечают только за то, чтобы старые сайты не сломались. Долгое время браузеры поддерживали “document.all”, некоторые до сих пор его поддерживают. Если вы протестируете поддержку “document.all”, мы скажем, что ее нет, а если мы ей воспользуемся, окажется, что она будет. Для обратной совместимости.

Будут поддерживаться не все свойства “-webkit-”, а только избранные и нужные. Если мы пока не поддерживаем 3D-трансформацию (над этим наши специалисты пока работают), мы не будем делать вид, что мы ее поддерживаем. Будут поддерживаться только те свойства, которые «понимает» наш браузер, те, которые улучшат совместимость.

Если сейчас через Opera Mobile зайти на сайт, сделанный для iPhone, окажется, что у нас белый текст на белом фоне.

Если автоматически добавить нужные префиксы каким-то простым скриптом, все будет работать хорошо, — будет черный текст на синем фоне, например.

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

Свойства “-webkit-” будут применяться только в случае отсутствия свойств для Opera. Если будут найдены свойства для Opera, они будут применяться прежде всего. Каскады будут сохраняться, сайты для iPhone заработают.

Я предчувствую, что что-нибудь обязательно сломается. Поэтому мы при начале поддержки свойств “-webkit-” постараемся сообщить об этом всем. Нужно, чтобы все успели протестировать свои сайты.

Может случиться еще кое-что другое. Недавно я говорил с человеком из CSS Working Group, который занимается в том числе и спецификациями, он мой коллега. Он рассказал, что в CSS Working Group есть и другая идея относительно работы с префиксами. Объясню на примере.

Браузер «икс» внедрил свойство “lol-cat:smile” без префикса, но в какой-то момент обнаружилась ошибка. Чтобы исправить эту ошибку, он внедрит исправленную версию этого свойства с префиксом. Тогда разработчики смогут исправить ошибку, использовав префикс.

Как видно из примера, порядок свойств здесь другой. Текущий подход предполагает использование «пирамиды» острием вниз, а подход, который, возможно, предложит CSS Working Group, предлагает другую «пирамиду» — острием вверх. Так что неизвестно, что будет считаться правильным в перспективе. Пока правильно то, о чем я говорил в начале доклада. Что будет через год, два или три, мы не знаем. Префиксы не дадут нам заскучать. Помните главное: свойство без префикса идет последним.

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

Большое вам спасибо за внимание. Жду вопросов.

Вопросы и ответы

Реплика из зала: Привет. Хочу сделать комментарий. Начну с того, что “khtml” был давно убран из  Compass , а “transform” был исправлен. Opacity с префиксами не работает уже, их не нужно добавлять.

Вадим Макеев: Там с opacity проблема в том, что добавляется невалидный CSS-код.

Реплика из зала: Этот невалидный CSS-код нужен, чтобы поддерживался старый IE.

Вадим Макеев: Все, понял.

Вопрос из зала: Вопрос про другое. Есть ли какие-нибудь идеи (может быть, ты их знаешь), почему-то их не внедряют… Почему бы не сделать общий префикс для всех браузеров, например, “-beta-“ и оставить префиксы для всех браузеров на случай, если какие-то браузеры реализуют это свойство неправильно?

Вадим Макеев: Тогда тебе в коде придется писать не 6, а 7 строк.

Реплика из зала: Но большинство свойств реализовано всеми браузерами одинаково.

Вадим Макеев: Понимаешь, если у тебя какой-то крупный проект, и тебе важна полная совместимость, ты будешь писать все свойства… То есть ты предлагаешь эту ситуацию еще больше ухудшить…

Реплика из зала: Но потом-то будет лучше, когда «умрут» старые браузеры, которые не поддерживали общий префикс…

Вадим Макеев: На самом деле, таких дискуссий очень много. Главная идея, с которой согласны все: префиксы в текущем состоянии всех «достали». С этим нужно что-то делать. Есть еще потрясающий аргумент: префиксы – это экспериментальные свойства. У вас стабильный проект, зачем ему экспериментальные свойства? Мы вежливо улыбаемся ребятам из W3C и говорим: «Конечно, вы молодцы, что пишете спецификации, но сайты вы хоть раз разрабатывали?» Дискуссий много. Я рассказал о том, что есть. О том, что будет, я не могу рассказать. Я не гадалка.

Реплика из зала: Я, например, стараюсь писать префиксы вручную и быть в курсе, что сейчас где используется…

Вадим Макеев: Таких, как ты, мало.

Вопрос из зала: Штука в том, что помнить об этом и следить за изменениями не всегда просто и не всегда нужно. На самом деле, нас еще в университете учили, что не нужно ничего запоминать. Нужно думать и искать информацию.  Сейчас для того, чтобы найти список актуальных префиксов, нужно перебрать примерно пять статей, хорошенько «полазить» по сайтам производителей… Не было ли когда-нибудь мысли создать сводный проект по префиксам, где можно будет посмотреть, в каких версиях движков что работает или не работает? Просто хочется знать, что поддерживается…

Вадим Макеев: Нужно «перелопатить» огромное количество данных. В последнее время на Западе очень популярны проекты типа «Все свойства такого-то браузера», «Все префиксы такого-то браузера», поддержка CSS 3, HTML 5, и так далее. Сейчас много таких проектов. Не удивлюсь, если в какой-то момент появится и то, о чем вы говорите. Есть парочка страниц, на которых собираются все свойства с префиксами всех известных браузеров. Две из них я знаю. Ссылок на них я не давал, но их можно найти довольно легко. Сводного проекта нет, но я бы с удовольствием поучаствовал в его создании.

Реплика из зала: Я бы тоже хотел поучаствовать в его создании. Есть основной момент… Собирать эти свойства с каких-то посторонних страниц крайне неприятно. Скажи, насколько возможно общение непосредственно с производителями браузеров, привлечение их к участию в таком проекте? Или хотя бы «вытягивать» данные из конкретных мест, где они будут их размещать.

Вадим Макеев: Я так понимаю, что ты бы хотел, чтобы сами производители браузеров выкладывали какой-нибудь файл XML или JSON со всеми префиксами? Это будет слишком накладно, мы же все очень занятые люди. Но я знаю, кого дернуть за рукав, чтобы получить актуальные списки – в принципе, это реально. Но вот обновлять их все-таки придется вручную.

Вопрос из зала: Что ты имеешь в виду? Придется каждый раз запрашивать у специалиста список, или в каком-то виде на каком-то ресурсе этот список будет фигурировать?

Вадим Макеев: Допустим, у нас есть страница, на которой есть все свойства с префиксами.

Реплика из зала: Вы практически святые в этом плане. Не стоит обобщать.

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

Реплика из зала: Ок.

Реплика из зала: Кстати, насчет гордости за документацию: мои переводы вы так и не опубликовали!

Вадим Макеев:  Мы с вами свяжемся!

Реплика из зала: По поводу единого сайта, где указаны все префиксы… На сайте Mozilla Developer Center всегда указаны префиксы и версии, в которых все это работает. Единственное исключение – там практически не показана информация для каких-то технологий, которые не работают в  Mozilla, но их достаточно мало.

Вадим Макеев:  На самом деле, самый простой способ найти префиксы прямо сейчас – это зайти на сайт webstandards.ru и ввести в строке поиска слово «префиксы». Примерно полгода или год назад мы писали новость со ссылками на страницы, где описаны все браузерные префиксы. Еще вопросы?

Вопрос из зала: Когда Opera начнет префиксы webkit, она будет поддерживать их так, как это у вас уже реализовано, или так, как это реализовано в webkit?

Вадим Макеев: Нет, мы просто будем «мапить» существующие свойства на свойства webkit. Есть еще один момент… Мы сейчас работаем над новой спецификацией Flexbox, она уже настолько финализирована, что ее можно внедрять. За последние полгода ее переписали практически с нуля. Там есть общие слова, но суть там очень сильно поменялась. Когда мы внедрим новую спецификацию Flexbox, мы посмотрим сайты и, возможно, сделаем совместимость со старой. Мы не просто будем реализовывать спецификацию, а «замапим» нужные свойства в виде ссылки.

Допустим, вы пишете какой-нибудь webkit Flexbox или просто Flexbox в старой нотации, а он раз – и начинает работать по спецификации. Мы не будем писать вторую реализацию, не будем «форкать».

Реплика из зала: У меня не вопрос, а небольшое предостережение. Вы компетентный специалист, и в вашем докладе прозвучали нотки антиагитации против использования Less и других подобных инструментов, правильно? Было такое, пусть и в неявном виде. А инструмент хороший, просто в нем есть некоторые нюансы, которые вы перечислили. Но сам инструмент очень облегчает жизнь. Я смотрел в исходники Less. На первых порах было много проблем с парсингом CSS, были какие-то ошибки, нельзя было вставить комментарии внутрь значения CSS-свойства. Все «валилось», да и сейчас так, по-моему. Вся проблема Less в том, что они разбирают CSS регулярными выражениями. Наверное, остальные препроцессоры работают сходным образом. А это, по-моему, абсолютно неправильно. У CSS слишком сложная структура для того, чтобы разбирать его на регулярные выражения.

Вадим Макеев: У молодого человека, который с микрофоном ходит, есть проект CSScomb, который разбирает CSS не регулярными выражениями, а построчно. Не просто пытается понять, как CSS работает, но разбирает его на какие-то простые структуры.

Реплика из зала: На простые структуры можно разбить CSS, описав CSS в виде БНФ, то есть формы Бэкуса-Наура. В Mozilla Developer Network все спецификации в виде псевдо-БНФ… Если так описать, то будет очень гибкий инструмент для анализа и трансформации CSS.

Вадим Макеев: Если там написано выражение (англ. expression), в которое вставляется таблица… Да?

Реплика из зала: Как раз SCSS под проекты SASS (оперативный синтаксис, совместимый с CSS) не использует регулярные выражения, он честно все парсит, и когда он вышел, было заявлено, что его парсер справится с любым валидным CSS-документом, включая невалидные расширения для IE.

Вадим Макеев: То есть если там «закавычена» таблица на 300 строк, он не сломается?

Реплика из зала: Если это нормально обрабатывается в браузерах, то проблем не будет.

Вопрос из зала: У меня вопрос: почему вы не перейдете на движок webkit?

Вадим Макеев: Тема слишком обширна. Попробую ответить кратко. Потому, что это не имеет смысла вообще. Нам придется уволить всех наших инженеров. Впрочем, есть более важный аспект. Я не с того пункта начал. Проект webkit контролируется компаниями Apple и Google. Чтобы получить право отправлять обновления (англ. commit) в основное ядро проекта, нужно иметь проверяющих (англ. reviewer) где-нибудь в Калифорнии, платить им как вице-президентам нефтяных компаний. Также стоит иметь в виду, что 90 % проверяющих ядра webkit связаны с Apple и Google. Все, что им не понравится, они будут отклонять. Чтобы начать разрабатывать движок, нельзя просто «форкнуть» Google и начать его писать. Это кажется классным и интересным. Но это повлечет за собой огромное количество проблем. Мы обсуждали эту возможность, это адекватно. Мы не хотим поддерживать что-то свое, но плохое. Мы хотим, чтобы пользователям было удобно. Но для того, чтобы им было удобно, мы должны иметь возможность гибко разрабатывать то, что мы хотим. Переход на webkit нам этой гибкости не даст. Мы просто разоримся.

Реплика из зала: У меня не вопрос, а замечание по поводу дискуссии о webkit и так далее. Я ещё помню времена, когда очень распространенным браузером был IE5. Монополия движка какого-то одного браузера ни к чему хорошему не приводит. Сейчас прекрасное время. Конкуренция дает массу преимуществ. Мы сейчас ими пользуемся, и будем пользоваться еще достаточно долго. Хорошо, что у нас есть разные браузеры. Здорово, что они продолжают появляться и что они делают друг друга лучше. 

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.

Префиксы конкретных браузеров. CSS3 для веб-дизайнеров

Читайте также

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

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

Запасной вариант для всех браузеров

Запасной вариант для всех браузеров Браузеры, которые пока что не поддерживают множественные фоны, проигнорируют свойство background целиком. Вот почему мы определили свойство background-color отдельно.На рис. 5.05 показано, как сайт выглядит в IE7: множественные фоны игнорируются, и

А как насчет других браузеров?

А как насчет других браузеров? Открывая форму в Internet Explorer 7 – браузере с нулевой поддержкой CSS3, – мы видим вполне приемлемую рабочую форму (рис. 6.15). Это замечательно! Все улучшения, добавленные свойствами CSS3, были проигнорированы; остался скелет формы, работающий так, как

А как насчет остальных браузеров?

А как насчет остальных браузеров? Добавление CSS-анимации – это первый раз в этой книге – когда мы улучшали пользовательский опыт только для одного производителя браузеров: WebKit. Одна из основных причин, по которой CSS3 используется все больше и больше, – новые свойства

Преобразование документов XML при помощи браузеров

Преобразование документов XML при помощи браузеров Поддержка XSLT включена и в Microsoft Internet Explorer, и в Netscape Navigator. Из этих двух браузеров Internet Explorer обладает гораздо большей поддержкой XSLT, и здесь я буду использовать версию 5.5 этого браузера. О поддержке XSLT в Internet Explorer вы можете

8.2. Несколько советов для браузеров

8.2. Несколько советов для браузеров Ускоряем загрузку страниц в Firefox 3 В Firefox можно увеличить скорость загрузки и отображения страниц, значительно повысив комфортность работы в Интернете. Что для этого нужно сделать:Открыть страничку настроек, набрав в адресной строке

Как искать в Интернете информацию о конкретных людях

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

6.4.3. Специальные возможности браузеров

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

12.3. Разрешение и блокировка конкретных программ

12.3. Разрешение и блокировка конкретных программ Еще один очень эффективный способ ограничить доступ к программам – это создание списка программ, которые можно запускать. Все программы, которые не попали в этот список, соответственно, запускать запрещено.Чтобы получить

Шаг 2. Advanced Новичок. Опыт работы <= 0,5 года. Знания в рамках школьных и институтских курсов информатики + полученные на работе навыки решения конкретных задач.

Шаг 2. Advanced Новичок. Опыт работы &lt;= 0,5 года. Знания в рамках школьных и институтских курсов информатики + полученные на работе навыки решения конкретных задач. Этот период охватывает промежуток времени от получения предложения о работе до окончания испытательного срока.

Использование браузеров

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

Дополнительные возможности браузеров

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

49. Оптимизация для конкретных моделей процессоров

49. Оптимизация для конкретных моделей процессоров Если некоторая программа будет работать на компьютерах со строго определенными моделями процессоров, можно попытаться применить ориентированные на определенные модели процессоров команды.Многие из новых команд дают

Opera наверстала отставание от других браузеров Андрей Письменный

Opera наверстала отставание от других браузеров Андрей Письменный Бета-версия браузера Opera 10.50 снабжена совершенно новым интерпретатором языка JavaScript. Он называется Carakan и работает значительно быстрее, чем прежние версии. Это означает, что Opera, наконец, догнала прочие

7 альтернативных браузеров для iPad Олег Нечай

7 альтернативных браузеров для iPad Олег Нечай Опубликовано 15 мая 2014 Строго говоря, для iOS существует только один полноценный браузер — Safari. Все альтернативы — это фактически графические надстройки и наборы Java-скриптов для движка с открытым

Opera наверстала отставание от других браузеров

Opera наверстала отставание от других браузеров Автор: Андрей ПисьменныйОпубликовано 22 марта 2010 годаБета-версия браузера Opera 10.50 снабжена совершенно новым интерпретатором языка JavaScript. Он называется Carakan и работает значительно быстрее, чем прежние версии. Это означает, что

Вендорные префиксы в CSS

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

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

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

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

-webkit-flexbox

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

-webkit-transforms

-webkit-transitions

-webkit-appearance

-webkit-background-clip

-webkit-device-pixel-ratio

-webkit-animation

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

-webkit-border*

Некоторые другие свойства могут быть в @-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 браузерах.

Автор: Patrick Catanzariti

Источник: //www.sitepoint.com/

Редакция: Команда webformyself.

Практический курс по верстке адаптивного сайта с нуля!

Изучите курс и узнайте, как верстать современные сайты на HTML5 и CSS3

Узнать подробнее

Верстка. Быстрый старт

Практический курс по верстке адаптивного сайта с нуля!

Смотреть

Что такое префиксы поставщика CSS или префиксы браузера?

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

KTSDESIGN/Science Photo Library/Getty Images

Происхождение префиксов поставщиков

Когда CCS3 впервые был представлен, ряд интересных свойств начал появляться в разных браузерах в разное время. Например, браузеры на основе Webkit (Safari и Chrome) были первыми, в которых были представлены некоторые свойства стиля анимации, такие как преобразование и переход. Используя свойства с префиксом поставщика, веб-дизайнеры могли использовать эти новые функции в своей работе и сразу же отображать их в браузерах, которые их поддерживали, вместо того, чтобы ждать, пока другие производители браузеров догонят их!

Общие префиксы

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

Префиксы браузера CSS, которые вы можете использовать (каждый из которых специфичен для другого браузера):

  • Android:
      -Webkit-
    • Chrome:
       -Webkit- 
    • Firefox:
       -Moz- 
    • Internet Explorer:
       -MS- 
    • IOS:
       -Webkit- 
    • Opera:
       -o- 
    • Safari:
       -webkit- 

    Добавление префикса

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

    -webkit-transition: все 4 легко; 
    -moz-transition: все четвёрки облегчаются;
    -ms-transition: все 4 легко;
    -o-transition: все 4 облегчаются;
    переход: легкость всех 4-х;
    класс=»ql-синтаксис»>

    Помните, что в некоторых браузерах синтаксис определенных свойств отличается от других, поэтому не думайте, что версия свойства с префиксом браузера точно такая же, как и стандартное свойство.Например, чтобы создать градиент CSS, вы используете свойство linear-gradient. Firefox, Opera и современные версии Chrome и Safari используют это свойство с соответствующим префиксом, в то время как ранние версии Chrome и Safari используют свойство с префиксом -webkit-gradient.

    Кроме того, Firefox использует значения, отличные от стандартных.

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

    Префиксы поставщиков не являются взломом

    Когда префиксы поставщиков были впервые введены, многие веб-профессионалы задавались вопросом, были ли они хаком или возвратом к темным дням разветвления кода веб-сайта для поддержки разных браузеров (помните, что сообщение « Этот сайт лучше всего просматривать в IE »).Однако префиксы поставщиков CSS не являются хаками, и у вас не должно быть сомнений относительно их использования в вашей работе.

    Хак CSS использует недостатки в реализации другого элемента или свойства, чтобы заставить другое свойство работать правильно. Например, взлом блочной модели использовал недостатки в анализе семейства голосов или в том, как браузеры анализируют обратную косую черту \. Но эти хаки были использованы для устранения проблемы разницы между тем, как Internet Explorer 5.5 обрабатывал блочную модель, и как ее интерпретировал Netscape, и не имеют ничего общего со стилем семейства голосов.К счастью, в наши дни нам не нужно беспокоиться об этих двух устаревших браузерах.

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

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

    Префиксы поставщиков раздражают, но являются временными

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

    -moz-border-radius: 10px 5px; 
    -webkit-border-top-left-radius: 10px;
    -webkit-border-top-right-radius: 5px;
    -webkit-border-bottom-right-radius: 10px;
    -webkit-border-bottom-left-radius: 5px;
    радиус границы: 10px 5px;

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

    радиус границы: 10px 5px; 

    Chrome поддерживает свойство CSS3, начиная с версии 5.0, Firefox добавил его в версии 4.0, Safari добавил его в 5.0, Opera в 10.5, iOS в 4.0 и Android в 2.1. Даже Internet Explorer 9 поддерживает его без префикса (а IE 8 и более ранние версии не поддерживали его ни с префиксами, ни без них).

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

    Префиксы поставщиков CSS

    Присоединяйтесь к полнофункциональному учебному лагерю веб-разработчиков 2022 года!


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

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

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

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

    Тем не менее, давайте посмотрим, что такое префиксы поставщиков.

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

      .мои занятия {
    -webkit-transition: все 1с линейные;
    -moz-переход: все 1с линейные;
    -ms-переход: все 1с линейные;
    -о-переход: все единицы линейные;
    переход: все единицы линейные;
    }  

    Теперь вы просто используете

      .мой класс {
    переход: все единицы линейные;
    }  

    , так как это свойство теперь хорошо поддерживается всеми современными браузерами.

    Используемые префиксы:

    • -webkit- (Chrome, Safari, iOS Safari / iOS WebView, Android)
    • -moz- (Firefox)
    • -ms- (пограничный, Internet Explorer)
    • -o- (Опера, Опера Мини)

    Поскольку Opera и Edge основаны на Chromium, -o- и -ms- , вероятно, скоро выйдут из моды.Но, как мы уже говорили, вендорные префиксы в целом тоже выходят из моды.

    Написание префиксов затруднено, в основном из-за неопределенности. Вам действительно нужен префикс для одного свойства? Некоторые онлайн-ресурсы также устарели, что еще больше усложняет работу. Такие проекты, как Autoprefixer, могут полностью автоматизировать процесс, и нам не нужно выяснять, нужен ли префикс больше, или функция теперь стабильна, и префикс следует удалить. Он использует данные с caniuse.com, очень хорошего справочного сайта по всем вопросам, связанным с поддержкой браузеров.

    Если вы используете React или Vue, такие проекты, как create-react-app и Vue CLI, два распространенных способа начать создание приложения, используйте автопрефиксер из коробки, так что вам даже не придется об этом беспокоиться .

    Префикс поставщика мертв? | CSS-трюки

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

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

    К 2012 году рабочая группа W3C CSS выпустила руководство по использованию префиксов поставщиков:

    .

    В CSS мы используем префиксы поставщиков для свойств, значений, @-правил, которые:1), или – экспериментальные реализации (согласно CSS Snapshot 2010) (например, в рабочих проектах)

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

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

    Чтобы ответить на этот вопрос, я проанализировал набор данных caniuse и набор данных Mozilla Developer Network Compat.

    Тенденции принятия

    На приведенной выше диаграмме можно увидеть тенденцию реализации префиксных функций в основных браузерах. Я исключил Chrome для Android из-за недостаточности данных.

    С 2007 по 2011 год количество функций с префиксом во всех браузерах неуклонно росло.В Internet Explorer наблюдался всплеск только в 2011 году. Затем, в 2012 году, Mozilla начала удалять функции с префиксами , такие как -moz-border-radius* и -moz-box-shadow  — из Firefox. После этого они последовательно удаляли свойства с префиксами, как только стандартная версия этого свойства была полностью реализована.

    В 2013 году Mozilla начала делать функции доступными за флагами функций (предварительные флаги). В том же году Chrome переключил свой движок рендеринга с WebKit на Blink (часть проекта Chromium).Это был большой поворотный момент в удалении некоторых префиксных функций.

    Только в апреле 2016 года WebKit объявил, что больше не будет выпускать экспериментальные функции с префиксами:

    .

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

    Поскольку браузеры Safari и iOS всегда использовали движок рендеринга WebKit, последовательное сокращение количества префиксов появилось позже в этих браузерах.

    Microsoft никогда не увлекалась префиксами и всегда имела наименьшее количество функций с префиксами. В 2019 году Edge перешел с собственного движка рендеринга на Blink. Забавно, что это изменение фактически увеличило количество префиксных свойств в Edge!

    Особенности трендов

    В приведенной ниже таблице сравниваются функции с префиксами в 2013 году (расцвет префиксов) и в 2021 году.

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

    Конечно, было бы ошибкой сосредотачиваться только на цифрах. Воздействие варьируется. Это может быть семейство свойств, все из которых требуют префикса, например анимация ; или это может быть функция, которая имеет только одно свойство или значение, требующее префикса, например user-select: none .Давайте изучим фактические особенности, чтобы лучше понять обстоятельства, начав с рассмотрения того, что изменилось за этот промежуточный период.

    Двадцать функций были без префикса (полностью реализованы во всех основных браузерах) и были введены три функции с префиксом ( фоновый фильтр , CSS текстовая ориентация и CSS начальная буква ).

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

    1. Модуль компоновки гибких блоков CSS
    2. Размер блока CSS3
    3. Анимация CSS
    4. Двухмерные преобразования CSS3
    5. Трехмерные преобразования CSS3
    6. Эффекты фильтра CSS
    0
    2
    1. : Любая ссылка
    2. :: Placholder
    3. 4 :: Выбор
    4. : Фокус-видимый
    5. 4: IS ()

      5
    6. : только для чтения

      5
    7. : Read-Write
    8. Text-align-Last

      5
    9. 4 Mode Mode
    10. CSS GRAB и Grabbing Курсы
    11. CSS Логические свойства (будут использоваться
    12. CSS3 увеличение масштаба и уменьшение масштаба курсоры
    13. CSS3 макет с несколькими столбцами

    Если вы решите не поддерживать Internet Explorer 11 в 2021 г., дополнительные семь функций больше не требуют префикса.Это сократит количество функций, требующих префикса, в 2021 году до 28, что на 46% меньше, чем в 2013 году.

    Префикс в 2021 году

    Давайте посмотрим на свойства, которые требуют префикса. Это пестрая группа!

    4
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit

        5)
      • Safari
        ( -Webkit

        5)
      • Opera
        ( -Webkit )
      • Safari iOS
        ( -Webkit )
      • Браузер Android
        ( -webkit )
      • Chrome для Android
        ( -webkit )
    4
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit

        5)
      • Safari
        ( -Webkit

        5)
      • Opera
        ( -Webkit )
      • Safari iOS
        ( -Webkit )
      • Браузер AndroidOpera Mobile
        ( -webkit )
    4
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit

        5)
      • Safari
        ( -Webkit

        5)
      • Opera
        ( -Webkit )
      • Safari iOS
        ( -Webkit )
      • Android браузер
        ( -webkit
        )
      • Chrome для Android
        ( -Webkit )
      • Opera Mobile
        ( -Webkit )
    4
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit

        5)
      • Safari
        ( -Webkit

        5)
      • Opera
        ( -Webkit )
      • Safari iOS
        ( -Webkit )
      • Браузер Android
        ( -webkit )
      • Chrome для Android
        ( -webkit )
    # Имя Свойства/значения Описание Требуется префикс Поддержка без префикса Опора с префиксом Улучшение с префиксами
    1 внешний вид внешний вид Определяет, как элементы (в частности, элементы управления формы) отображаются по умолчанию.Установка значения none приводит к тому, что внешний вид элемента по умолчанию полностью переопределяется с использованием других свойств CSS.
    • Safari
        ( -Webkit )
      • Opera
        ( -Webkit
        )
      • браузер Android 2.1-4.4.4
        ( -Webkit )
    69,80% 97,03% 27,23%
    2 фоновый клип-текст фоновый клип: текст Нестандартный метод обрезки фонового изображения по тексту переднего плана. 3,89% 96,65% 92,76%
    3 фоновый фильтр фоновый фильтр Метод применения эффектов фильтра (таких как размытие , оттенки серого или оттенок ) к содержимому или элементам ниже целевого элемента.
    • Safari
      ( -webkit )
    • Safari iOS
      ( -webkit )
    70,20% 88,20% 18,00%
    4 фоновое изображение: crossfade() фоновое изображение: crossfade() Функция изображения для создания «кроссфейда» между изображениями. Это позволяет одному изображению переходить (затухать) в другое на основе процентного значения.
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit

        5)
      • Opera
        ( -Webkit )
      • браузер Android
        ( -Webkit )
      • Chrome для Android
        ( -вебкит )
    17.77% 92,62% 74,85%
    5 фоновое изображение: набор изображений() фоновое изображение: набор изображений() Метод, позволяющий браузеру выбрать наиболее подходящее фоновое изображение CSS из заданного набора, в основном для экранов с высоким разрешением PPI .
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit

        5)
      • Opera
        ( -Webkit )
      • Browser Android
        ( -Webkit )
      • Opera Mobile
        ( - вебкит )
    17.77% 92,48% 74,71%
    6 декоративный ящик декоративный ящик Определяет, будут ли поля, границы, отступы и другие украшения блока оборачивать сломанные края фрагментов блока, когда блок разделен разрывом, таким как страница, столбец, область или строка. 6.39% 97,17% 90,78%
    7 клипса клипса Метод определения видимой области HTML-элемента с помощью SVG или определения формы. 72,00% 96,33% 24,33%
    8 регулировка цвета регулировка цвета Нестандартное расширение CSS, которое можно использовать для принудительной печати фоновых цветов и изображений.
    • Chrome
        ( -webkit-print-color-addrad

        5)
      • Edge
        ( -webkit-print-color-addrad
      • )
      • Safari
        ( -webkit-print-color-addrad )
      • Opera
        ( -webkit-print-color-adjust )
      • Android Mobile
        ( -webkit-print-color-adjust )
    3,69% 39,77% 36,08%
    9 элемент() фон: элемент() Эта функция отображает живое изображение, сгенерированное из произвольного элемента HTML 0.00% 4,04% 4,04%
    10 кернинг шрифта кернинг шрифта Управляет использованием интервала между буквами, сохраненного в шрифте. Обратите внимание, что это влияет только на шрифты OpenType с информацией о кернинге и не влияет на другие шрифты. 81,73% 96,03% 14,30%
    11 гладкий шрифт гладкий шрифт Управляет применением сглаживания при рендеринге шрифтов.Хотя это свойство присутствовало в черновиках спецификации CSS3 Fonts в начале 2002 года, с тех пор это свойство было удалено и в настоящее время не входит в стандартный набор.
    • Chrome
      • ( -Webkit-font-clanging )
      • Edge
        ( -Webkit-font-Clanging
      • )
      • Firefox
        ( -Moz-OSX-Smed-Clamping )
      • Safari
        -webkit-font-smoothing )
      • Opera
        ( -webkit-font-smoothing )
    0.00% 39,64% 39,64%
    12 дефис дефис Метод управления переносом слов в конце строк.
    • Internet Explorer 10+
      ( -ms )
    • Safari
      ( -webkit )
    • Safari iOS
      ( -webkit
    • )
    76,49% 96,51% 20,02%
    13 начальная буква начальная буква Способ создания увеличенной крышки, включая опускающуюся или приподнятую крышку, надежным способом.
    • Safari
      ( -webkit )
    • Safari iOS
      ( -webkit )
    0,00% 18,00% 18,00%
    14 линейный зажим линейный зажим Содержит текст до заданного количества строк при использовании в сочетании с display: -webkit-box . Любой текст, выходящий за пределы пробела, создает многоточие, если включено text-overflow: ellipsis .
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit
        )
      • Firefox
        ( -webkit

        5)
      • Safari
        ( -Webkit )
      • Opera
        ( -Webkit )
      • Safari iOS
        ( -Webkit )
      • браузер Android
        ( -Webkit
        ( -webkit

        5)
      • Chrome для Android
        ( -Webkit )
      • Firefox для Android
        ( -Webkit )
      • Opera Мобильный
        (-вебкит )
    0.19% 96,28% 96,09%
    15 положение: липкое положение: липкое Сохраняет положение элементов как «фиксированное» или «относительное» в зависимости от того, как они отображаются в окне просмотра. В результате элемент «застревает» на месте при прокрутке.
    • Safari 7.1-12.1
      (-вебкит )
    93,50% 95,36% 1,86%
    16 с выступами с выступами Способ настройки ширины символа Tab .Действует только вместе с white-space: pre или white-space: pre-wrap .
    • Firefox 4+
      ( -Moz )
    • Firefox для Android
      ( -Moz )
    • Opera 11.5-12-1
      ( -O )
    92,33% 97,38% 5,05%
    17 оформление текста украшение текста
    украшение текста-* свойства.
    Метод определения типа, стиля и цвета линий в свойстве text-decoration . Они могут быть определены как сокращение (например, text-decoration: сквозная пунктирная синяя ) или как отдельные свойства (например, text-decoration-color: blue ).
    • Firefox 6-35
      ( -Moz )
    • Safari 7.1+
      ( -Webkit )
    • Safari для iOS 8+
      ( -Webkit )
    80.25% 94,86% 14,61%
    18 выделение текста выделение текста
    выделение текста-* свойства
    Метод использования маленьких символов рядом с каждым глифом для выделения части текста, обычно используемый в восточноазиатских языках. Сокращенное свойство text-emphasis и входящие в него свойства text-emphasis-style и text-emphasis-color можно использовать для применения меток к тексту.Свойство text-emphasis-position , которое наследуется отдельно, позволяет установить положение меток выделения относительно текста.
    • Chrome 25+
      ( -webkit
      )
    • Edge 79+
      ( -Webkit )
    • Opera 15+
      ( -webkit )
    • Android браузер
      ( -Webkit )
    • Chrome для Android
      ( -webkit )
    • Opera Mobile
      ( -webkit )
    21.96% 95,99% 74,03%
    19 текстовая ориентация текстовая ориентация Задает ориентацию текста в строке. Текущие значения действуют только в вертикальных типографских режимах (определяемых с помощью свойства write-mode ). Сафари
    (-вебкит )
    90,88% 94,84% 3,96%
    20 регулировка размера текста регулировка размера текста Контролируйте, применяется ли алгоритм увеличения текста к текстовому содержимому элемента, к которому он применяется, и если да, то каким образом.
    • Edge 12-18
      ( -ms )
    • Safari iOS
      ( -webkit )
    • Firefox для Android
      ( -moz
    • 1 )
    72,75% 87,48% 14,73%
    21 выбор пользователя: нет по выбору пользователя Метод предотвращения выбора текста или элемента.
    • Internet Explorer 10-11
      ( -ms )
    • Safari
      ( -webkit )
    • Safari iOS
      ( -webkit)
      5 5 Android
    • 51-4.4.4
      ( -веб-кит )
    74,81% 96,49% 21,68%
    22 Рисунки на холсте CSS фон: -webkit-canvas(mycanvas) Способ использования HTML5 Canvas в качестве фонового изображения. В настоящее время не является частью какой-либо спецификации. 0,00% 19,40% 19,40%
    23 Маски CSS маска маска-* свойства Метод отображения части элемента с использованием выделенного изображения в качестве маски.
    • Chrome
      ( -Webkit

      5)
    • Edge
      ( -Webkit
      ( -Webkit

      5)
    • Safari
      ( -Webkit )
    • Safari iosandroid браузер
      ( -webkit )
    • Chrome для Android
      -webkit )
    • Opera Mobile
      ( -webkit )

    Частичная поддержка в браузерах WebKit/Blink относится к поддержке mask-image и для других свойств mask-box-image 9011 support5, но отсутствует части спец.

    4,18% 96,93% 92,75%
    24 CSS-отражения -вебкит-коробка-отражать Способ отображения отражения элемента. 0.00% 91,20% 91,20%
    25 Стиль полосы прокрутки CSS цвет полосы прокрутки
    ширина полосы прокрутки
    Способы изменения цвета и ширины полосы прокрутки. 4.28% 96,87% 92,59%
    26 Заливка и обводка текста CSS штрих-текст
    штрих-текст-* свойства
    Метод объявления ширины и цвета контура (штриха) для текста.
    • Chrome
        ( -Webkit

        5)
      • Edge
        ( -Webkit
        ( -Webkit
        )
      • Firefox
        ( -webkit

        5)
      • Safari
        ( -Webkit )
      • Opera
        ( -Webkit )
      • Safari iOS
        ( -Webkit )
      • браузер Android
        ( -Webkit
        ( -webkit

        5)
      • Chrome для Android
        ( -Webkit )
      • Firefox для Android
        ( -Webkit )
      • Opera Мобильный
        (-вебкит )
    0.00% 96,65% 96,65%
    27 Внутренний и внешний размер max-content
    min-content
    fit-content
    stretch (ранее fill ).
    Позволяет указывать высоту и ширину элемента во внутренних значениях, а не в фиксированных числовых значениях.
    • Chrome 22-45
      ( -Webkit
      )
    • Edge 3-65
      ( -Webkit )
    • Firefox (-MOZ-Attage)
    • Opera 15-32
      ( -Webkit )
    • Сафари 6.1-10-1
      ( -webkit )
    • Safari iOS 7-13.7
      ( -Webkit
      )
    • браузер Androind 4.4-4.4.4
      ( -Webkit )
    91,99% 96,36% 4,37%
    28 Медиа-запросы: функция разрешения @media (минимальное разрешение: 300 dpi) { … }, @media (максимальное разрешение: 300 dpi) { … } Позволяет задать медиа-запрос на основе пикселей устройства, используемых на единицу CSS.В то время как стандарт использует минимальное разрешение и максимальное разрешение , некоторые браузеры поддерживают более старый нестандартный медиа-запрос с соотношением устройств к пикселям .
    • Chrome 4-28
      ( -Webkit
      )
    • Safari 4+
      ( -Webkit )
    • Opera 10-115
      ( -Webkit )
    • Safari iOS
      ( -Webkit )
    • Браузер Android (2.3-4.3) Opera Mobile 12
      ( -webkit )
    • Firefox 3.5-15
      ( min--moz-device-pixel-ratio )

    Браузеры, поддерживающие -webkit , поддерживают нестандартное -webkit-min-device-pixel-ratio и webkit-min -device-pixel-ratio .

    80,40% 99,16% 18,76%

    После того, как я составил этот список, у меня сложилось первое впечатление, что это не те вещи, с которыми я сталкивался бы очень часто. Некоторые свойства не были  — и, вероятно, не будут  — полностью реализованы.Я бы сказал, что функция element() и CSS Canvas Drawings попадают в эту категорию. Safari недавно отказался от префикса для позиции : sticky , так что, скорее всего, он скоро исчезнет из списка.

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

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

    Недавно я столкнулся с несколькими ситуациями, когда требовались свойства с префиксом. Например, я делал индикатор выполнения чтения для блога, и мне нужно было использовать -webkit-appearance: none; и -моз-внешний вид: нет; , чтобы сбросить стиль по умолчанию для элемента progress . Также требовалось фиксированное позиционирование, поэтому мне пришлось добавить префикс позиции : sticky для поддержки фиксированного позиционирования в Safari.

    Другой пример? Я хотел использовать изображение PNG в качестве изображения-маски для рождественского дизайна и обнаружил, что -webkit-mask-image — единственное свойство, которое работает правильно. Маскирование, как правило, немного ошибочно, потому что большинство браузеров лишь частично поддерживают спецификацию.

    Вот еще: Флавио Коупс в статье «Как применять отступы к нескольким строкам в CSS» писал о том, как он хотел иметь одинаковые отступы в каждой строке многострочного заголовка. Решение заключалось в использовании box-decoration-break: clone .Большинству браузеров требуется версия этого свойства с префиксом -webkit , поэтому вам необходимо использовать ее.

    Инструменты

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

    Конечно, Autoprefixer (плагин PostCSS) поддерживается и использует данные прямо из caniuse, чтобы оставаться в курсе.

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

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

    Заключение

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

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

    Что такое префиксы поставщика CSS или префиксы браузера и что следует использовать? – Techstacker

    Глядя на код CSS в дикой природе, вы когда-нибудь задумывались, почему некоторые коды CSS имеют множество повторяющихся свойств с прикрепленными ярлыками, такими как -webkit-, -webkit-, -moz- , -o- и -ms- ?

    Они называются префиксами поставщиков или, более выразительно, префиксами браузера.

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

    Распространенным примером является свойство transition , для работы которого раньше требовалось целых 4 префикса браузера:

      -webkit-transition: все 1s легкость;
    -moz-переход: все 1 с облегчением;
    -ms-transition: все 1 с облегчением;
    -о-переход: все четверки облегчаются;
    переход: все 1 с облегчением;  
    Список префиксов CSS для каждого браузера:
    • Chrome, Android, Safari, iOS:
       -вебкит- 
    • Firefox:
       -моз- 
    • Internet Explorer:
       -мс- 
    • Опера:
       -о- 

    Какие браузерные префиксы нужны вашему сайту?

    В 2020 году свойство transition почти полностью работает в Chrome, Firefox, Edge, Opera без префикса, однако:

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

    Использование префиксов — это быстро сокращающаяся проблема, но она все еще существует.

    Чтобы проверить, нужны ли вашему коду префиксы для поддерживаемых браузеров, перейдите на веб-сайт Autoprefixer. Затем перейдите в Browserlist и здесь вы можете указать, сколько версий обратной совместимости вам нужно.

    Браузеры постоянно развиваются и меняются. Просто посмотрите на большую разницу между выбором совместимости для последних 4 версий и последних (1) версий.

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

    Caniuse.com также является отличным веб-сайтом для поиска совместимости браузера CSS.

    Совместимость с CSS3 и префиксы поставщиков

    Совместимость с CSS3 и префиксы поставщиков | Примечания Comm244

    Вернуться на страницу недели 6 »

    Как вы, возможно, уже поняли, CSS (а также HTML и JavaScript) является движущейся целью, и постоянно вводятся и совершенствуются новые функции и спецификации.Этот процесс обычно включает в себя множество компромиссов с сообществом веб-разработчиков, организациями по стандартизации (такими как W3C) и разработчиками браузеров.

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

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

    Чтобы разрешить использование спецификации CSS, которая не полностью реализована в браузере или в ранней реализации, мы используем так называемые префиксы поставщиков CSS.

    Проверка совместимости

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

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

    • Является ли эта функция необходимой для работы моего веб-сайта/приложения или это визуальное улучшение?
    • Какие браузеры не поддерживают эту функцию?
    • Могу ли я предоставить разумный запасной вариант?
    • Определите «точку разрыва» для функции.Как далеко назад должна идти поддержка?

    В Интернете имеется множество ресурсов, собирающих информацию о совместимости браузеров. Иногда трудно сказать, насколько свежа информация. Важно получать актуальную информацию. Один из лучших ресурсов — Могу ли я использовать ____?

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

    Префиксы поставщиков CSS

    Процесс введения новых свойств CSS и элементов HTML может быть долгим и запутанным. Иногда изменения предлагаются комитетами по стандартам (например, W3C), а иногда поставщики браузеров создают свои собственные свойства.

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

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

    Торговые префиксы в 2017 году

    Гораздо менее необходим, но все же используется.

    Браузер Префикс поставщика
    Internet Explorer -мс-
    Хром -вебкит-
    Сафари -вебкит-
    Firefox -моз-
    iOS -вебкит-
    Андриод -вебкит-
    Опера -о-

    Примечание. И Chrome, и Opera теперь используют разветвленную версию webkit под названием Blink в качестве механизма рендеринга.На данный момент они продолжат использовать префикс -webkit, но в будущем они вообще не будут использовать префиксы и потребуют включения «экспериментальных» функций с помощью настройки предпочтений. Firefox будет делать то же самое.

    Пример префикса поставщика

    Префиксы поставщиков лучше всего понять на примере. В CSS вы можете создавать закругленные углы, используя свойство border-radius. Вот в самом простом виде:
      .закругленный {
       радиус границы: 10px;
    }  
    Все четыре угла округлены на 10 пикселей.Сегодня border-radius достаточно поддерживается, чтобы сделать ненужными префиксы поставщиков. Однако всего несколько лет назад вам нужно было использовать префиксы поставщиков для обеспечения поддержки. Вы бы написали это:
      .закругленный {
       -moz-border-radius: 10px; /* поддержка Firefox */
       -webkit-border-radius: 10px; /* поддержка браузеров на основе webkit (Chrome, Safari, iOS и т. д.) */
       -o-граница-радиус: 10px; /* поддержка Opera */
       радиус границы: 10px; /* стандартизированное свойство */
    }
    
    /* Только пример.Вам не нужно использовать префиксы поставщиков для радиуса границы */  
    • В CSS браузер просто игнорирует свойства, которые он не понимает.
    • Префиксы поставщиков используются указанными браузерами и игнорируются другими.
    • Всегда ставьте стандартизированное свойство последним. Любой браузер, который его понимает, будет использовать последнее определение, перезаписывая любое предыдущее.

    Дополнительная информация

    Вернуться на страницу недели 6 »

    Перестаньте записывать префиксы поставщиков CSS вручную

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

    .
    • -webkit- : браузеры Chrome, Safari, WebKit
    • -ms- : Internet Explorer, Microsoft Edge
    • -o- : версии Opera
    • до WebKit.
    • -moz- : Firefox
      .пример {
      -webkit-border-radius: 10px;
      -moz-border-radius: 10px;
      -ms-border-radius: 10px;
      -o-граница-радиус: 10px;
      радиус границы: 10px;
    }  

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

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

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

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

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

    Функциональные запросы

    Ат-правило CSS @supports позволяет указать объявления, которые зависят от поддержки браузером одной или нескольких определенных функций CSS, известных как запросы функций.

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

      @supports (отображение: сетка) {
      
    }
    
    @supports not (отображение: сетка) {
      
    }
    
    @supports (отображение: сетка) и (не (отображение: встроенная сетка)) {
      
    }
    
    @supports (-moz-transform-style: сохранить) {
      
    }  

    Это направление, которое продвигают основные поставщики браузеров, оно отлично работает, предоставляя средство для написания резервных стилей, когда что-то не поддерживается, но имейте в виду следующие ограничения:

    • Ат-правило @support будет работать только в браузерах, поддерживающих @supports .Не забудьте написать запасной код вне функциональных запросов.
    • Вам по-прежнему нужно отслеживать, какие функции нужно проверять вручную, caniuse.com может помочь с этим. Очевидно, что это менее обыденно, чем написание префиксов, и меньше беспокоит появление на рынке новых браузеров, если они поддерживают запросы функций.
    • Браузеры, не поддерживающие CSS Grid, которые также не поддерживают запросы функций.

    Автоматическое добавление префикса

    Учтите, что префикс поставщика нельзя полностью удалить даже при использовании запросов функций из-за опасений пропустить непроверенные функции.С появлением CSS (pre|post)-процессоров префиксы поставщиков могут выполняться автоматически. Чтобы это решение работало, вам понадобятся следующие инструменты:

    • Инструмент для определения целевых браузеров . Список браузеров — это лучшее, что вы можете найти, он автоматически найдет целевые браузеры, когда вы укажете требования в .browserslistrc следующим образом:
      # поддерживаемые браузеры
    значения по умолчанию
    не IE 11
    поддерживаемые версии узлов  
    • Инструмент для автоматического префикса на основе указанных выше целевых браузеров .Autoprefixer — лучший в своем роде, плагин PostCSS использует целевые браузеры из списка браузеров и добавляет префиксы на основе данных caniuse.com. Вот пример настройки с Gulp:
      gulp.task('автопрефиксер', () => {
      const autoprefixer = require('autoprefixer')
      const sourcemaps = require('gulp-sourcemaps')
      const postcss = требуется ('gulp-postcss')
    
      обратный глоток
        .src('./src/*.css')
        .pipe(исходные карты.init())
        .pipe(postcss([autoprefixer()]))
        .pipe(исходные карты.записывать('.'))
        .pipe(gulp.dest('./dest'))
    })  

    Помимо автоматического префикса, PostCSS может помочь с полифиллами, но очень ограничено, когда новые функции CSS требуют реализации JavaScript на стороне клиента.

    Совместимость браузеров и префиксы поставщиков

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

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

    В этом уроке мы узнаем о кросс-совместимости браузеров и о том, как мы можем использовать что-то, называемое , с префиксом , чтобы заставить новые функции CSS работать практически в любом современном браузере.

    Кросс-браузерное тестирование

    Поддержка браузера имеет большое значение в веб-разработке.Хотя большинство из нас используют современные версии Chrome или Firefox, вы будете удивлены, узнав, сколько людей до сих пор используют устаревшие браузеры, такие как Internet Explorer 8. Из-за этого разработчики постоянно стремятся соблюдать стандарты, чтобы включить поддержку на всех платформах. . В конце концов, компании хотят, чтобы их сайты были функциональными и красивыми для всех , а не только для тех, у кого новейшие браузеры.

    Кросс-браузерное тестирование помогает сделать это возможным. Это не то, что мы будем явно практиковать в классе, но вы можете прочитать больше об этом здесь и проверить некоторые инструменты (бесплатные или платные) на досуге.А пока просто узнайте, что означает этот термин.

    Префиксы поставщиков

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

    .
      .sample-parent-контейнер {
      -moz-border-radius: 10px;
      -webkit-border-radius: 10px;
      -o-граница-радиус: 10px;
      радиус границы: 10px;
    }
      

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

    Все четыре объявления стилей в приведенном выше правиле делают одно и то же, но предназначены для разных браузеров:

      .sample-parent-контейнер {
      -moz-border-radius: 10px; // добавляет радиус границы 10px к элементу в Firefox.
      -webkit-border-radius: 10px; // добавляет радиус границы 10px к элементу в
                                    // Android, Chrome, iOS и Safari.-o-граница-радиус: 10px; // добавляет радиус границы 10px к элементу в Opera.
      радиус границы: 10px; // версия этого же объявления без префикса.
    }
      

    Рекомендуется перечислить все объявления стилей с префиксом для всех браузеров, которые поддерживает ваш сайт, а затем перечислить «обычное» объявление без префикса последним, как показано выше. (Обратите внимание, что последнее объявление стиля — border-radius: 10px без префикса.)

    Общие префиксы

    Вот наиболее часто используемые префиксы и браузеры, с которыми они работают:

    • Android: -вебкит-
    • Хром: -вебкит-
    • Firefox: -moz-
    • Internet Explorer: -ms-
    • iOS: -вебкит-
    • Опера: -о-
    • Сафари: -вебкит-

    Как уже упоминалось, рекомендуется включить поддержку всех браузеров.Но в целях обучения и практики не слишком беспокойтесь о включении резервной поддержки (просто знайте как! ). Для учебных проектов используйте Chrome как обычно.

    Автопрефиксеры

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

    Например, этот код, создающий flexbox:

      .пример {
      дисплей: гибкий;
    }
      

    Автоматически превратится в это после запуска через автопрефикс:

      .пример {
      дисплей: -webkit-box;
      отображение: -webkit-flex;
      отображение: -ms-flexbox;
      дисплей: гибкий;
    }
      

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

    Срок действия префикса поставщика?

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

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

    По этой причине префиксы поставщиков и автопрефиксеры не требуются для нашего курса.

Добавить комментарий

Ваш адрес email не будет опубликован.