CSS-live.ru

Ну что, можно уже использовать CSS-переменные?

Перевод статьи So, Can We Use CSS Variables Yet? с сайта webdesignerdepot.com для CSS-live.ru, автор — Адам Хьюз

Весь этот шум вокруг CSS-гридов в последнее время заставил меня задуматься: какие ещё потрясающие CSS-фичи доступны нам сегодня?

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

Еще раз вкратце о CSS-переменных

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

Я впервые увлёкся CSS-переменными ещё в 2014, и с тех пор они не выходят у меня из головы. И только сейчас я внедряю их в свои реальные проекты, и покажу вам, как легко их использовать.

Объявление переменной

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

--my-reusable-value: 20px;

Доступ к переменной

Работать со свойством также просто. Сначала обращаемся к нему с помощью функции var(), а уже внутри используем свойство, объявленное выше.

padding: var(--my-reusable-value);

Просто и восхитительно, правда?

CSS-переменные легко использовать и запомнить. Наибольшая проблема с ними (как и в CSS в целом) — правильно выбрать время и место для их использования. Если разбрасывать их по коду как попало, стили неизбежно окажутся в беспорядке, и отлаживать это всё станет очень трудно.

Следует рассматривать подходящие применения и стратегии работы с ними, и именно на это стоит обратить пристальное внимание.

Интересный способ использования: отзывчивые модули

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

Пример с Sass

See the Pen CSS Variables — responsive use case without CSS Variables by Максим (@psywalker) on CodePen.

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

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

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

CSS-переменные спешат на выручку

See the Pen CSS Variables — responsive use case by Максим (@psywalker) on CodePen.

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

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

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

В чём разница между CSS- и Sass-переменными?

Между Sass- и CSS-переменными большая разница, и у каждых есть свои плюсы и минусы.

Sass-переменные можно лучше организовать

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

CSS-переменные относительно молоды, поэтому правильные подходы ещё не развились. Sass maps и массивы невозможно представить в CSS, поэтому этим новым организационным паттернам придётся привносить что-то новое и решать проблемы иначе, чем в Sass.

CSS-переменные изменяются динамически

CSS-переменные обрабатываются динамически браузером в процессе выполнения, тогда как Sass-переменные используются во время компиляции CSS.

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

CSS-переменные — это стандартная браузерная фича

Я считаю, что чем больше можно удалить из Webpack, Gulp и какой-там-новый-фреймворк-сейчас-в-моде, тем лучше. Благодаря интересным браузерным фичам не придётся полагаться на компиляцию и JavaScript-фреймворки, в том, что важно для разработчиков. Смею полагать, что бОльшая часть фронтенд-разработчиков используют переменные в CSS так или иначе, поэтому, если все начнут использовать эту встроенную фичу, это будет выглядеть разумно. А значит, этап сборки (и так уже слишком необъятный, с чем, думаю, никто не поспорит) станет на одну частичку меньше, и в интернете будет больше порядка.

А что с поддержкой браузерами?

Поддержка выглядит замечательно с одним вопиющим исключением: IE 11. Большинство современных браузеров поддерживают CSS-переменные, только в Edge есть некоторые баги.

78.11% — выше чем у CSS-гридов (на момент написания этой статьи), но из-за отсутствия поддержки в IE11 могут быть проблемы.

Ну что, можно уже использовать CSS-переменные?

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

Но забывать об ответственности за поддержку старых браузеров также не стоит. Систему простейших запасных вариантов вроде директивы @supports, или даже полифилл, для старых браузеров всё же стоит рассматривать, а если ваш сайт слишком часто просматривают в старых браузерах, то тем более.

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

P.S. Это тоже может быть интересно:

10 комментариев

  1. Большое спасибо за статью! Совсем недавно мы начали использовать css переменные в связке с динамическим импортом, что значительно облегчило переключение различных тем проекта. В статье Вы упомянули про полифилы для старых браузеров. Не поделитесь ссылочкой?) В данный момент пришлось написать свой невнятный полифил, который покрывает далеко не весь функционал css переменных.

  2. Вообще не понимаю причину хайпа вокруг CSS-переменных. Пример, который вы написали с media-выражениями — надуман. Ибо можно достаточно просто написать mixin, определить несколько переменных для разных размеров экрана и подключать media-выражения одной строчкой. При этом вы не теряете поддержку браузеров.
    Динамическая природа — единственное преимущество, которое я здесь вижу. Но ничего не мешает мне использовать inline стили и менять их динамически.
    Имхо.

  3. Нет никакого смысла в переменных, нет смысла в Import , нет смысла в WEb Components.
    Все как писали на react/angular + styled components так и будут писать

  4. Вот если бы она умела работать с процентами, тогда да. (допустим делать высоту блока такую же как его ширина, адаптивно)
    А так бесполезная хрень, максиму для чего можно использовать — это влезть в псевдоэлемент через JS.

    1. умеют работать с процентами и работать адаптивно. Через calc() например высчитывать относительно ширины экрана, и приравнивать к переменной высоты. Основная фишка как раз и заключается что css переменные можно изменять на лету и делать расчёты динамически с постоянными и относительными величинами.

  5. Каждый раз читаю о чем-то новым с большой болью в сердце :( Ибо что иностранные заказчики, что наши часто указывают разработку от ie-9, только недавно отказались от ie-8 и проблема в том, что многие до сих пользуются XP. Да, в современных, крутых проектах мы начинаем с ie-11, указывая для всех старых браузеров — «МОЛ ИДИТЕ И СКАЧАЙТЕ НОРМАЛЬНЫЙ БРАУЗЕР».
    Балуемся в перерывах flexbox’ом и гридами, грустим :( Поэтому не верю я в то, что переменные будут многими использоваться. Уж точно, пока все «большие дяди» не поймут небезопасность использования XP и не перейдут на что-то новое.

    1. А при чём тут XP? То что, от его поддержки отказались некоторые браузеры, конечно, говорит в сторону его обновления, но, во-первых, это произошло не так давно, во-вторых, вероятно, причина отказа надумана.
      Поэтому я не думаю что поддержка суперстарых браузеров напрямую связана с XP, а связана, вероятно, с самими заказчиками…

  6. Ну тут история как с IE6. Чтобы в продакшене верстать, то надо будет добавлять все костыли пока оно не умрёт. Сейчас разве что жать когда IE умрёт окончательно…

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

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

    Вот такие пироги.

Оставить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

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