Отже, чи можемо ми використовувати змінні CSS?

318

Від автора: після всіх розмов останнього часу про те, що ми, нарешті, можемо використовувати CSS Grid, мені стало цікаво: які ще дивовижні функції CSS я можу використовувати вже зараз? CSS змінні — перше, що спадало на думку. Минуло багато часу з тих пір, як я вперше почув про змінних CSS і про те, що вони вводять в розробку інтерфейсу абсолютно новий набір інструментів і новий спосіб мислення.

Історичний екскурс по змінним CSS

Змінних CSS були введені ще кілька років тому, але, схоже, вони так і не отримали широкого розповсюдження. Враховуючи популярність таких препроцесорів, як Sass, front-end розробники не поспішають братися за них.

Особисто мене ця тема зацікавила ще в 2014 році, і з тих пір вона міцно входить в сферу моїх інтересів. Однак тільки зараз я замислююся над тим, щоб використовувати їх безпосередньо в робочих проектах. І я покажу вам, як просто і легко це робиться.

Оголошення змінних

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

–my-reusable-value: 20px;

Отримання доступу до змінних

Використовувати властивість досить просто. Ми звертаємося до нього через функцію var() і використовуємо властивість, оголошене вище.

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

Хіба це не просто і класно? Змінні CSS прості у використанні і досить легко запам’ятовуються. Найбільша проблема з змінними CSS (як і з більшістю компонентів CSS) — це вибрати правильний час і місце їх використання. Розкидати їх безладно — це практично гарантований спосіб створити плутанину в таблиці стилів, і при налагодженні це, ймовірно, створить складнощі.

Слід враховувати належні варіанти і стратегії їх використання, і саме на це слід звернути увагу в першу чергу.

Цікавий випадок використання: Адаптивні модулі

У наступному прикладі я покажу базовий приклад того, як я в даний час створюю адаптивні компоненти з використанням змінних Sass. Потім я покажу, як це можна покращити за допомогою змінних CSS — так, як неможливо зробити з допомогою препроцесора. Цей конкретний варіант використання застосовується не до всіх змінним, але він ілюструє, як по-різному можуть використовуватися змінні CSS. Приклад Sass

Існує кілька різних методологій для використання Sass, які я випробував. Моя поточна версія призначена для розміщення медіа-запитів в блоках CSS, які я хочу змінити. Я можу використовувати змінну, стандартний CSS, міксин або розширення, щоб змінити цей елемент, не додаючи стилі для компонента тут і там.

Одна з проблем полягає в наявності декількох медіа-запитів і безлічі змінних, які є спорідненими, але не пов’язаними. Я міг би використовувати карти для змінних, які допомогли б зробити все більш організованим, але, думаю, що основна проблема полягає в тому, що ми використовуємо кілька змінних для визначення одного властивості. Це просто неправильно.

Змінні Sass використовуються насамперед інших елементів, що означає, що ми повинні планувати кожен спосіб, з допомогою якого будемо їх використовувати. Вони роблять розробку простіше, але технічно не надають нам ніяких нових супер-сил.

Вихід пропонують змінні CSS

Змінні CSS не обов’язково повинні бути оголошені раніше інших елементів, вони є динамічними. Це корисно в багатьох відносинах. Тепер ми можемо, виходячи з певних умов, змінювати змінні з будь-якого місця і для певних контекстів, таких як медіа-запити.

Працюючи зі стилями медіа-запитів безпосередньо, ми можемо зменшити кількість медіа-запитів, які визначаються для адаптивних стилів. Це також дозволяє побачити загальні стилі відступів і типографіки для різних форматів.

Я вважаю, що адаптивні проекти і теми — це два чудових варіанти використання для змінних CSS, але існує і багато інших можливостей.

Чим змінні CSS відрізняються від змінних Sass?

Змінні Sass і змінні CSS — це два різних види, кожен з яких має свої переваги і недоліки.
Змінні Sass можуть бути організовані ефективніше

З-за популярності Sass і більше програмної природи цієї мови, з часом ми отримали більш глибоко структуровані формування. Мені особливо подобаються карти Sass і об’єднання в картах змінних різних типів. В такі карти досить часто включаються кольори, розміри і ярлики для шляхів.

З-за відносно меншого використання для змінних CSS ще не сформувалися такі просунуті методи. Карти і масиви, можливо, будуть реалізовані по іншому для CSS, і ці нові організаційні шаблони будуть слідувати інноваційним підходам і вирішувати проблеми відмінно від Sass.

Змінні CSS можуть бути змінені динамічно

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

Для мене це є ключовою відмінністю змінних CSS. Буде цікаво подивитися, як люди використовують цю функцію і стане вона настільки корисною і потужною, наскільки дозволяє її потенціал.

Змінні CSS — це стандартна функція для браузера

Я особисто вважаю, що чим більше речей ми зараз зможемо видалити з Webpack, Gulp або будь-якого іншого нового фреймворку, тим краще. Підтримка цікавих нових функцій в браузерах означає, що нам не потрібно покладатися на компіляцію і JavaScript-фреймворки, щоб зробити речі, які, на думку розробників, важливі. Я б ризикнув припустити, що високий відсоток front-end розробників так чи інакше використовує змінні в своїх CSS-стилі, тому використовувати CSS-змінні, як функцію ядра, здається розумними. Це означає, що на етапі побудови (який, я думаю, всі з цим погодяться, і так стає все більш і більш складним) буде на один процес менше, а загалом все стане більш узгодженим.

Яка ситуація з підтримкою?

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

У всякому разі це на 78.11% вище, ніж для CSS Grid (на момент написання статті). Але підтримка в IE11 може стати проблемою.

Так чи можемо ми власне використовувати змінні CSS?

Я думаю, час прийшов. Підтримка в IE11 не стане краще, і по ситуації з попередніми версіями Windows ми знаємо, що деяким людям потрібно багато часу, щоб перейти на нову версію. Але в цілому підтримка в сучасних браузерах досить повна, що означає, що ми повинні пробувати змінні CSS і експериментувати з їх можливостями.

Це не означає, що ми можемо забути про підтримку старих браузерів. Слід передбачати основну резервну систему з використанням підтримуваних тегів або навіть полифиллов для старих браузерів, тим більше, якщо фактичне відображення сайту в старих браузерах сильно спотворено.

Це неймовірне час для front-end розробників, і я не можу дочекатися, коли приступлю до використання цих нових технологій у своїх робочих проектах.