Статьи

BEM и SMACSS: советы разработчиков, которые были там

Методологии CSS могут быть невероятно запутанными и сложными для принятия решения. Давайте рассмотрим два наиболее известных варианта: BEM и SMACSS .

Вы должны выбрать один из них для вашего следующего проекта? Для чего они лучше всего подходят? Что может пойти не так? Если вы уже работаете с одним из них — используете ли вы его по назначению? В полной мере потенциал? Как узнать, правильно ли вы это делаете? Я подумал, что было бы неплохо спросить людей, которые уже задавали эти вопросы в своих собственных проектах, и учиться на их опыте.

Я попросил разработчиков, которые работали с BEM и / или SMACSS, рассказать об их успехах, ужасах, советах и ​​предостережениях. Я дал некоторым разработчикам целый список вопросов, а другие просто сошлись в своих мыслях. Я собрал результаты в то, что, я надеюсь, будет полезным для тех, кто рассматривает возможность оптимизации своего CSS.

Смотреть стать CSS-героем вашего офиса с CSS-архитектурой
Craft структурированный, поддерживаемый и масштабируемый CSS

Для новичков в BEM и SMACSS я начну с краткого обзора того, что такое BEM и SMACSS.

Что такое БЭМ?

БЭМ расшифровывается как Блочный Элемент Модификатор и возникла на Яндексе. Это обеспечивает довольно строгий способ организации ваших CSS-классов в независимые модули. Есть несколько вариантов этой идеи, но самая распространенная выглядит так:

.block {} .block__element {} .block--modifier {} .block__element--modifier {} 

Блок представляет объект на вашем сайте. Например:

  • персона
  • форма входа
  • меню
  • форма поиска

Элемент — это компонент внутри блока, который выполняет определенную функцию. Это должно иметь смысл только в контексте его блока. Например:

  • рука
  • кнопка входа
  • пункт меню
  • поле ввода поиска

Модификатор — это то, как мы представляем варианты блока. Например:

  • высокий / низкий человек
  • сжатая форма входа (например, мы скрываем ярлыки в одной версии)
  • меню, измененное для нижнего колонтитула или карты сайта
  • поле ввода поиска с определенным стилем кнопки

В примере нашего меню имена классов могут выглядеть так:

 .menu {} .menu__item {} .menu__item--featured {} .menu--footer {} 

На веб-сайте bem.info есть и другие архитектурные принципы и инструменты для BEM, однако, когда разработчики обсуждают BEM, они часто сосредоточены в основном на соглашении об именах, приведенном выше, и это верно в отношении большей части обсуждения ниже.

Что такое SMACSS?

SMACSS — это фреймворк CSS от Jonathan Snook . На веб-сайте SMACSS он говорит, что это больше похоже на «руководство по стилю», чем на жесткую структуру CSS. Это сосредотачивается на пяти категориях для его правил:

База используется для значений по умолчанию, таких как html , body , a , a:hover . Это включает в себя ваш сброс CSS и часто будет в своем собственном базовом файле CSS или в начале вашего основного CSS.

Макет делит страницу на разделы с такими элементами, как заголовок, нижний колонтитул и статья. Часто разработчики показывают элементы макета, добавляя к классу префикс l- .

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

Состояние используется для возможных вариантов для каждого элемента (например, активный, неактивный, расширенный, скрытый). К ним добавляется префикс is- , например, is-active , is-active , is-inactive is-expanded , is-hidden или псевдоклассы, такие как :hover и :focus или медиа-запросы.

Тема похожа на состояние, но определяет, как будут выглядеть модули и макеты. Это больше подходит для больших сайтов с общими элементами, которые выглядят по-разному. Вы бы добавили варианты темы для каждой страницы или раздела.

Дочерние элементы в SMACSS (например, что такое «элемент» для «блока» в БЭМ) имеют родительский элемент с префиксом тире. например, menu и menu-item .

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

Руководство от тех, кто использовал БЭМ

Это применимо ко всем проектам, большим и маленьким

Хэмиш Таплин (Hamish Taplin), разработчик внешнего интерфейса из Кардиффа, Великобритания, считает, что BEM подходит для больших и малых проектов и предлагает множество преимуществ:

«БЭМ рекламируется как для крупных проектов, но я не верю этому вообще. Если вам нравится писать код, который является чистым, поддерживаемым и не борется с проблемами специфичности, то BEM для вас. Некоторые говорят, что HTML-код, который он создает, уродлив или избыточен, но я думаю, что это красиво. Я могу прочитать некоторый HTML и точно увидеть, что происходит и как элементы связаны друг с другом. Здорово.»

Избегает вложения

Alec Raeside, разработчик внешнего интерфейса из Сиднея, Австралия, нашел, что BEM — хороший способ избежать слишком большого количества вложенных селекторов:

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

Это поможет вам заново открыть для себя силу классов

Хэмиш Таплин воспел хвалу БЭМ и объектно-ориентированным принципам. Он поднимает интересные мысли о понятии «семантическая» разметка:

«Преимущества БЭМ были очевидны сразу. До принятия принципов BEM и OOCSS я был сторонником того, что (неправильно) известно как «семантическая» разметка. Я думаю, что многие разработчики (включая меня) в значительной степени неправильно поняли, что это на самом деле означает, и пренебрегали силой классов под маской того, что они недостаточно «семантические». Поисковые системы и программы чтения с экрана не заботятся о классах, которые вы используете, или о некоторых дополнительных элементах div, используемых для сетки. Инженер Twitter Николас Галлахер (Nicholas Gallagher) полностью прибег к этому в своем блоге «О семантике HTML и архитектуре интерфейса», когда он говорит: «… не всякая семантика должна быть производной от контента. Имена классов не могут быть «не семантическими». Какие бы имена ни использовались: они имеют значение, у них есть цель. Семантика имени класса может отличаться от семантики HTML ».

Облегчает работу на крупных сайтах

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

«Я баловался несколькими небольшими проектами и занялся им — сначала это было довольно сложно, поскольку это противоречило тому, как я работал в течение многих лет, но преимущества становились очевидными. Затем мы начали проект, который был довольно большим и очень модульным — My Health Skills. Это был первый проект Bluegg, над которым я работал, где я работал с другим разработчиком (Полом Гудфилдом, который также использовал BEM) — я сделал фронтенд, а Пол — бэкэнд. Преимущества были сразу очевидны, Пол мог точно понять, что делает моя разметка, и написать вокруг нее свои шаблоны Laravel. Если ему нужно было заполнить некоторые пробелы, то предсказуемая природа БЭМ означала, что он мог писать HTML так же, как и я, и весь процесс стал намного более плавным. Я написал об этом в своем блоге «Укрепление здоровья» .

Алек Раесайд также нашел преимущества для крупных проектов благодаря модульной природе именования БЭМ. Он говорит:

«БЭМ хорошо подходит для крупных проектов. CSS сложен, и большие проекты могут рухнуть, где неопределенные селекторы могут вызвать непредвиденные последствия в других местах. Например, нацеливание на все <ul> с помощью селектора, такого как .container ul {} может сработать, когда этот код был написан, но после того, как многие другие компоненты будут вложены в компонент .container , стиль ul может оказаться неподходящим. Благодаря инкапсуляции и специфичности, лежащим в основе методологии BEM, она может помочь предотвратить случайное стилирование некоторых страниц при столкновении имен между компонентами и неспецифическими селекторами.

Методология BEM инкапсулирует ваш код для повторного использования

Гарри Робертс, консультант Front-end Architect, дизайнер и разработчик из Великобритании, который внес огромный вклад в идеи в области BEM и разработке чистого CSS, отметил, что методология BEM облегчает повторное использование компонентов через веб-сайты через его инкапсуляция:

«Методология BEM идеально подходит для проектов, в которых ваши компоненты, возможно, придется переместить из одной кодовой базы в другую; они должны быть полностью инкапсулированы, чтобы вы могли просто переместить один кусок HTML, CSS, JS в другой проект, и вам не нужно брать с собой никаких зависимостей. Представим, что вы работаете в компании, которая имеет пять разных сайтов, и им всем нужна одна и та же карусель на главной странице. Вы написали бы эту карусель в методологии БЭМ, чтобы вы могли собрать ее одним куском и переместить ».

Хорошо работает с фреймворками с компонентным фокусом

Джош Хант, фронтенд-разработчик из Сиднея, обнаружил, что он прекрасно работает с другими фреймворками с похожим компонентным фокусом:

«БЭМ действительно хорошо работает на сайтах, которые имеют множество автономных виджетов или компонентов, таких как веб-приложения. Фреймворки, которые продвигают HTML-компоненты (Angular, React, Polymer / Web Components), также значительно упрощают применение методологий BEM ».

Быстрый способ доставки прототипов

Боб Дондервинкель, разработчик внешнего интерфейса из Роттердама, Нидерланды, сделал отличную презентацию «Преимущества BEM CSS» . Он отмечает самое большое преимущество, которое он нашел, работая с BEM:

«Я уже полгода пользуюсь BEM и использую его в двух проектах: на новой странице прокрутки галереи для www.viewbook.com и переделываю старый Flash-сайт в HTML-версию. Проекты для этих проектов были четко определены, и я бы сказал, что наибольшая победа с использованием БЭМ — быстрая доставка прототипа. И это в основном потому, что «расшифровка» вашего дизайна в блоках, элементах и ​​модификаторах дает вам хороший старт для написания кода CSS ».

Заставляет вас думать дважды

Джош Хант считает, что соглашение об именах помогает вам дважды подумать, прежде чем делать вещи слишком сложными:

«Я нашел из-за того, что это немного уродливо, это заставляет вас дважды подумать, когда вы собираетесь писать действительно длинные имена классов».

Убедитесь, что вы планируете!

Хэмиш Таплин также дал несколько советов тем, кто начинает новый проект:

«Имейте степень планирования, когда вы начинаете проект. Я склонен просматривать макеты и искать шаблоны, которые можно абстрагировать в модули БЭМ. Поначалу это может быть сложно, но вы становитесь лучше до того момента, когда начинаете повторно использовать старые шаблоны. Повторное использование кода — это нирвана разработки, и ваш начальник поблагодарит вас за снижение производственных затрат, потому что вы более эффективны! »

Не будь слишком строг с этим

Джош предупреждает о том, что вы слишком ограничены в своих проектах, когда намереваетесь использовать БЭМ:

«Не чувствуйте себя ограниченным БЭМ или чувствуйте, что вы вынуждены следовать какой-то странной схеме. Я привлечен к этим двум твитам Гарри Робертсом :

Джош объясняет: «БЭМ не должен быть целью проекта, это должно быть то, что вы должны учитывать при разработке и применять там, где это полезно. Не увлекайтесь, пытаясь придерживаться какого-то теоретического «стандарта». Вспомогательные классы (такие как .pull-right или .text-center ) совершенно классные, чтобы сосуществовать с BEM. Там, где у вас могли бы быть class="story--centered" , class="story text-center" будет работать так же хорошо (возможно, даже лучше).

Если вы колебались, просто прыгните и попробуйте

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

«Я видел, как БЭМ упоминал несколько раз, и думал, что это выглядит интересно, но все еще продолжал, как я, пытаясь минимизировать количество разметки и классов, которые я писал, используя Sass @extend чтобы обойти проблемы, которые это вызывает. Однажды я посмотрел видео Гарри Робертса «Breaking Good Habits» и был поражен. Этот парень был на высоте — какие проблемы мы на самом деле решали, делая это?

Хэмиш продолжает: «В то время я перешел на другую работу, начиная с моей нынешней работы в Блюгге, и увидел, что это чистый прорыв для испытания БЭМ».

Я спросил Гарри, того самого разработчика, который сразил Хэмиша своим выступлением на тему «Breaking Good Habits» и который вдохновил Джоша своими твитами, если у него есть какие-то конкретные истории успеха, которыми можно поделиться. Его слова перекликаются с менталитетом «давай-давай»:

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

«Пожалуй, ближе всего к истории успеха я могу представить BEM-именование для моего клиента. Он долго и долго избегал называть БЭМ, ссылаясь на часто используемое «Но это так ужасно!». Я убедил его хотя бы попробовать его на полдня и посмотреть, что он думает. тогда. Он любил это. Всего через несколько часов он поставил здесь подчеркивание, а здесь — двойной дефис. Всегда приятно видеть, что у людей есть этот момент лампочки ».

Гарри также поставил следующий вопрос для тех, кто не уверен:

«Если вы не уверены в БЭМ, ответьте на вопрос: что не нравится в строгом, прозрачном и содержательном способе именования вещей? Честно говоря, нет никаких недостатков в использовании имен БЭМ ».

Я оставлю последние слова по этому поводу Хэмишу Таплину, который сказал:

«Просто попробуйте. БЭМ решает проблемы, поэтому посмотрите, поможет ли это вам. Я видел, что это отклонено на многих форумах или обсуждениях людьми, которые никогда не пробовали это и хотят сохранить их разметку «семантической». Я был таким же, пока не сделал решительный шаг, и это полностью изменило мой взгляд на то, как я должен писать HTML и CSS. Вы должны быть готовы адаптироваться и признать, что ошибаетесь, если хотите создавать отличные продукты ».

Руководство от тех, кто использовал SMACSS

Легкость демонстрации и передачи

Крис Райт, разработчик из Сиднея, большой поклонник SMACSS и предложил свой совет. Главная похвала Криса за SMACSS — простота использования его функций категоризации:

«Как только я начал использовать причину, почему SMACSS был настолько мощным, функции категоризации, я обнаружил, что это действительно удобочитаемая и обучаемая методология по сравнению с другими популярными методологиями CSS».

«Я использовал его в качестве подрядчика, потому что это намного проще продемонстрировать людям — вот моя таблица стилей: классы с l- перед ним относятся к макету, вещи с m- перед ним являются модулями и так далее. , Хотя мне все еще нужно передать и объяснить, сумма, которую я должен объяснить и документировать, была уменьшена, так что это сэкономило мне больше времени вне работы. С прошлого года я начал использовать его в каждом проекте ».

Хорошо для новичков в методологии CSS

Крис, в частности, обнаружил, что ему было трудно заставить других работать с ранними версиями BEM и OOCSS, но SMACSS было проще объяснить:

«Я обнаружил, что гораздо проще объяснить разработчику, который никогда раньше не сталкивался с методологией CSS, — какова ценность этой методологии и как ее использовать.

«Я некоторое время пытался с БЭМ, но всегда находил, что люди могут запутаться. С OOCSS я обнаружил, что соглашения об именах людей часто бывают повсеместно, но они обычно получают это. SMACSS предлагает категоризацию, которая поможет вам сразу увидеть, какова цель занятия ».

Легкость чтения

Крис также сказал, что он обнаружил, что ранние версии BEM немного многословны, но он видел, как он развивается со временем, он предпочитает SMACSS здесь.

«Кроме того, с точки зрения чтения, все эти подчеркивания, тире и сумасшедшие длинные классы в BEM, как правило, отвлекали меня от этого — я видел несколько более адаптированных версий, таких как то, что сделал Гарри Робертс, как довольно значительное улучшение методологии , но я все еще не чувствую, что это для меня.

Масштабируется для всех проектов

Крис также отмечает, что SMACSS не нужно полностью соблюдать на больших сайтах по сравнению с более мелкими, что обеспечивает гибкость и применимость во всех проектах:

«Я думаю, можно с уверенностью сказать, что различные формы SMACSS могут подходить для всех проектов. Как говорит Снук в своей книге — в меньшем проекте вы, вероятно, не будете использовать такие вещи, как тема, как категорию ( t- ), но возможность отличить класс макета от класса модуля от взгляда довольно ценна ».

Вы можете использовать SMACSS и BEM

Хэмиш Таплин на самом деле использует гибридный подход, используя некоторые концепции SMACSS в своем BEM. Я обнаружил, что многие разработчики нашли приятное место между этими двумя, так что это не может быть вопросом выбора одного:

«Я использую некоторые концепции SMACSS и не считаю их взаимоисключающими. Я организую свой Sass в «базовый», «макет» и «модули», которые в общих чертах являются соглашениями SMACSS. Я также большой поклонник использования основанных на состоянии классов в моем JavaScript. Например, модуль, который может быть видимым или скрытым, может иметь is-visible или is-hidden классы, управляемые JavaScript. Я считаю, что это помогает отличить то, что контролируется JavaScript, а не с помощью модификаторов в стиле БЭМ. Я не был бы против этого все же. ”

Боб Дондервинкель согласился, что сочетание BEM и SMACSS возможно в большинстве ситуаций:

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

Гарри Робертс рекомендует выбирать лучшие биты повсюду и использует свою собственную методологию, которую он называет «ITCSS», с комбинацией BEM, SMACSS и OOCSS.

«Я на самом деле использую свою собственную — пока неопубликованную — методологию ITCSS наряду с небольшим количеством OOCSS, BEM и SMACSS. Чрезвычайно важно выбирать биты отовсюду, а не слепо следовать одной методологии до самого конца. Я всегда использую именование БЭМ и использую методологию БЭМ в проектах, где мне нужны полностью инкапсулированные компоненты, которые должны совместно использоваться несколькими кодовыми базами. Я написал бы эти компоненты, используя OOCSS, и затем я бы обернул эти компоненты в архитектуру ITCSS.

«Это не начинается и не заканчивается с БЭМ и SMACSS. ITCSS предназначен для охвата целых проектов; OOCSS — это отличная маленькая методология, которая совместима со всеми; Принципы SOLID могут быть использованы для написания CSS лучшего качества ».

Если вы хотите узнать больше об ITCSS, у Гарри есть видео, которое вы можете посмотреть . Для получения дополнительной информации о принципах SOLID CSS Гарри также предложил эти две статьи:

Если вы этого не сделали, прочитайте руководство по SMACSS

Гарри Робертс настоятельно рекомендует прочитать руководство по SMACSS :

«Просто прочитай об этом. SMACSS — это один из лучших фрагментов фронтального чтения, появившийся за последние несколько лет, и очень трудно не согласиться с логикой, которую он выдвигает ».

Ужасы на БЭМ и SMACSS

Я пытался получить некоторые ужасные истории и предупреждающие слова от наших разработчиков — уроки, которые мы могли извлечь из их ошибок, когда они находились в процессе обучения. Вот их мысли.

Алек Раисайд на БЭМ

«Это довольно сложная кривая обучения, концептуально не слишком сложная для понимания, но требуется время, чтобы изменить привычки написания нормальных CSS / Sass. Это очень легко НЕ думать только на основе компонентов. Я пишу БЭМ весь год и все еще чувствую, что я учусь и совершенствуюсь, как пишу. Иногда вам нужно написать немного больше CSS с BEM по сравнению с не-BEM CSS, чтобы достичь чего-то, что раздражает, но лучше иметь последовательность.

«Сам по себе BEM недостаточно для создания пользовательского интерфейса наилучшим образом, мы объединяем BEM, CSS для мобильных устройств, надлежащее использование Sass и строгие стандарты кодирования. У нас нет идеального, но становится лучше. Мы также недавно начали использовать scss-lint для обеспечения соблюдения наших стандартов кодирования и, в меньшей степени, нашего использования БЭМ ».

Крис Райт на SMACSS

«Большинство моих страшных историй — это не страшилки, а места боли. Я сталкивался с агентствами, которые действительно сильно нагружены фреймворком Bootstrap, которые хотят продолжать использовать больше подходов OOCSS, что хорошо (OOCSS тоже довольно хорош) — но пытаюсь убедить кого-то, кто использует подход, который идет с их конкретной структурой, немного адаптировать их методологию к своим проектам, которые не используют структуру, — довольно бесполезный аргумент. Поэтому мне пришлось оставить это в тех случаях. Самая большая слабость SMACSS, я бы сказал, это то, что она менее широко принята, чем BEM или OOCSS — кажется, что об этом слышали меньше людей.

«Мои личные истории с его реализацией не совсем соответствовали методологии. Очень легко попасть в ловушку «модулировать все вещи» и забыть, что предложенные категории были именно этим предложением. Самое сложное — это понимание того, что относится к каждой категории. Является ли глобально используемая основная кнопка модулем с именем .m-btn-primary ? Или дело в модуле? Это может сбивать с толку, когда вы впервые начинаете использовать методологии, и в случае SMACSS, где вы четко определяете такие вещи, как макет, модули и темы; Я столкнулся с несколькими ситуациями, когда мне приходилось останавливаться и думать, где что-то принадлежит, но это также было для меня позитивом, и дело в том, что мы хотим больше организованных классов, которые люди могли бы легко читать и понимать ».

Джош Хант на БЭМ

«Первое использование БЭМ чаще всего будет кошмаром. Мой первый раз я создавал .classes__about__five__levels__deep . БЭМ не должен быть взаимно однозначным отображением структуры DOM на имена классов.

«Мне было трудно применять BEM, когда вам нужны дополнительные элементы исключительно для стиля, такие как .wrapper или .inner . Не совсем правильно иметь .article__inner (внутренняя не является элементом статьи). Иногда вы можете проявить креативность с div.article__media img.article__img словами ( div.article__media img.article__img ), но в других случаях совершенно нормально «сломать» БЭМ и перейти .article-wrapper или .article-inner .

Хэмиш Таплин на БЭМ

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

«Еще одним камнем преткновения является то, что он требует полного контроля над разметкой, что может быть сложно, если вы работаете в среде (например, .NET), где это не всегда возможно».

Гарри Робертс на БЭМ

«Поскольку BEM naming — это просто GoodIdea ™, очень редко можно услышать ужасные истории. Самое близкое, о чем я могу подумать, имело место с моим действительно большим клиентом в начале года. Это была действительно прилежная команда, которая провела много исследований и изучила лучшую архитектуру CSS, и они привели меня на неделю обучения, чтобы попытаться сгладить любые грубые моменты. Одним из самых сложных моментов было внедрение BEM-имен. К сожалению, они прочитали статью (в интересах сохранения которой я не буду ссылаться здесь), в которой содержался очень плохой совет относительно именования БЭМ. Принципиально некорректная информация, которая была просто неверна. Клиент последовал этому совету к письму, и у него возникли реальные проблемы. Вещи были более запутанными и взаимосвязанными, чем когда-либо прежде — что-то, что BEM именование должно решить! Это, однако, единственный инцидент, о котором я знаю ».

Боб Дондервинкель на БЭМ

«Ну, я бы точно не назвал это ужасной историей;) Но я сделал небольшой инструмент для подмостей BEM под названием kaBEM . Ошибка, которую я сделал, заключалась в использовании имен классов BEM CSS с несколькими элементами (например, block__element__element ). Главным образом потому, что это помогло в создании хорошо вложенной структуры папок на основе этих имен классов CSS. По сути, я записывал структуру HTML в именах классов CSS, но это на самом деле делает BEM немного более жестким, что не нужно.

«Еще одна небольшая ошибка заключалась в том, что вложение BEM CSS-селекторов, как вы можете сделать с Sass или LESS, фактически добавляет специфичность CSS там, где это не нужно. BEM лучше всего работает как отдельные имена классов, так что, возможно, об этом стоит помнить ».

Вывод

Изучив ответы и идеи каждого, стало ясно, что лучшим подходом представляется гибрид. Читайте обо всем, откройте для себя и BEM, и SMACSS, и посмотрите, улучшится ли ваш CSS и рабочий процесс. Вам не нужно выбирать одну методологию; объедините концепции нескольких методологий в одну, которая работает для вас и вашей команды. Если вам нужна помощь, есть много разработчиков, готовых поделиться некоторыми мыслями и советами.

кредиты

Большое спасибо следующим разработчикам, которые были достаточно любезны, чтобы уделить время, чтобы ответить на мои вопросы и поделиться своими мыслями и опытом: