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

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

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

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

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

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

Нам понравился supervisor. И для dev, и для production. Работает как master процесс, которые стартует и перестартует любые приложения, в т.ч. и такие, как node.js.

supervisord.org
OpenSource на гитхабе: https://github.com/Supervisor/supervisor
Есть всякие web морды: https://github.com/Jahaja/supervisor-webctl
Написан на питоне, но это ему не мешает ни сколько.

Что умеет из коробки:
Удобное API для работы (поэтому и есть возможность писать веб морды),
Позволяет перенаправлять стандартные потоки IO, запускает как надо и под нужным пользователем,
Сам перезапускает сервисы при падении,
Позволяет проверять запущенные сервисы и удаленно, и через ctl, и через всякие third-party приложения,
Позволяет собирать конфиг из кусочков, в т.ч. по wildcard, как апач/nginx, и тем самым дает возможность иметь отдельные конфиги для каждого приложения,
Документация,
Ну и проект живой, это очень важно https://github.com/Supervisor/supervisor/commits/master

Очень удобно использовать вместе с чем-то типа капистрано.

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

Пожалуй, посоветую следующее:
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 — неплохо знать как сам вордпресс, так и методологию, и инструменты, которыми будете все это собирать.