Продолжение обсуждения из Стилизация Discourse с помощью переменных: Покажи и расскажи:
Я полностью ценю усилия по улучшению работы с темами в Discourse! Однако я не до конца убеждён, что подход с добавлением большого количества CSS-переменных, описанный в вышеупомянутой теме, является оптимальным решением. Хочу поделиться несколькими мыслями на этот счёт.
Я сам экспериментировал с этим подходом в шаблоне темы Canvas, который по сути представляет собой набор настраиваемых переменных для создания базовых тем:
:root {
/* Макет */
--d-max-width: 1110px;
--canvas-nav-space: 0.75rem;
--canvas-content-padding: 1.5rem;
--canvas-topic-list-padding: 0.8em;
/* Базовые стили */
--canvas-background: var(--secondary);
--canvas-surface: var(--secondary);
--canvas-border: 1px solid var(--primary-500);
--canvas-border-light: 1px solid var(--primary-200);
/* Радиус скругления границ */
--d-border-radius: 2px;
--d-border-radius-large: 2px;
--d-button-border-radius: 2px;
--d-input-border-radius: var(--d-button-border-radius);
--d-nav-pill-border-radius: var(--d-button-border-radius);
/* Стили кнопок */
--canvas-button-padding: 0.5em 0.65em;
--canvas-button-primary-padding: 0.5em 0.65em;
/* Заголовок */
--canvas-header-height: 4rem;
--canvas-header-background: var(--header_background);
--canvas-header-border: none;
--canvas-header-shadow: var(--shadow-header);
/* Боковая панель */
--d-sidebar-width: 17em;
--d-sidebar-background: var(--secondary);
--canvas-sidebar-border: 1px solid var(--primary-low);
--canvas-sidebar-scrollbar: var(--scrollbarWidth);
--d-sidebar-row-height: 2.2em;
--d-sidebar-highlight-background: var(--primary-low);
/* И ещё несколько... */
}
Хотя это неплохо работает для простых корректировок, при попытке масштабировать этот подход я столкнулся с рядом ограничений:
Когнитивная нагрузка и доступность
Обширный список переменных фактически требует использования таблицы соответствий. Это кажется оторванным от того, как обычно работают в компонентных фреймворках, где я ожидаю стилизовать именно компоненты. Возможно, это только моё мнение, но мне кажется, что такая модель мышления смещается с «Я хочу стилизовать этот компонент» на «Мне нужно найти правильное имя переменной».
Отсутствие каскадной логики
Текущая реализация присваивает переменным жёстко заданные значения без установления правильной иерархии каскада:
--d-sidebar-link-color: var(--primary-high);
--d-nav-background-color--active: transparent;
--table-border-width: 1px;
Это означает, что нет наследования от более общих переменных, таких как --link-color или --border-width. Если я хочу внести системные изменения, мне приходится обновлять множество конкретных переменных вместо того, чтобы изменить одно базовое значение.
Разрыв между дизайном и разработкой
Думаю, такой подход создаёт трение при работе между инструментами дизайна (например, Figma) и реализацией. Системы дизайна обычно используют семантические переменные, которые не имеют прямого соответствия этим очень специфичным для реализации переменным.
Альтернативный подход, использующий компонентную архитектуру
Я считаю, что ту же цель можно достичь более естественно, сочетая базовые семантические переменные с надёжным выбором компонентов. Вместо длинного списка конкретных переменных, что если мы могли бы полагаться на уникальные и последовательно именованные классы компонентов по всему Discourse? Например: .d-sidebar, .d-topic-list, .d-header.
А затем дополнить это небольшим набором базовых переменных, которые действительно работают с каскадом так, как задумано в CSS:
/* Установка основы дизайна */
:root {
--d-border-width: 2px;
--d-surface-color: #3498db;
--d-space-1: 1rem;
}
/* Переопределение на уровне компонента при необходимости */
.d-topic-list,
.d-sidebar {
--d-border-width: 1px;
}
Для меня это выглядит более естественным для CSS. Я задаю глобальные стили, а затем уточняю их там, где это нужно. Когда я хочу изменить внешний вид границ во всём приложении, я меняю одну переменную. Когда мне нужно, чтобы боковая панель выглядела иначе, я выбираю именно её.
