История изменений

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого неидеального какую-то пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

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

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

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности внутри сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

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

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь сущности button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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

P. S. В этой притче сущностью был блок, ролью элемент, а модификатором — модификатор.

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого неидеального какую-то пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

И приведен маааленький (пока) зародыш будущего хтонического ужоса на 10к строк, который никто до конца не понимает и поэтому не осмеливается трогать. Когда на проекте появляется джун, которого можно бросить ужосу на съедение, в остальной части команды некоторое время слышны вздохи облегчения и царит приподнятое настроение.

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности внутри сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

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

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь сущности button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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

P. S. В этой притче сущностью был блок, ролью элемент, а модификатором — модификатор.

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого неидеального какую-то пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

И приведен маааленький (пока) зародыш будущего хтонического ужоса на 10к строк, который никто до конца не понимает и поэтому не осмеливается трогать. Когда на проекте появляется джун, которого можно бросить ужосу на съедение, в остальной части команды некоторое время слышны вздохи облегчения и царит приподнятое настроение.

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности внутри сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

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

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь сущности button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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

P. S. В этой притче сущностью был блок, ролью элемент, а модификатором — модификатор.

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

И приведен маааленький (пока) зародыш будущего хтонического ужоса на 10к строк, который никто до конца не понимает и поэтому не осмеливается трогать. Когда на проекте появляется джун, которого можно бросить ужосу на съедение, в остальной части команды некоторое время слышны вздохи облегчения и царит приподнятое настроение.

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности внутри сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

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

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь сущности button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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

P. S. В этой притче сущностью был блок, ролью элемент, а модификатором — модификатор.

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

И приведен маааленький (пока) зародыш будущего хтонического ужоса на 10к строк, который никто до конца не понимает и поэтому не осмеливается трогать. Когда на проекте появляется джун, которого можно бросить ужосу на съедение, в остальной части команды некоторое время слышны вздохи облегчения и царит приподнятое настроение.

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности внутри сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

— если тебе не нужны в этом месте стили для роли (или сущности — если это безымянная роль для любой сущности), то и ее класс включать не нужно. Удобно.

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь сущности button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

И приведен маааленький (пока) зародыш будущего хтонического ужоса на 10к строк, который никто до конца не понимает и поэтому не осмеливается трогать. Когда на проекте появляется джун, которого можно бросить ужосу на съедение, в остальной части команды некоторое время слышны вздохи облегчения и царит приподнятое настроение.

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности внутри сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

— если тебе не нужны в этом месте стили для роли (или сущности — если это безымянная роль для любой сущности), то и ее класс включать не нужно. Удобно.

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь классы button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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

обоснованная критика

Нет ничего идеального, все можно покритиковать. Можно ли извлечь из этого пользу — вот что имеет значение. Из БЭМа пользу извлечь можно, и еще какую.

подробный разбор плюсов и минусов

Так-так, интересно.

Ниже предоставлен образец вёрстки без наследования в имени класса названия блока, модификаторы привязываются к главному классу через наследование в SCSS

И приведен маааленький (пока) зародыш будущего хтонического ужоса на 10к строк, который никто до конца не понимает и поэтому не осмеливается трогать. Когда на проекте появляется джун, которого можно бросить ужосу на съедение, в остальной части команды некоторое время слышны вздохи облегчения и царит приподнятое настроение.

А ~~причина одна~~ причины две — пространства имен сущностей и их ролей не разделены, ограничения на глубину вложенности в сущности нет, поэтому

любое изменение может потенциально внезапно повлиять на что угодно где угодно;
рост ужоса ничем не ограничен.

Модульность и простота — прощайте, геморрой и депрессия — здравствуйте.

классы длинные некрасиво фуфу

Ну окей. Дело вкуса. Правда, не обошлось без легкого мухлежа. Это

<h1 class="article__heading_level_1 article__heading_level_1_active"></h1>

может выглядеть так:

<h1 class="heading heading_active article__heading"></h1>

или

<h1 class="article__heading article__heading_active"></h1>

или вообще

<h1 class="heading heading_active"></h1>

— если тебе не нужны в этом месте стили для роли (или сущности — если это безымянная роль для любой сущности), то и ее класс включать не нужно. Удобно.

Все зависит от того, чему ты хочешь назначить модификатор - сущности или ее роли.

Длиннее? Да. Стоит ли оно того? Я думаю, что да. Все, что поможет не дать ужосу вырваться на волю, того стоит.

Дословная цитата из документации: В CSS по БЭМ также не рекомендуется использовать селекторы по тегам или id

И в той же документации написано, почему не рекомендуется (не запрещено) этого делать. Но чукчи ведь не читатели.

В каждом большом темплейте есть мелкие элементы, как кнопки, дропдауны, тайтлы, субтайтлы, секции и т.д. Но в БЭМе у вас их нету

Любой элемент может быть сущностью. Надо тебе сущность «заголовок со смайликами» — вот тебе класс «smiley-header». Ставь его хоть на h1, хоть на span.

В чем проблема иметь классы button, dropdown, title, subtitle, section? Дай-ка угадаю — в том, что они потом будут интерферировать с внутренностями ужоса, в котором сущности не отделены от ролей?

Так ведь для этого и нужен БЭМ (и другие модульные методологии) — чтобы ужоса у нас в стилях не было %)

Плюсы: их нет.

О — объективность %)

Ну раз афтар не смог, я ему помогу:

Модульность для стилей, причем в любом браузере.

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

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