Алексей Ярошевич

У вас здесь 2 проблемы:

• нужны ли классы для динамического контента;
  
• как, если нужно, модифицировать структуру динамического контента.

Проблема структуры не относится к BEM, она относится к семантике и SEO.

Если же не смотреть на структуру и тэги (использовать ли small внутри или span, заворчивать ли в article) — то вопрос в сущности нужны ли классы на динамическом контенте или нет. Учитывая, что контент динамический, и нет необходимости иметь классы на тэгах, то допустимо сделать каскад на тэги от некоторого блока: например, dynamic-content или content, text.

Почему именно теги? Потому что WYSIWYG по умолчанию генерирует теги. Но вы можете использовать какие-то доп. инструменты, которые подправят итоговый html, расставят классы и т.д. (например, с помощью инструментов типа https://github.com/posthtml/posthtml ).

При необходимости можно дополнительно пометить стили тегов классами.

<div class="text">
  <h1>Caption <small>Some Foo Bar</small></h1>
  <article>
    <p>Lorem ipsum...</p>
    <div class="text__p">Dolor sit...</div>
  </article>
</div>

.text h1, .text__title { /* main title styles */ }
.text h1>small, .text__sub-title { /* sub-title styles */ }
.text p, .text__p { /* paragraph styles */ }

Таким образом вы инкапсулируете все пользовательские стили в одном месте (одном блоке) и не имеете проблем с созданием контента.

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

Не очень тянет на вменяемый ответ, но уж коль ничего другого нет ;-)

Имхо, это все css3, js тут мало играет.

Делаете прямоугольный «слайдер», который загибаете, а его элементы наоборот разгибаете. При наличии какого-то класса сдвигаете, опять же, css3 свойствами и ставите нужную прозрачность (или меняете картинку), тени.

Вариант 2: svg. В этом случае, делаете inline svg, с нужной формой элементов, классы там тоже поддерживаются и при наличии класса active на элементе двигаете его вниз и меняете прозрачность.

Пожалуй, посоветую следующее:
1) Иметь хелперы в jade, переменную с названием блока типа b, гененрацию модификатора типа mod(b, 'name', 'val'), переменную content (у меня это объект с toString()) с содержимым блока, и т.п.
2) Не использовать include вообще, чтобы можно было строить дерево, просчитывать в рилтайме зависимости, и даже собирать assets для страницы. Например, через какието хелперы, опять же. При большом делении на блоки все повиснет, конечно, но надо научиться их умно кешировать.
3) На вход постарайтесь подавать bemjson-like структуру с доработками под себя. У нас в проекте сейчас это поле data, в которое кладутся любые данные, нужные для блока. Подтягивание внутренних блоков (и их последующую отрисовку) мы делаем либо в самих шаблонах, либо из объекта content, если контент состоит из массива блоков и строк.
4) Если нужно будет где-то подтянуть блок в элемент — научите хелперы block/element из (2) подмешивать данные при прямом вызове хелпера.
5) Если все замечательно — в конце все собранные assets можно в заголовке (css) и в подвале (js) страницы, предварительно прогнав через uglifyjs, csso, но только на продакшне, где есть их кеширование на nginx.

У нас это все на пхп со смарти (так звезды сложились), но вполне подойдет для рантайм js с jade. Работает замечательно.

Но вообще, если вы используете js, то удобнее использовать bemhtml свежий с js синтаксисом. На bem.info пока не обновляли доку, но базовые блоки в самой библиотеке вполне описывают синтаксис. Будет бонус — шаблоны самодостаточны, и на морде не потребуют подгрузки доп. библиотек, можно будет запускать как есть. В гульп их сборку встроить тоже можно.

Че-то второй вопрос по бэм и опять 3 подвопроса.

(1) Поступать с тегами нужно нежно. Лучше всего, если хотите бэм в вордпрессе, поискать готовые плагины/темы, на базе которых делать свое. В контенте без языков разметки бэму делать нечего, ибо это неудобно руками писать. В этом случае удобнее всего завернуть все в некий блок user-content, которому прописать стили для всех каскадов — таким образом у вас получится наибольшая польза от бэм с наименьшим кол-вом проблем от классического подхода. Т.е. вы все эти проблемы локализуете внутри блока user-content, все остальное будет стабильнее, в зависимости от навыков.

(2). Обертки это немножко другое, чем то, что вы хотите. Для центровки всех элементов можно родительскому блоку пользовательского контента user-content, в который вставляется то, что приходит из админки, выставить text-align: center, и оно разойдется по всем дочерним. А вообще, если такое нужно не везде, то лучше сделать соотв. модификатор или элемент, который можно будет навешивать на тэги контента. Имя блока можно сократить до uc, например: user-content_align_center или uc_align_center, или uc__centered (если использовать, как подмешанный элемент).

(3) Про вложенные блоки есть такая идея: создаете модификатор _level_N, или depth_K, где N, К — натуральные числа, этим модификаторам задаёте нужные цвета текста. Родительскому блоку по умолчанию выставляете тот самый одинаковый цвет. Профит.
Про дублирование стилей 7 раз — не очень понимаю, если у вас будет один и тот же блок — просто навешиваете его и нет проблем, если разные — цвета прописываете в модификаторах.
Кроме прочего, есть csso, который оптимизирует все это богатство и ужаса никакого не будет.
Кроме прочего, задача какая-то вымученная, потому что color по стандарту передается в дочерние элементы, и его будет достаточно прописать в style="color: red" родительской ноды.
Независимыми должны быть блоки, а не ноды. Разница между ними такая же, как между классом и объектом, или как между схемой и таблицей, или как между трафаретом и надписью им сделанной, и т.д. Одно — правила, второе — результат. Один и тот же блок может быть навешан на 50 хтмл нодах (тэгах), и все они будут иметь похожее или одинаковое поведение и отображение.
Например, есть у вас на сайте яндекс.карты, а в них 100 меток, все эти метки разные, но в чем-то сходятся, например, у них одинаковые или похожие стили, а при клике на любой из них выводится попап, в котором разные данные. Так вот метка и попап — это одни блоки, а данные в попапах будут в других блоках. И стили, скрипты про вид метки и про открытие попапа мы описываем в одном месте единожды, сам попап в другом месте и тоже единожды, а когда будем выводить эти данные — это уже будет контент и там уже мы будем выводить многократно один и тот же класс (название блока) в разные дом ноды (тэги).
В различных инструментах (bem-tools/enb) есть удобные шаблонизаторы как раз для автоматической генерации таких деревьев дом нод, чтобы было меньше путаницы: bemhtml, bh. Кроме того, такой подход позволяет генерировать шаблоны для сборки на клиенте в браузере. Но чтобы интегрировать все вместе — нужно разобраться. А чтобы еще и использовать с wordpress — неплохо знать как сам вордпресс, так и методологию, и инструменты, которыми будете все это собирать.

Странно, что никто не сказал про рендеринг.
Всякие CSS3 фишки весят меньше, но рисуются на клиенте. И каждая перерисовка будет заставлять браузер перерисовывать и эти ваши модные штуки. Таким образом, скорость работы сайта, перегруженного css3 может быть заметна глазу на слабых машинках — это уже не хорошо.
С другой стороны, как уже много говорили, перекрасить картинку — автоматически крайне сложно, иногда нереально, а перекрасить css3 — не сложнее, чем скушать печеньку.
Нужно искать золотую середину. Не использовать новомодные штуки там, где они не нужны, и стараться использовать там, где будет полезно, даже если для ie6/7/8/9 придется делать отдельные стили. Их все равно придется делать отдельно.