вендорные префиксы что это
Вендорные префиксы. Что это?
На первый взгляд кажется, что вендорные префиксы это что-то из разряда грамматики. Вендорные префиксы, вендорные суффиксы и вендорные окончания. Но какое отношение это имеет к верстке?
Оказывается, самое прямое! Вендорные префиксы — это приставки к названию CSS свойства, которые добавляют производители браузеров для нестандартизированных свойств.
Согласно спецификации CSS 2.1 CSS идентификаторы, которые начинаются с «-» или «_» зарезервированы для CSS расширений браузеров. Наличие этих знаков в начале свойства гарантирует то, что в будущем расширения браузеров никогда не пересекутся со стандартными CSS свойствами. Т.е. ни один браузер не начнет «случайно» понимать свойство, которое для него не предназначено.
Какие они бывают?
Вендорные префиксы самых распространенных браузеров приведены в таблице ниже:
Как это работает?
Для элемента прописывается CSS свойство в прямом виде для браузеров, которые его понимают. Следом за ним через точку с запятой перечисляется то же самое свойство, но с разными вендорными префиксами для разных браузеров. Браузер из такого кода интерпретирует только то свойства, которое написано под него, а написанные для других браузеров игнорирует.
Например, CSS свойство opacity, отвечающее за прозрачность элемента, кроссбраузерно используется так:
Для чего это нужно?
Кроме того, разработчики Microsoft ухитрились с помощью вендорных префиксов скрывать от валидатора невалидные конструкции. Это касается, прежде всего, фильтров. Для IE 5.5-7 фильтр выглядел так:
Такая конструкция пройти валидацию в принципе не может! Но ее преспокойно проходит новая конструкция того же фильтра, но уже для IE 8:
Конечно, не очень хочется в коде писать несколько строчек кода с вендорными свойствами под каждый браузер вместо одной строчки кода со стандартными свойствами. Но не нужно забывать, что спецификация CSS3 пока еще находится в разработке. Возможно, что в описании свойства при стандартизации что-то поменяется, либо его совсем не будет в спецификации. Тогда безусловно разработчикам будет легче отказаться от вендорного свойства и поддерживать стандарты. Согласитесь, если в разных версиях браузера одно и то же свойство будет работать по-разному, ничего хорошего из этого не получится. Пускай лучше в старых версиях браузеров будут работать вендорные свойства, а новые версии будут поддерживать спецификацию в прямом виде, а свойства с вендорными префиксами будут игнорироваться.
Приятный бонус
Благодаря вендорным префиксам производители браузеров уже внедряют экспериментальные CSS3 свойства на свой страх и риск.
Верстальщик уже сейчас может реализовать большинство возможностей предоставляемых CSS3, в том числе разнообразные переходы и анимации без использования скриптов, но используя вендорные префиксы.
Наглядным примером такой реализации может быть использование CSS3 свойства transition. Поставим задачу реализовать для ссылки плавное изменение цвета фона при наведении курсора, не используя JavaScript. Для этого в CSS для ссылки нужно дописать следующий код
Живой пример можно посмотреть тут.
Кроме того, согласно заявлениям разработчиков, данный демо пример будет также работать в Firefox 4.0, первая бета версия которого вышла в июле 2010 года.
Подытожим
Вендорные префиксы — это специальные приставки к названию CSS свойства, заточенные под конкретный браузер, которые позволяют ему понимать экспериментальные CSS свойства и одновременно игнорировать записи, предназначенные для других браузеров.
Свойства с вендорными префиксами не соответствуют стандартам и не пройдут валидацию. Если тебя это не сильно беспокоит, их можно применять, т.к. в умелых руках это очень мощный инструмент. И многие ведущие студии рунета этим пользуются.
Заметка
Свойства по спецификации всегда пишем последними.
В этой статье мы рассмотрим, что такое префиксы браузеров, причины их появления и как их использовать в CSS.
Что такое префиксы
Веб-разработчик начинающий изучать теоретические основы CSS и использующий данные знания на практике может столкнуться с проблемами при рассмотрении реальных примеров. Это может вызвать у него непонимание происходящего и отбить дальнейшее желание изучать данную технологию.
Что же это такое? На самом деле всё просто, эти непонятные слова являются префиксами следующих браузеров:
Таким образом, если перед названием свойства стоит некоторый префикс, то это означает, что данное свойство реализовано и будет применяться исключительно в указанном браузере. Все остальные браузеры данное свойство будут игнорировать, т.к. для них данный префикс неизвестен.
Причины появления префиксов
Причин для появления префиксов было достаточно много:
Когда экспериментальное свойство утверждено в стандарте и прошло тестирование в браузере, у него обычно убирается префикс.
Как использовать префиксы
Рассмотрим в качестве примере следующий код:
При использовании префиксов для свойств CSS, необходимо помнить, что их следует располагать до свойства CSS без префикса. Почему это так важно? Это важно потому, что если когда-то в браузере будет реализовано оригинальное свойство (без префикса), то будет использоваться именно оно (т.к. оно располагается последним), а не его экспериментальная версия.
Например: применение свойства CSS ко всем элементам веб-страницы в браузере Google Chrome версии 40.
Как проверить поддержку определенного свойства в браузере
Сайт, на котором можно проверить реализовано ли данное свойство или нет в конкретном браузере можно по ссылке приведённой ниже. Кроме этого на сайте показывается количество пользователей в процентах, которые пользуется этой версией браузера.
Например: проверим, как реализовано свойство transform в браузерах.
На сайте «CanIUse» браузеры отмечаются различными цветами, в зависимости от того в каком состоянии находится поддержка определённых свойств или тегов:
Блог Vaden Pro
Зачем нужны вендорные префиксы
У каждого браузера есть свои встроенные, экспериментальные или нестандартные свойства и для того, что бы они корректно работали используют вендорные префиксы. В названии не зря использовано слово префиксы потому что, как и в грамматике, они являются приставкой, только в данном случае к свойству CSS.
Вендорные префиксы представляют собой надпись, которая начитается с «-» или с «_» и для каждого браузера имеет смысл специального маркера, написанного перед CSS свойством.
Использование данного префикса гарантирует работу именно этого стиля в определённом браузере, а также то, что он не перекроется аналогичными стилями, предназначенными для других браузеров.
Как их отличать?
Каждый движок, на котором написан браузер, имеет свой вендорный префикс.
Как это выглядит на практике?
Рассмотрим на примере для свойства transition-duration:
Как мы можем видеть, первыми пишутся элементы стиля с вендорными префиксами, для каждого браузера. Стоит обратить внимание, что стиль соответствующий требованиям спецификации пишется последним. Благодаря этой записи, к примеру, Firefox из написанного выше примера воспримет только вторую строчку, а остальные проигнорирует.
Для чего это нужно?
Большинство производителей называют несколько причин, когда нужно использовать вендорные префиксы. Основные, из которых:
Дополнительные возможности
Благодаря появлению вендорных префиксов большинство компаний производящих свои браузеры стали внедрять собственные свойства CSS.
Уже сейчас для верстки своих проектов можно исключить некоторые скрипты, заменив их стилями CSS.
Так, к примеру, вышеуказанный стиль позволяет плавно изменять цвет, при наведении не используя JavaScript. Однако если попробовать обойтись без префиксов, то данный стиль в некоторых браузерах может работать не корректно или не работать вообще.
Подводя итоги
Вендорные префиксы – приставки к стилям css, имеющие смысловую нагрузку только для тех браузеров, к которым они относятся. Они дают возможность браузеру воспринимать не стандартные свойства, а также не воспринимать те стили, которые предназначены для других пользовательских клиентов.
Стоит отметить, что свойства, имеющие данный префикс, не пройдут валидации. Однако при правильном использовании они придают большей гибкости CSS, по этой причине большинство веб-студий ими не пренебрегают.
Вендорные префиксы
Время чтения: 6 мин
Обновлено 18 августа 2021
Кратко
Вендорные префиксы — это приставки перед свойствами, селекторами, функциями или другими сущностями в CSS, позволяющие браузерам внедрять экспериментальные фичи до того, как они полностью стандартизированы и готовы для использования. Когда префикс отбрасывается — это знак, что всё готово.
Кто такие вендоры?
Чтобы понять, что такое вендорные префиксы и зачем они нужны, надо немного разобраться с тем, как и кто разрабатывает CSS.
CSS — это одна из трёх основных мощных технологий, на которых строится веб. Его используют в своей работе тысячи разработчиков. А результат — стили сайта — видят миллионы пользователей.
Чтобы CSS во всём мире был единым, над его развитием работает так называемая Рабочая группа CSS (CSS Working Group), или коротко CSSWG. Они собирают потребности разработчиков сайтов и описывают возможности CSS в новых модулях. Получившийся документ называется спецификацией. В ней содержится описание того, как новое свойство должно работать.
Дальше наступает этап внедрения в браузеры. Каждый браузер разрабатывает отдельная компания, отдельные команды разработки. Когда в черновиках спецификации появляется новая CSS-фича, разработчики браузера начинают её реализовывать. Поскольку в спецификации не всегда описаны конкретные технические решения (черновик на то и черновик, что может меняться), то каждая команда разработки может делать это чуть иначе и принципы работы фичи вполне могут меняться со временем. До момента, пока не стабилизируется спецификация или пока не будут написаны все тесты, фича может работать в тестовом режиме, с вендорным префиксом.
Каждый браузер — это отдельный вендор (от англ. vendor — продавец) услуг просмотра сайтов, интернета. Отсюда и слово «вендорный». Буквально это означает, что существуют некие отдельные префиксы — они же приставки — которые работают в конкретном браузере — вендоре.
Префиксы
Основные браузеры используют следующие префиксы:
Где нужны префиксы?
В CSS существует много разных сущностей: селекторы и псевдоэлементы, свойства и их значения, функции, директивы. В процессе внедрения любой новой фичи используются вендорные префиксы.
Директивы
Самый частый случай, когда вам может пригодится вендорный префикс для директивы — @keyframes :
Написать директивы @-webkit-keyframes и @keyframes через запятую, чтобы не дублировать их содержимое, не получится.
Псевдоклассы
В последнее время в CSS появляется много новых очень мощных псевдоклассов. Например, стилизовать плейсхолдер в поле ввода можно при помощи такого кода:
Как и в случае с директивами, префиксы в псевдоэлементах тоже приводят к дублированию кода: если перечислить всё через запятую, браузеры вас не поймут.
Значения свойств
Бывает и так, что свойство старое, а вот значение для него новое, экспериментальное. В данный момент таким новым значением является функция image-set() для свойства background-image :
Но браузер на этом не остановится и пойдёт дальше: если он поддерживает значение без префикса, то он предпочтёт его — ведь оно последнее. Поэтому порядок следования свойств с префиксами в значениях тоже важен: сначала идут значения с префиксами, потом — без, чтобы браузеры выбрали последний, максимально современный вариант.
Селекторы
Как всё запомнить?
Скорее всего, вы сейчас думаете, а как же запомнить, где какие префиксы нужно писать, и для каких свойств они действительно нужны, а какие поддерживаются и без них.
Самый простой способ проверить поддержку свойства — найти его на сайте Can I use. Там, в том числе, написано, какие префиксы для каких браузеров нужны.
Но чаще всего разработчики не пишут префиксы руками, а используют инструменты автоматизации. Самым популярным из них на сегодня является Автопрефиксер. Вы можете попробовать его онлайн: вставляете ваш CSS, указываете, какие браузеры должны поддерживаться, и получаете код с проставленными префиксами там, где это нужно.
Порядок важен
Очень важно указывать сущности (свойства, селекторы, директивы и так далее) с вендорными префиксами выше, чем без префиксов:
Это нужно для того, чтобы браузер использовал самую последнюю стабильную реализацию. Если браузер уже поддерживает фичу без префиксов, то применится последнее из перечисленных. А если нет, то сработает подходящая запись из кода выше.
Современный CSS для динозавров
— Двигать пиксели в CSS и так было трудно! А теперь мне говорят, насколько круто использовать несемантические названия классов, встроенные стили в HTML и даже писать стили CSS на JavaScript!
[Вставь тут гифку из «Гриффинов»] — Ха!
Иллюстрации из Dinosaur Comics Райана Норта
Как ни странно, CSS считается одновременно одним из самых простых и одним из самых сложных языков для веб-разработчика. Определённо он достаточно прост в начале — вы определяете свойства стиля, значения для конкретных элементов и… это практически всё, что нужно знать! Однако в больших проектах ситуация становится довольно запутанной и сложной, чтобы организовать CSS каким-то осмысленным образом. Изменение любой строчки CSS для стилизации элемента на одной странице часто ведёт к непредвиденным последствиям для элементов на других страницах.
Чтобы разобраться в присущей сложности CSS, созданы самые разные виды передовых практик. Проблема в том, что до сих пор нет единого мнения, какие из них являются лучшими, а многие из них полностью противоречат друг другу. Если вы впервые пытаетесь выучить CSS, то такая ситуация дезориентирует, мягко говоря.
Цель этой статьи — показать исторический контекст, как развивались техники и инструменты CSS до их нынешнего состояния в 2018 году. Поняв эту историю будет легче понять каждый подход и как с выгодой его использовать. Итак, начнём!
Использование CSS для базовых стилей
Пока мы не используем никаких классов или id в HTML, только семантические теги. Вообще без использования CSS веб-сайт выглядел бы так (с текстом-заполнителем):
Нажмите здесь для реального примера
Функционально, но не очень симпатично. Можем добавить CSS для улучшения базового оформления в index.css :
Здесь бóльшая часть CSS — это стили оформления (шрифты с размерами, высота строк и проч.), с некоторыми стилями цветов и центрированной вёрсткой. Вам пришлось бы изучать дизайн, чтобы узнать хорошие значения этих параметров (тут стили из sakura.css), но сам код CSS здесь не слишком сложен для чтения. Результат выглядит примерно так:
Нажмите здесь для реального примера
Какова разница! Это посыл CSS — простой способ добавить стили в документ, без программирования или сложной логики. К сожалению, всё становится немного сложнее, когда мы начинаем использовать CSS для чего-то большего, чем просто оформление и цвета (с этим разберёмся дальше).
Использование CSS для разметки
В 1990-е годы, до того как технология CSS получила широкое распространение, существовало немного вариантов для разметки содержимого на странице. HTML изначально проектировался как язык для создания простых документов, а не динамических веб-сайтов с боковыми меню, колонками и т.д. В те времена разметку часто производили HTML-таблицами — вся страница целиком помещалась в таблицу, которая использовалась для организации контента по колонкам и строкам. Такой подход работал, но обратной стороной была тесная увязка содержания и представления — если вы хотели изменить разметку на сайте, иногда приходилось переписывать значительный объём HTML.
CSS дал сильный толчок к разделению контента (написанного на HTML) и представления (написанного на CSS). Появился способ вынести всю разметку из HTML (больше никаких таблиц) в CSS. Важно отметить, что CSS как и HTML тоже изначально не был спроектирован для разметки страниц, поэтому первые попытки разметки трудно назвать изящными.
Посмотрим, как это работает на практике с нашим вышеприведённым примером. Прежде чем определить какую-либо разметку CSS, сначала сбросим все поля и отступы (которые влияют на вычисление разметки), а также разметим секции разными цветами (не для красоты, а для их визуального различении при тестировании разных макетов).
Теперь веб-сайт временно будет выглядеть так:
Нажмите здесь для реального примера
Сейчас мы готовы использовать CSS для разметки контента на странице. Оценим три разных подхода в хронологическом порядке, начиная с классических float-макетов.
Макет на основе float
Свойство CSS float первоначально ввели для размещения изображения внутри колонки текста слева или справа (что вы часто видели в газетах). Веб-разработчики начала 2000-х воспользовались преимуществом того факта, что вы можете назначить свойство float не только изображениям, но любому элементу, то есть можно создать иллюзию строк и колонок, назначая float для целых div’ов контента. Но опять же, float не предназначен для этой цели, так что такую иллюзию трудно осуществить последовательным образом.
В 2006 году A List Apart опубликовал популярную статью «В поисках Святого Грааля», которая изложила подробный и тщательный подход к созданию макета, известного как Святой Грааль — заголовок, три колонки и нижний колонтитул. Сейчас кажется безумием, что такой довольно простой макет называли Святым Граалем, но вот так трудно было создать устойчивый макет на чистом CSS.
Ниже показан макет на основе float для нашего примера на основе техники, описанной в статье:
Нажмите здесь для реального примера
Неплохо, но по трём цветам видно, что у колонок неодинаковая высота, а страница не заполняет всю высоту экрана. Это неизбежные проблемы при использовании подхода на основе float. Всё, что может сделать float, это прижать контент к левой или правой границе секции — в CSS нет средств повлиять на высоту контента в других секциях. В течение многих лет у проблемы отсутствовало простое решение, пока не появились макеты на основе flexbox.
Макет на основе flexbox
Свойство flexbox в CSS впервые предложили в 2009 году, но оно не получило широкой поддержки в браузерах примерно до 2015 года. Свойство спроектировано для определения, как распределяется пространство в одной колонке или строке, что делает его более подходящим способом вёрстки, чем float. Таким образом, после десяти лет использования макетов на основе float веб-разработчики наконец-то смогли применять CSS для вёрстки без хаков, присущих макетам на float.
Ниже показан макет на основе flexbox для нашего примера. Он сделан на базе техники, описанной на сайте Solved by Flexbox (популярный ресурс, где публикуются различные примеры на flexbox). Обратите внимание, что для работы flexbox требуется дополнительный враппер div вокруг трёх колонок в HTML:
Вот код flexbox в CSS:
Это гораздо более компактный код по сравнению с макетом на основе float! Свойства и значения flexbox на первый взгляд немного сбивают с толку, но они устраняют необходимость в большом количестве хаков вроде негативных границ — огромная победа. Вот как выглядит результат:
Нажмите здесь для реального примера
Намного лучше! Все колонки одинаковой высоты и занимают всю высоту страницы. В некотором смысле это выглядит идеально, но у такого подхода есть пара небольших недостатков. Во-первых, поддержка браузеров — сейчас все современные браузеры поддерживают flexbox, но некоторые старые браузеры никогда не будут его поддерживать. К счастью, разработчики браузеров делают существенные шаги, чтобы закончить жизненный цикл старых версий, что сделает более стабильной среду разработки для веб-дизайнеров. Другой недостаток — тот факт, что нам нужно добавлять в разметку
— было бы хорошо обойтись без этого. В идеальном мире любой макет CSS вообще не потребует редактировать разметку HTML.
Но самый большой недостаток — в самом коде CSS. Flexbox устраняет много хаков float, но код не такой выразительный, каким он мог быть для описания макета. Flexbox CSS трудно прочитать и получить визуальное понимание, как все элементы лягут на страницу. Из-за этого вы пытаетесь угадать правильные параметры — и проверяете, что получилось.
Важно ещё раз подчеркнуть, что flexbox создан для размещения элементов в одной колонке или строке — он не создан для вёрстки целой страницы! Даже хотя он исправно с этим справляется (намного лучше, чем подход на основе float), для вёрстки в нескольких колонках или строках были специально разработаны другие спецификации. Они называются CSS grid.
Макет на основе grid
CSS grid впервые предложили в 2011 году (ненамного позже flexbox), но прошло долгое время, пока браузеров стали его поддерживать. На начало 2018 года CSS grid поддерживается большинством современных браузеров (огромный шаг вперёд по сравнению с ситуацией год-два назад).
Ниже показан макет на основе grid для нашего примера. Он сделан на базе первого метода, описанного в этой статье по хитростям CSS. Обратите внимание, что в этом примере мы можем избавиться от
, который приходилось добавлять в макет на основе flexbox. Здесь мы просто используем оригинальный HTML без каких-либо изменений. Вот как выглядит CSS:
Результат визуально идентичен макету на основе flexbox. Однако здесь код CSS намного лучше в том смысле, что он явно показывает искомый макет. Размер и форма колонок и строк определены в селекторе body, а каждый элемент сетки непосредственно определяется по своему положению.
Нажмите здесь для реального примера
Первая колонка начинается в позиции 1 и заканчивается в позиции 2, вторая колонка начинается в 2 и заканчивается в 3, а третья колонка начинается в позиции 3, а заканчивается в позиции 4. В заголовке указано свойство grid-column со значением 1 / 4 для расширения на всю страницу, в nav указано grid-column со значением 1 / 2 для расширения на первую колонку и т.д.
Когда вы привыкнете к синтаксису grid, то станет понятно, что это идеальный способ осуществлять вёрстку в CSS. Единственный реальный недостаток — поддержка не во всех браузерах. Но опять же ситуация значительно улучшилась за последний год. Трудно переоценить значение CSS grid как первого реального инструмента в CSS, который действительно изначально создан для вёрстки, то есть для вёрстки всей страницы целиком. В каком-то смысле веб-дизайнерам всегда приходилось быть очень консервативными при создании креативных макетов, поскольку до последнего времени инструменты оставались очень хрупкими, требовали разнообразных хаков и нестандартных лазеек. Теперь с появлением CSS grid возникает потенциал для новой волны креативных дизайнерских макетов, которые невозможно было создать никогда раньше — замечательные времена!
— Получил? Забавно, что когда меняешь что-то в CSS, то оно ломает что-нибудь ещё!
— Возможно, но с новыми спецификациями вроде flexbox и grid всё стало гораздо лучше!
— Ха! В CSS гораздо больше трудностей, а не только вёрстка!
Использование CSS-препроцессора для нового синтаксиса
До сих пор мы рассматривали использование CSS для простых стилей и макетов. Сейчас изучим инструменты, которые помогают работать с самим языком CSS. Начнём с CSS-препроцессоров.
CSS-препроцессор позволяет писать стили на других языках, которые потом преобразуются в CSS, чтобы их понял браузер. Это было исключительно важно во времена, когда браузеры слишком медленно внедряли поддержку новых функций. Первый популярный CSS-препроцессор Sass вышел в 2006 году. В нём реализовали новый краткий синтаксис (отступы вместо скобок, отсутствие точек с запятой и т.д.) и добавили продвинутые функции, отсутствующие в CSS, такие как переменные, вспомогательные функции и вычисления. Вот как выглядит цветная секция из нашего предыдущего примера при использовании Sass с переменными:
Такой процесс известен как этап сборки, и в 2006 году это был довольно значительный барьер для входа. Если вы накоротке с языками программирования вроде Ruby, то для вас всё просто. Но многие фронтенд-разработчики в то время работали только с HTML и CSS, где не требуется подобный инструментарий. Так что это немалое требование к разработчику — изучать целую экосистему, чтобы воспользоваться функциями CSS-препроцессора.
В 2009 году вышел CSS-препроцессор Less. Он тоже написан на Ruby и обладает схожим функционалом с Sass. Ключевым отличием стал синтаксис, который сделали максимально похожим на CSS. Это значит, что любой код CSS одновременно является валидным кодом Less. Вот тот же пример на синтаксисе Less:
Для преобразования приведённого кода в обычный CSS требуется сначала установить Node.js, затем установить Less и запустить команду:
lessc index.less index.css
Когда Less приобрёл популярность, разработчики Sass добавили в свой препроцессор новый синтаксис SCSS в 2010 году (надмножество CSS, похожее на Less). Они также выпустили LibSass, порт движка Ruby Sass на C/C++, что ускорило его работу и сделало доступным для программирования на различных языках.
Ещё один альтернативный CSS-препроцессор Stylus вышел в 2010 году. Он написан на Node.js и отличается более чистым синтаксисом по сравнению с Sass или Less. Обычно в обсуждении CSS-препроцессоров упоминаются эти три программы как самые популярные (Sass, Less и Stylus). В конце концов, они все очень похожи по функционалу, так что вы не ошибётесь, выбрав любую из них.
Однако некоторые считают, что в последнее время значение CSS-препроцессоров уменьшилось, потому что браузеры наконец-то начали внедрять некоторые из их функций (такие как переменные и вычисления). Более того, существует противоположный подход — постобработка CSS, из-за которой CSS-препроцессоры могут полностью устареть (очевидно, это спорный вопрос). CSS-постпроцессоры мы сейчас и рассмотрим.
Использование CSS-постпроцессора для функций преобразования
CSS-постпроцессор использует JavaScript для анализа и преобразования вашего CSS в валидный CSS. В этом смысле он довольно похож на CSS-препроцессор — его можно рассматривать как иной способ решить ту же проблему. Ключевое отличие в том, что CSS-препроцессор применяет специальный синтаксис для определения объекта трансформации, а CSS-постпроцессор умеет разбирать оригинальный CSS-код и трансформировать его без какого-либо специального синтаксиса. Лучше всего показать это на примере. Посмотрим на часть CSS из вышеупомянутого примера, где мы определяли стиль тегов заголовка:
Довольно неудобно вставлять эти разные вендорные префиксы для использования свойств CSS. Хорошо бы, чтобы какой-нибудь инструмент автоматически делал это за нас в случае необходимости. Такое можно провернуть с помощью CSS-препроцессоров. Например, в синтаксисе SCSS:
Вместо mixin хотелось бы просто писать нормальный CSS, чтобы инструмент автоматически находил свойства, которым нужны префиксы, и добавлял их куда надо. CSS-постпроцессор умеет работать именно таким образом. Например, если используете PostCSS с плагином autoprefixer, то можете писать совершенно обычный CSS без каких-либо вендорных префиксов, а постпроцессор сделает всю работу:
Если запустить CSS-постпроцессор на этом коде, то вместо строчки hyphens: auto; появятся все соответствующие вендорные префиксы (в соответствии с правилами автозамены из плагина autoprefixer, которые не нужно вручную менять). То есть вы можете просто писать обычный CSS, не беспокоясь о какой-то совместимости или специальном синтаксисе, и это здорово!
Кроме autoprefixer есть и другие плагины для PostCSS, позволяющие вытворять поистине крутые штуки. Плагин cssnext позволяет применять экспериментальные функции CSS. Плагин CSS modules автоматически изменяет классы во избежание конфликтов имён. Плагин stylelint находит ошибки и противоречивые условия в вашем CSS. Эти инструменты по-настоящему стартовали в последние год или два, демонстрируя такие возможности рабочего процесса разработчика, какие не были доступны никогда раньше!
Однако за прогресс приходится платить. Установка и использование CSS-постпроцессора вроде PostCSS требует больше усилий по сравнению с CSS-препроцессором. Вам не только придётся установить и запустить инструменты из командной строки, но также установить и сконфигурировать отдельные плагины и определить более сложный набор правил (вроде того, какие браузеры принимать в расчёт и т. д.). Вместо запуска PostCSS прямо из командной строки многие разработчики интегрируют его в конфигурируемые системы сборки вроде Grunt, Gulp или webpack. Так легче управлять всеми разными инструментами сборки, которые вы можете использовать для фронтенда.
Примечание: Если вы никогда не использовали современные системы сборки для фронтенда, то может показаться, что необходимо усвоить слишком много информации. Если хотите начать с чистого листа, почитайте мою статью «Современный JavaScript для динозавров», где разъясняется весь необходимый инструментарий JavaScript, необходимый для использования этих современных функций во фронтенд-разработке.
Стоит заметить, что вокруг CSS-постпроцессоров развернулись споры. Некоторые говорят, что терминология слишком путаная (одни считают, что все эти инструменты следует называть CSS-препроцессорами; другие говорят, что их нужно называть просто CSS-процессорами и т.д.). Кто-то верит, что CSS-постпроцессоры вообще устранят необходимость в CSS-препроцессорах, кто-то считает, что их следует использовать вместе. В любом случае, нужно изучать CSS-постпроцессоры, если вы хотите выжать всё возможное из CSS.
— Ха! Мне кажется, CSS меняется слишком быстро для своего же блага.
— Ну, не всё сразу!
— Ха! Погоди, в смысле?
— Ты жалуешься, что CSS трудный, и одновременно жалуешься, что люди делают инструменты для его улучшения!
— Возможно! Но одними инструментами не исправишь CSS!
— А вот здесь тебе поможет методология CSS!
Использование методологий CSS для надёжного сопровождения
Инструменты вроде CSS-препроцессоров и CSS-постпроцессоров прошли долгий путь к повышению удобства разработки на CSS. Но одних этих инструментов недостаточно для решения проблемы с поддержкой больших кодовых баз CSS. Чтобы решить эту проблему, начали создавать разные методические рекомендации о том, как писать CSS — обычно их называют методологии CSS.
Прежде чем углубиться в какую-то конкретную методологию CSS, важно понять, по каким причинам долговременная поддержка CSS настолько сложна. Ключевая проблема — в глобальной природе CSS. Каждый установленный вами стиль глобально применяется ко всем частям страницы. На вас возлагается работа или ввести подробную конвенцию именований для поддержки уникальных названий классов, или ввести правила CSS specificity для определения, какой стиль должен применяться к каждому элементу. Методологии CSS предлагают организованный способ писать CSS, чтобы избежать этих болевых точек в больших кодовых базах. Рассмотрим некоторые популярные методологии в хронологическом порядке.
OOCSS
OOCSS (Object Oriented CSS) впервые представили в 2009 году как методологию, на двух основных принципах. Первый принцип — отделять структуру от оболочки. Это значит, что CSS с определением структуры (как макет) не должен смешиваться с CSS, который определяет оболочку (как цвета, шрифты и т.д.). Так проще переделывать оболочку, то есть внешний вид приложения. Второй принцип — отделять контент от контейнера. Это значит представлять элементы как повторно используемые объекты с ключевой идеей, что объект должен выглядеть одинаково независимо от своего положения на странице.
OOCSS предлагает хорошо продуманные методические рекомендации, но не очень точно описывает специфику этого подхода. Последующие методологии вроде SMACSS взяли ключевые концепции и добавили больше подробностей, чтобы с ними было легче работать.
SMACSS
В SMACSS гораздо больше конкретной специфики, чем в OOCSS, но эта методология по-прежнему требует тщательного обдумывания, какие правила CSS следует отнести в каждую из категорий. Последующие подходы вроде BEM частично берут на себя принятие решений, так что их проще использовать на практике.
Представленная в 2010 году методология BEM (Block, Element, Modifier) основана на разделении пользовательского интерфейса на независимые блоки. Блок — это повторно используемый компонент (примером может быть поисковая форма, определённая как ). Элемент представляет собой меньшую часть блока, и его нельзя повторно использовать самого по себе (примером может быть кнопка из поисковой формы, определённая как Search ). Модификатор — это сущность, определяющая внешний вид, состояние или поведение блока или элемента (примером будет отключённая кнопка поисковой формы, определённая как Search ).
Методология BEM проста для понимания, с конкретной конвенцией присвоения имён, что позволяет новичкам применять её без необходимости принимать какие-то сложные решения. Обратная сторона медали в том, что некоторые названия классов довольно многословны и не соответствуют традиционным правилам указания семантических названий. Впоследствии появились новые методологии вроде Atomic CSS, где этот нетрадиционный подход вышел на принципиально новый уровень!
Atomic CSS
Если первой вашей реакцией на этот пример будет отпрянуть в ужасе — вы не одиноки. Многие рассматривают эту методологию как абсолютное нарушение устоявшихся лучших практик CSS. Однако прошло немало содержательных дискуссий, где подвергается сомнению эффективность этих практик в некоторых случаях. Эта статья хорошо расставляет акценты, как традиционное разделение задач приводит к созданию CSS, который зависит от HTML (даже при использовании методологий вроде BEM), в то время как «атомарный» или функциональный подход заставляет создавать HTML, который зависит от CSS. Оба варианта приемлемы, но при ближайшем рассмотрении вы обнаружите, что полное разделение CSS и HTML невозможно в принципе!
Другие методологии CSS вроде CSS в JS на самом деле включают в себя понимание, что CSS и HTML всегда будут зависеть друг от друга. Это признание привело к созданию одной из самых противоречивых методологий на сегодняшний день…
CSS в JS
Методология CSS в JS представлена в 2014 году. Она базируется на определении стилей CSS не в отдельной таблице стилей, а прямо внутри каждого компонента. Данная методология разработана для фреймворка React JavaScript (который и сам выбрал неоднозначный подход определения HTML для компонента прямо в JavaScript вместо отдельного файла HTML). Изначально методология использовала вложенные стили, но в поздних реализациях JavaScript генерировал код CSS (с уникальными названиями классов по компоненту) и вставлял его в документ вместе с тегом style.
Методология CSS в JS тоже полностью противоречит устоявшимся лучшим практикам CSS по разделению содержимого. Дело в том, что со временем наши способы использования веба кардинально изменились. Изначально веб состоял в основном из статичных сайтов — там отделение содержимого HTML от представления CSS вполне имело смысл. В наше время Сеть используется для динамических веб-приложений — здесь имеют смысл повторно используемые компоненты.
Цель методологии CSS в JS состоит в том, чтобы разрешить определять компоненты с жёсткими границами, которые состоят из своих собственных инкапсулированных HTML/CSS/JS, так что CSS из одного компонента не имеет возможности повлиять на другие компоненты. React стал одним из первых популярных фреймворков, который продвигал эти компоненты с жёсткими границами. Под его влиянием такие же компоненты ввели в других популярных фреймворках, таких как Angular, Ember и Vue.js. Важно отметить, что методология CSS в JS относительно новая, так что в этой области продолжается много экспериментов — разработчики пытаются установить новые лучшие практики для CSS в эпоху компонентов для веб-приложений.
Легко запутаться в таком большом количестве разных методологий CSS, но важно помнить, что не существует единственно верного подхода — вы должны представлять их как разные доступные инструменты, которые можно использовать, когда у вас на руках достаточно сложная кодовая база CSS. Здесь удобно иметь выбор из разных продуманных подходов, так что все последние эксперименты в этой области принесут пользу каждому разработчику в долговременной перспективе!
Заключение
Вот так выглядит современный CSS в двух словах. Мы обсудили использование CSS для базовых стилей со свойствами оформления, использование CSS для разметки с использованием float, flexbox и grid, использование CSS-препроцессора для нового синтаксиса, такого как переменные и mixin’ы, использование CSS-постпроцессора для функций трансформации, таких как добавление вендорных префиксов, а также методологии CSS для надёжного сопровождения и преодоления глобальной природы стилей CSS. У нас не было шанса подробно разобраться во многих других функциях CSS, таких как продвинутые селекторы, переходы, анимации, формы, динамические переменные — список можно продолжать долго. В CSS многое можно обсудить — если кто-то говорит, что это просто, то он наверное и половины не знает!
С современным CSS определённо может быть неудобно работать, потому что он продолжает изменяться и развиваться быстрыми темпами. Но важно помнить исторический контекст, как развивалась Сеть с годами — и приятно знать, что куча умных людей работают над конкретными инструментами и методологиями, чтобы лучшие практики CSS развивались вместе с вебом. Сейчас захватывающее время, чтобы быть веб-разработчиком, и я надеюсь, что эта информация послужит картой в вашем путешествии!
— Ха! Но все крутые парни по-прежнему ненавидят CSS, верно?
— Как я говорил, не всё сразу!
—… ладно. Дай хоть насладиться CSS-мемами, потому что CSS КРУТ [надпись выходит за пределы границ]