Поговорим о темах? :)

Форум /

В bem-components используется подход с использованием модификатора theme. У нас на проекте он тоже долго используется.

Простой пример на button https://github.com/bem/bem-components/blob/v6/design/common.blocks/button/_theme/button_theme_islands.post.css

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

Но есть другой подход в виде уровней

common.blocks/
  button/

light.theme
  button/

dark.theme
  button/

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

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

В общем... Кто какие подходы использует? А может кто-то их совмещает?

П.Н. Сейчас размышляю над плюсами/минусами для нас от второго подхода.

6 years ago

ijakparov

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

6 years ago

koloskof

Контролы реагируют на уровень Темы из https://github.com/whitepapertools/whitepaper-bem/tree/master/theme так же как и все остальные интерфейсные сущности.

На уровне компонентс лежат переменные https://github.com/bemdesign/bem-components/blob/master/design/common.blocks/component/_whitepaper/component_whitepaper_default.post.css, которые отвечаю за все состояния контролов, но при этом они так же наследуются от тех же основных переменных, что и цвета состояний блоков и типографики, вычисляются через математику (путем изменения HSL).

Благодаря Custom Properties, контролы подстраиваются под цветовую схему блока в который они помещаются (в зависимости от того, какая модификация themecolor* у ближайшего родителя).

Это дает возможность делать разноТематические вставки.

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

6 years ago

kompolom

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

6 years ago

belozer

Сейчас прихожу к тому, что предложил @koloskof Вначале смутило, что переменные лежат в классах (но поддержка браузеров ещё не совсем гуд). Но ничего ведь не мешает их засовывать в :root.

Stylus

:root {
  @extend .theme_color_default
  @extend .theme_size_default
  @extend .theme_gap_default
  .. и т.д.
}

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

Чтобы оставлять комментарии, необходимо авторизоваться.