В статье речь идёт не только о CSS-вёрстке, но также и о шаблонах и JavaScript компонентах. JavaScript может весить довольно много, если речь идёт о богатых приложениях.
Статические файлы не обязательно собирать для каждой конкретной страницы. Можно объединить всё в один файл, или выделить какие-то общие (common) куски + постраничные файлы. Такие операции возможны благодаря командам bem decl merge и bem decl subtract (bem tools).
В статье описана модель при которой каждая страница имеет свои CSS и JS файл, потому что такая модель прижилась у нас: мы проанлизировали поведение пользователей и скорость загрузки при различных вариантах, и этот оказался оптимальным. Дальше мы будем развиваться в следующем направлении: автоматический анализ статистики о том, какие страницы пользователи загружат вместе может влиять на сборку, внося логику в выделение этих «общих» кусков между страницами.
Вы правы, это требует определённой воли, даже если подход оправдывает себя.
Мы в свою очередь постоянно боремся над упрощением и отказом от рутинных операций. В частности, файлы руками никто не создаёт, для этого есть БЭМ инструменты, заботящиеся о правильном нэйминге и даже предоставляющие дефолтный контент.
Сборка осуществляется не прямым набором команд, а при помощи GNUmakefile, реализованного с учётом нужд проекта. Это сводит сборку к запуску одной команды.
Что не набирать даже эту команду, мы пользуемся утилитой Monkey Joe. Она отслеживает изменения файлов по нотификациям файловой системы и запускает всё, что нужно, в фоне.
В данный момент разрабатывается штука с рабочим названием bem server, для того, чтобы с проектами по архитектуре БЭМ можно было работать «из коробки».
Здесь опять же, не только IE6, но и контектсная зависимость.
Иногда всё-таки нужно использовать каскад и изменять элемент, если у блока (его родителя) есть определённый модификатор. В случае, когда модификатор не содержит имени блока, к которому относится, он может подействовать не только на элементы этого блока, но и на элементы вложенных блоков.
Из-за этого в том числе, но не только. «Полные» имена для CSS-классов нужны, чтобы уменьшить контекстную зависимость. Тогда блоки можно будет, не боясь, вставить в другие блоки.
А что касается >, то элементы могут быть не только непосредственными потомками. Их можно как угодно вкладывать друг в друга.
Статические файлы не обязательно собирать для каждой конкретной страницы. Можно объединить всё в один файл, или выделить какие-то общие (common) куски + постраничные файлы. Такие операции возможны благодаря командам bem decl merge и bem decl subtract (bem tools).
В статье описана модель при которой каждая страница имеет свои CSS и JS файл, потому что такая модель прижилась у нас: мы проанлизировали поведение пользователей и скорость загрузки при различных вариантах, и этот оказался оптимальным. Дальше мы будем развиваться в следующем направлении: автоматический анализ статистики о том, какие страницы пользователи загружат вместе может влиять на сборку, внося логику в выделение этих «общих» кусков между страницами.
Мы в свою очередь постоянно боремся над упрощением и отказом от рутинных операций. В частности, файлы руками никто не создаёт, для этого есть БЭМ инструменты, заботящиеся о правильном нэйминге и даже предоставляющие дефолтный контент.
Сборка осуществляется не прямым набором команд, а при помощи GNUmakefile, реализованного с учётом нужд проекта. Это сводит сборку к запуску одной команды.
Что не набирать даже эту команду, мы пользуемся утилитой Monkey Joe. Она отслеживает изменения файлов по нотификациям файловой системы и запускает всё, что нужно, в фоне.
В данный момент разрабатывается штука с рабочим названием bem server, для того, чтобы с проектами по архитектуре БЭМ можно было работать «из коробки».
Иногда всё-таки нужно использовать каскад и изменять элемент, если у блока (его родителя) есть определённый модификатор. В случае, когда модификатор не содержит имени блока, к которому относится, он может подействовать не только на элементы этого блока, но и на элементы вложенных блоков.
А что касается >, то элементы могут быть не только непосредственными потомками. Их можно как угодно вкладывать друг в друга.