Есть такая разметка
<section class="section section-icon section-icon--image--paper">
<div class="container">
<div class="section-icon__left">
<h2 class="section__heading">Heading 2</h2>
<img src="/img/paper.svg" alt="" />
<p>Text section</p>
</div>
</div>
</section>
Интересует правильно ли используется подход БЭМ?
Может ли содержать класс section-icon--image--paper модификатор и его значение, что изменяет внешний вид секции в целом?
Посоветуйте, пожалуйста, ссылку на пример реализации просмотра превью изображений в открытом попап окне, которая бы была сверстана по бэм. Интересует сама верста + js реализация. Может есть ссылки на сайты, или статьи на которых можно посмотреть.
Здравствуйте. Подскажите, пожалуйста, как отобразить блок popup при эффекте ховер на компоненте select из bem-components?
Заранее благодарен.
Допустим у меня вот такая вёрстка header'а
<header class="page__header header">
<nav class="header__nav nav">
<ul class="nav__links">
<li class="nav__item">
<a href="#" class="nav__link"></a>
</li>
</ul>
</nav>
</header>
Как мне это разбить на блоки header, nav и их элементы? Использую handlebars. Если я напишу шаблон для блока header, будет вот так, верно?
<header class="page__header header">
{{>nav/nav.hbs}}
</header>
Начав писать шаблон, я столкнулся с проблемой, во первых - создавая новый блок, который входит в другой блок, как мне реализовать миксы - внешнюю геометрию и позиционирование как я могу писать класс header__nav, если nav допустим не всегда используется как элемент header'а?
В итоге получается примерно вот так. Получается что каждая html вложенность это импорт, это нормально? Я только начинаю знакомиться с методологией и шаблонизаторами
index.hbs
<body class="page">
{{>header/header.hbs}}
{{>article/article.hbs}}
{{>footer/footer.hbs}}
</body>
header.hbs
<header class="page__header header">
{{>nav/nav.hbs}}
</header>
nav.hbs // вот именно здесь главный вопрос с классом header__nav, куда мне его девать если nav не должен быть зависим от header'a?
<nav class="??header__nav?? nav">
{{>nav/__links/nav__links.hbs}}
</nav>
nav__links.hbs
<ul class="nav__links">
{{#each nav__links}}
{{>nav/__item/nav__item.hbs}}
{{/each}}
</ul>
nav__item.hbs
<li class="nav__item">
{{>nav/__link/nav__link.hbs}}
</li>
nav__link.hbs
<a href="#{{this.link}}" class="nav__link">{{this.text}}</a>
На вход я подаю вот по типу таких данных например, типовая навигация для лендинга:
nav__links: [
{ link: "about", text: "about us" },
{ link: "prices", text: "pricelist" },
{ link: "team", text: "our team" },
{ link: "contact", text: "contact us" },
]
По файловой структуре получается вот так:
Выглядит довольно запутанно и неявно, иерархию не видно сразу. Заодно вопрос, обязательно ли в каждую сущность/модификатор добавлять все файлы технологий? Чаще всего модификатор изменяет только стили например, нужно ли добавлять пустой файл шаблона и скриптов? Или например если я пока что только верстальщик и поведение описываю редко.
При установке вылезает вот это:
npm WARN deprecated CSSselect@0.4.1: the module is now available as 'css-select'
npm WARN deprecated CSSwhat@0.4.7: the module is now available as 'css-what'
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@0.2.14: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated graceful-fs@1.2.3: please upgrade to graceful-fs 4 for compatibility with current and future versions of Node.js
npm WARN deprecated natives@1.1.6: This module relies on Node.js's internals and will break at some point. Do not use it, and update to graceful-fs@4.x.
npm WARN deprecated minimatch@0.3.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated minimatch@1.0.0: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
npm WARN deprecated formatio@1.1.1: This package is unmaintained. Use @sinonjs/formatio instead
npm WARN deprecated samsam@1.1.2: This package has been deprecated in favour of @sinonjs/samsam
> spawn-sync@1.0.15 postinstall C:\Users\123\AppData\Roaming\npm\node_modules\generator-bem-stub\node_modules\spawn-sync
> node postinstall
npm WARN generator-bem-stub@0.12.0 requires a peer of yo@>=1.0.0 but none is installed. You must install peer dependencies yourself.
+ generator-bem-stub@0.12.0
added 420 packages from 375 contributors in 60.27s
А при запуске это:
fs.js:27
const { Math, Object } = primordials;
^
ReferenceError: primordials is not defined
at fs.js:27:26
at req_ (C:\Users\123\AppData\Roaming\npm\node_modules\generator-bem-stub\node_modules\natives\index.js:143:24)
at Object.req [as require] (C:\Users\123\AppData\Roaming\npm\node_modules\generator-bem-stub\node_modules\natives\index.js:55:10)
at Object.<anonymous> (C:\Users\123\AppData\Roaming\npm\node_modules\generator-bem-stub\node_modules\vinyl-fs\node_modules\graceful-fs\fs.js:1:37)
at Module._compile (internal/modules/cjs/loader.js:1063:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:1103:10)
at Module.load (internal/modules/cjs/loader.js:914:32)
at Function.Module._load (internal/modules/cjs/loader.js:822:14)
at Module.require (internal/modules/cjs/loader.js:956:19)
at require (internal/modules/cjs/helpers.js:74:18)
Как исправить?
Здравствуйте, подскажите пожалуйста, корректно ли с точки зрения БЭМ такое миксование?
<div class="block1">
<div class="block2 block1__elem1">
<div class="block2__elem1 block1__elem2"></div>
<div class="block2__elem2 block1__elem3"></div>
</div>
</div>
Доброго времени суток. Подскажите, пожалуйста, если есть знающие люди, как подключать изображения в bemgo?
Добрый день, друзья! Никак не могу разобраться.. Подскажите пожалуйста, есть ли возможность автоматической генерации структуры папок и css файлов на основе написания их в чистом html?
Т.е. например, я пишу:
<div class="search search_theme_sand">
И автоматически, или по нажатию "волшебной" кнопки у меня генерируется структура:
common.bloks
search
_theme_sand
search_theme_sand.css
search.css
Нашел вроде как bemgo, но что-то у меня ничего не работает
Привет. Имеются две одинаковых навигации по смыслу, но с некоторыми отличиями во внешнем виде, поэтому планирую использовать модификаторы с разными темами. Но по идеи привязать название к цвету или к расположению бессмысленно, так как эти параметры могут поменяться. Как лучше всего назвать темы для этих модификаторов? За какой смысл цепляться? И стоит ли модификаторы давать на каждый элемент или можно просто дать на контейнер и наследовать через CSS? Буду благодарен за ответы
Пример моего HTML для этих навигаций:
<ul class="navigation-list navigation-list_theme-1">
<li class="navigation-list__item navigation-list__item_theme-1">
<a class="navigation-list__link navigation-list__link_theme-1">Пункт 1</a>
</li>
</ul>
<ul class="navigation-list navigation-list_theme-2">
<li class="navigation-list__item navigation-list__item_theme-2">
<a class="navigation-list__link navigation-list__link_theme-2">Пункт 1</a>
</li>
</ul>
Скрин внешнего вида:
Всем привет! Пытаюсь безрезультатно найти инструмент, который из HTML кода с БЭМ классами автоматически создавал бы папки и файлы CSS. Чтобы вручную это не делать. Нашел bemgo. Там вроде написано, что он генерирует. Но при этом вроде как нужно самому делать. Может я чего-то не понял. Еще bem-tools-create, но там вручную все надо создавать. При этом я еще не очень понял как эти команды выполнять, через терминал не работает почему-то.
Добрый день!
Поясните, пожалуйста, общие рекомендации оформления блока кнопки.
Знакомясь с методологией немного запутался. В разделе "Быстрый старт" указано, что блок не должен влиять на свое окружение,
т. е. блоку не следует задавать внешнюю геометрию (в виде отступов, границ, влияющих на размеры) и позиционирование.
Тут понятно. Но далее, в разделе "Внешняя геометрия и позиционирование", в примере оформления позиционирования блока button содержится правило, в котором задается border: 1px .
CSS-реализация кнопки:
.button { font-family: Arial, sans-serif; text-align: center; border: 1px solid black; /* Рамка */ } .header__button { margin: 30px; /* Отступ */ position: relative; }
Насколько правильно согласно бэм методологии задавать границу кнопке на классе button? Нормальная ли это практика (как в примере выше) или все же более правильный подход для задания границы:
.button { box-shadow: 0 0 0 1px black; }
.page__button { border: 1px solid black; }
.button_wiew_page { box-shadow: 0 0 0 1px black; }
И можно ли задавать блоку padding'и? С одной стороны - это внутреннее оформление блока, а с другой стороны они тоже влияют на размер.
До TechTrain осталось чуть больше недели, а мы во всю готовимся к БЭМ-дебатам. Приходите на площадку поболеть за участников или выступите в одном из раундов. Чтобы принять участие, свяжитесь с нами любым удобным способом.
Доброго. Только начал осваивать БЭМ. Подскажите, что в данном случае не так, и как следовало бы правильно сделать?
<header class="header">
<div class="header__text">
<p class="text-head"> Заголовок </p>
<ul class="text-main">
<li class="text-main__item"> Пункт 1 </li>
<li class="text-main__item"> Пункт 2 </li>
<li class="text-main__item"> Пункт 3 </li>
<li class="text-main__item"> Пункт 4 </li>
</ul>
</div>
<div class="header__logo">
<img src="#" alt="" class="logo">
</div>
</header>
Приветствую. Господа подскажите мне как gulp-bem-bundle-builder прокинуть свой naming. Просто обидно. Всё настроил, везде naming мой работает, собираю html, bemjson.js. Везде всё типтоп, а вот собрать бандл по итогу нельзя нормально ибо builder использует стандартный нейминг. Я то уже склоняюсь на стандартный перейти, но это же не дело, всё таки как-то то можно его заставить собирать с моим неймингом.
Если что
function style(path) {
builder = bundleBuilder({
levels: [
'src/common.block',
'src/' + path + '.block'
]
});
return src(['./src/' + path + '.bundles/deps.bemjson.js'])
.pipe(builder({
css: bundle => bundle.src('css').pipe($.concat('style.css')),
}))
.pipe(dest('dist/' + path + '/css'));
}
содержимое .bemrc
module.exports = {
root: true,
levels: [
{
path: 'src/',
naming: {
delims: {
elem: '__',
mod: { name: '--', val: '_' }
},
wordPattern: '[a-zA-Z0-9]+'
}
}
],
modules: {
'bem-tools': {
plugins: {
create: {
levels: {
"src/*.block": {
techs: ['css', 'deps.js'],
templateFolder: '.bem/templates',
templates: {
'js-modules': '.bem/templates/js',
'pug-modules': '.bem/templates/pug'
},
techsTemplates: {
js: 'js-modules',
pug: 'pug-modules'
}
}
}
}
}
}
}
}
C содержимым deps.bemjson.js всё в порядке, если моды создаю используя классический нейминг он собирает.
24-25 августа в Санкт-Петербурге пройдёт большой IT-фестиваль TechTrain 2019 для всех, кто любит IT-инженерию, технологии и разработку ПО. Мы не стоим в стороне и везём на фестиваль стенд и доклад Алексея Хохулина «State of BEM 2019. Эволюция большого фронтенда». Кстати, на стенде мы организуем БЭМ-дебаты, если вы хотите принять участие, напишите нам в личные сообщения — расскажем детали.
Stayed BEMed с нами на TechTrain.
Здравствуйте!
Такой вопрос.
Например создаем секцию с классом intro:
< section class="intro">
Как правильно задать класс заголовка в этой секции:
1) < h1 class="intro_title">
2)< h1 class="intro intro_title">
3) < h1 class="title">
Вы просили и мы сделаем!
19 июля в 18:30 в питерском офисе Яндекса пройдет БЭМап — митап по БЭМ.
Мы начнем с самых азов, расскажем зачем БЭМ в 2019 и куда он движется. Познакомим с основанной на БЭМ дизайн-системой whitepapper, позволяющей верстать без написания CSS. Поговорим, как применять идеи БЭМ в проекте на React с использованием пакетов.
И, конечно, ответим на все ваши вопросы.
Ноутбук приносить не обязательно. После встречи мы опубликуем все материалы, ссылки и видео.
Встречи по БЭМ всегда бесплатны, но нужно зарегистрироваться заранее: количество мест ограничено.
Stay BEMed!
Можете сказать правильно я сделал или нет ? ``
<head>
<link rel="stylesheet" href="style.css">
<link rel="stylesheet" href="media.css">
<meta name="keywords" content="Жизнь,работа,новости">
<meta name="description" content="MyLife - Это прекрасная жизнь, чтобы иди дальше....">
<title> Сайт </title>
</head>
<body>
<header>
<div class="container">
<div class="menu">
<div class="block-logo">
<img class="block-logo__image"src="Image/Logo.png">
</div>
<div class="block-button">
<a class="block-button__text" href="#">work</a>
<a class="block-button__text" href="#">news</a>
<a class="block-button__text" href="#">about me</a>
</div>
</div>
<h1 class="name">Slice of my life.</h1>
<div class="block-schroll">
<img class="block-schroll__img" src="Image/Mouse.png">
<p class="block-schroll__text">Schroll to see more</p>
</div>
</div>
</header>
</body>
``
Доброго времени суток. Правильная ли форма с точки зрения БЭМ? Больше всего вопросов вызвало присваивание классов элементам fieldset и label
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<title>Title</title>
<link rel="stylesheet" href="merged/merge.min.css"/>
</head>
<body>
<div class="header">
<span class="logo">
<img src="" alt="" />
</span>
</div>
<div class="main">
<form class="auth-form" enctype="application/x-www-form-urlencoded" method="post">
<fieldset class="auth-form__fieldset">
<label class="auth-form__label">Логин</label>
<input type="text" class="auth-form__input_text"/>
</fieldset>
</form>
</div>
</body>
</html>
Привет!
Мы рады пригласить вас на очередной BEMup — митап по БЭМ, который пройдет в Москве 14 июня в 19:00. Эту встречу мы посвятим применению методологии БЭМ на React-проектах.
В программе:
— обзор @bem-react/classname — самого минималистичного пакета для генерации имен CSS-классов по БЭМ с поддержкой TypeScript. — статические и динамические модификаторы с помощью @bem-react/core. Рассмотрим правильные способы композиции, способы расширения компонентов и другие тонкости использования. — управление зависимостями благодаря @bem-react/di: зачем компонентам реестры, как правильно организовать эксперименты на проекте, нужно ли класть все зависимости в реестр, организация кода под разные платформы, разделение кода в модификаторах и блоках.
И, конечно же, ответим на все ваши вопросы!
Ноутбук приносить необязательно. После встречи мы опубликуем все материалы, ссылки и видео.
Встречи по БЭМ бесплатны, но нужно зарегистрироваться заранее: количество мест ограничено.
Stay BEMed!
Друзья, начинаем регистрацию на очередной BEMup — митап по БЭМ, который пройдет в Москве 24 мая в 19:00.
На эту встречу мы пригласили дизайнеров рассказать про создание дизайн-системы на основе http://whitepaper.tools.
Регистрируйтесь скорее, количество мест ограничено! https://events.yandex.ru/events/bemup/24-may-2019/
Здравствуйте, подскажите пожалуйста, я создаю проект на framework laravel и хочу использовать файловую структуру БЭМ для моих стилей (scss), соответственно в html разметке у меня блоки и элементы именованы по правилам как в документации.
Вопрос в том что считается ли такая ситуация правильной когда у меня допустим в папке для элемента находиться только один файл ? Потому что js файлы, мне всё таки удобнее было бы хранить в другом месте, не разбивать их как стили.
К примеру:
/header
__logo
header__logo.scss
__menu
__search
Получается что у меня вот в папке __logo будет только один файл. Да и вообще во многих папка может быть только один файл. К примеру если я захочу добавить модификатор какой то к logo
получится такое:
/header
__logo
_center
_header__logo_center.scss
header__logo.scss
__menu
__search
В папке _center один файл только. Заранее благодарю за ответ.
Пример:
<div class="block-name">
<div class="block-name__item">
<div class="block-name">
<div class="block-name__item">
etc.
</div>
</div>
</div>
</div>
<div class="popup popup_A">
<div class="popup__container">
<div class="popup__header">
<div>Знакомства</div>
<div class="popup__close">x</div>
</div>
<div class="popup__content enabled-notification">
<div class="enabled-notification__title">Включить уведомления</div>
<div class="notification">
<div>
<div class="notification__title">Новое сообщение</div>
<div class="notification__desc">Ирина: Привет! Встретимся сегодня у фонтана в парке</div>
</div>
<div class="notification__icon">
<svg xmlns="http://www.w3.org/2000/svg"></svg>
</div>
</div>
<div class="enabled-notification__text">
Вы разрешаете нам отправлять уведомления о новых сообщениях, комментариях на ваши заметки и т.д.?
</div>
</div>
<div class="popup__footer popup_A__footer">
<button class="btn btn_color_grey popup_A__btn">Нет, спасибо</button>
<div class="divider"></div>
<button class="btn btn_color_blue popup_A__btn">Включить</button>
</div>
</div>
</div>
Блок "popup" ре-используемый, может содержать различный контент. Блок "enabled-notification" уникальный и не будет ре-использоваться. Блок "notification" ре-используемый, может содержать различный контент, в рамках определённых элементов.
Для модификации кнопок (нужно было сделать ширину в 50%), используем микс с модификатором popup_A. В обычном состоянии у "popup" есть только одна кнопка.
.popup_A__footer{
display: flex;
justify-content: space-between;
}
.popup_A__btn{
width: 50%;
}
Ещё есть вопрос по использованию "пустых" тегов-элементов (без классов), допустимо ли это?
<div class="notification">
<div>
<div class="notification__title">Новое сообщение</div>
<div class="notification__desc">Ирина: Привет! Встретимся сегодня у фонтана в парке</div>
</div>
<div class="notification__icon">
<svg xmlns="http://www.w3.org/2000/svg"></svg>
</div>
</div>
Допустим у меня есть блок .article:
<div class="article">
<h1 class="article__heading"></h1>
<img class="artilce__image">
<p class="article__text"></p>
</div>
Я хочу видоизменить его внутри блока .frontpage, при этом сохранив привязку к .article. Для этого я использую микс только к .article:
.frontpage{
&__article{
.article{
&__heading{}
&__image{}
&__text{}
}
}
}
Такой подход (в отличии от миксования к каждому изменному блоку) позволяет мне не засорять пространство имен (никаких .frontpage__article-heading), и вроде бы не ломает модульность.
Соответствует ли он методологии?
Привет. Есть вот такой футер:
который можно разделить на два больших элемента:
И получается такая структура:
footer
footer__wrapper
footer__item footer__item_columns
footer__item footer__item_info
Это правильная структура и названия?
И еще внутри есть такие колонки:
И как лучше всего сделать колонки? Сделать их блоками или элемантами? Как тогда лучше обозвать их? Была идея navbar-column, но в колонке может не быть navbar(последняя колонка). Или сделать это элементами футера? Но тогда слишком много зависимости от футера будет и плюс хочется использовать класс wrapper для колонки примерно так:
noname-column
noname-column__wrapper
noname-column__header
noname-column__content
<div class="infg">
<div class="infg__item">
<div class="infg-icon">
<img src="/images/implant.svg" class="infg__icon" alt="">
</div>
<div class="infg__desc">
<div class="infg__title"></div>
<div class="infg__text"></div>
</div>
</div>
</div>
Вопрос: правильно ли я сделал именование классов согласно БЭМ? Как будет правильно назвать класс 'infg-icon' который находиться в div`?
Уже давно пытаюсь избавиться от боли модификатора _theme у блоков.
У нас 2 темы блока button - публичная и админка, около 2K строк стилей в сумме.
Имхо, блок должен быть максимально реиспользуемым и не тянуть ненужный код. Сейчас под тему запихиваются ВСЕ комбинации модификаторов блока, даже если они не нужны на странице. Это боль в поддержке.
Очень близки идеи http://whitepaper.tools/. В целом работаю тоже в этом направлении.
На данный момент пришёл к использованию 2-х видов переменных.
Задаются через блок theme и модификаторы theme_color_* theme_size_* и т.д.
Провайдят контекст переменных вниз по дереву.
.Theme_color_light {
--color-bg: #f7f7f7;
--coloron-bg: #222;
--color-primary: #222;
--coloron-primary: #fff;
--color-secondary: #777;
--coloron-secondary: #ddd;
--color-surface: #fff;
--coloron-surface: #222;
--color-error: #d00;
--coloron-error: #fff;
--color-success: #090;
--coloron-success: #fff;
}
Задаются с указанием префикса имени блока. Такой способ явно ограничивает пространство имён переменных, чтобы случайно не сломать что-то внутри дерева. И позволяет легко изменять их через модификаторы.
Если спроецировать на мир React, то контекстные переменные - это пропсы, локальные - стейт :)
.Button {
--Button-bg: var(--color-bg);
--Button-border: var(--color-secondary);
--Button-color: var(--color-primary);
--Button-shadow: var(--color-bg);
--Button-fontSize: 1rem;
background: var(--Button-bg);
border: 1px solid var(--Button-bg);
color: var(--Button-color);
padding: 1em 2em;
font-size: var(--Button-fontSize);
transition: .3s;
border-radius: 3px;
}
.Button:hover {
background: var(--Button-color);
color: var(--Button-bg);
cursor: pointer;
box-shadow: 0 10px 20px var(--Button-shadow);
}
.Button_disabled,
.Button_disabled:hover {
background: #ddd;
border-color: #ddd;
color: #999;
cursor: default;
box-shadow: none;
}
Блок получает переменные из контекста и преобразует их в локальные для дальнейшего использования в своих стилях.
Дальше через модификаторы жонглируем уже локальными переменными блока.
.Button_color_action {
--Button-bg: var(--color-action, #00a);
--Button-color: var(--coloron-action, #fff);
}
.Button_color_error {
--Button-bg: var(--color-error, #f00);
--Button-color: var(--coloron-error, #fff);
}
.Button_color_success {
--Button-bg: var(--color-success, #090);
--Button-color: var(--coloron-success, #fff);
}
Данный подход позволяет избавиться от длинных селекторов в css.
Например если мы не хотим использовать локальные переменные, то нужно писать классы таким образом
.Button_color_success {
background: var(--coloron-success, #fff);
color: var(--color-success, #090);
}
.Button_color_success.Button:hover {
background: var(--color-success, #090);
color: var(--coloron-success, #fff);
}
И это только 2 состояние, а там ещё N состояний, включая вложенные элементы...
Локальные переменные, конечно не серебренная пуля и каскады писать придётся. Но как решение вполне может помочь добиться лаконичных селекторов.
После долгих ресёрчей толком не нашёл способа лаконично и предсказуемо описывать переменные. Наиболее лаконичным стилем нашёл подход из Material Design https://material.io/design/color/
В кратце, есть какой-то цвет и для него создаётся рекомендуемый контрастный цвет.
:root {
--color-primary: #000;
--coloron-primary: #fff;
}
В качестве дополнительного задания контраста есть идеи использовать доп. параметр -low, -hight
:root {
--color-primary: #000;
--coloron-primary: #dddddd ; /* например для текста на фоне с цветом primary */
--coloron-primary-hight: #ffffff; /* сильноконтрастный цвет */
--coloron-primary-low: #777777; /* слабоконтрастный цвет */
}
В целом такое именование позволяет добиться предсказуемых результатов при создании темы.
Правда это тоже не является серебренной пулей, т.к. где-то могут не использоваться рекомендуемые переменные.
.Block {
background: var(--color-surface);
color: var(--color-error);
}
И не известно на сколько в новой теме surface и error будут контрастны друг к другу.
upd Пересмотрел ещё раз whitepapper https://github.com/whitepapertools/whitepaper-portal/tree/a6bb170522b470560e3572856cf11b1929e1469a/common.blocks/theme
Идёт разбитие цветовой темы на 2 вида. 1 базовые цвета страницы, 2 контролы (кнопки, чекбоксы, инпуты и т.д.).
Данный подход позволяет наиболее однозначно разрабатывать цвета для темы и тестировать их в "вакуме", что очень удобно. Тема не рассчитывается на все цвета радуги. Если нужно много вариаций, то стоит сделать несколько тем, что и плюс и минус.
Плюсы:
Минусы:
Любимый IE... Хоть поддержка по caniuse уже > 90% https://caniuse.com/#search=css-variables он ещё живёт...
Как один из подходов решения этого вопроса есть компромиссный вариант - делать версию с одной темой. Все переменные темы дублировать в :root и через postcss ставить статичные значения.
Этот сегмент получит сильно урезанный вариант оформления... Если это сильно критично то от локальных переменных придётся отказаться и делать стилизацию через каскады.
Либо использовать подходы с css-in-js... Но они не лишены недостатков.
Тут конечно есть конфликт интересов... Но имхо, у дизайнера должна быть система, по которой он работает и она должна быть логичной (например http://whitepaper.tools/)
П.Н. Небольшая демка "на коленке" Буду благодарен, если поделитесь своей системой стилизации блоков и именованием переменных.