Comments 61
Пожалуй, самая популярная сейчас методология вмиреЯндексе. Название означает «Блок, элемент, модификатор».
Fixed.
«Невероятно популярен» — это не «про это пишут статейки с кучей лайков для профильной аудитории», а «на этом работает Твиттер и Фейсбук».

А вообще, БЭМ — очень общая система, позволяющая значительно упростить поддержку кода, поэтому используется сейчас в том или ином виде очень широко.
По поводу «Все хорошие верстальщики верстают так, без всяких соглашений, статей и прочего». В 2005 это было не так.
Сейчас каждый школьник знает, что Земля круглая, а когда-то это знание стоило жизни.
Однако автор статьи считает это плохой практикой (каждый раз, когда в стилях появляется id селектор, где-то в мире грустит котенок). Используйте классы и будет вам счастье.
Надо было раскрыть тему, хотя бы поверхностно
Описанные в статье способы организации css-кода там так-же рассматриваются.
Как я понял из нее, самая большая проблема использования id в css — селектор становится СЛИШКОМ специализированным и уже ничем не перебить установленные таким образом свойства.
Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?
Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?
Первый раз такое слышу. А как тогда заставить работать anchor в пределах страницы? А javascript? :)
На сколько я понимаю вопрос, «плохо» не просто использовать id, а использовать его не по назначению. Если в css-файле появился селектор с id, это не катастрофа, это сигнал о том, что глобальная модель css-правил не оптимальна.
Ваш совет равносилен предложению снять с автомобиля три колеса из четырех и на основании этого утверждать, что использование колес в автомобиле в принципе — крайне плохая практика.
Мой комментарий был ответом — и только ответом — на комментарий VitaliiDel, озвучившего предположение о том, что браузер обрабатывает стили для id только для первого найденного элемента с соответствующим id. Я предложил провести элементарный эксперимент для того, чтобы убедиться, что это не так, и браузер обработает все элементы с соответствующим id, сколько бы их не было, будь это хоть трижды нарушением каких бы то ни было спецификаций.
а за пример
.block {
&-element {...}
}
отдельное спасибо, не знал, что так можно =)
Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
Сам использую нечто похожее на SMACSS.
А вот за атомарный CCS ни раз хотелось уже убить.
Например,
b-article, b-article-title, b-article-content, b-article-controls и т.д. Каскадность видна невооружённым глазом, однако изменение html-разметки, в данном случае, никак не повлияет (конечно, при сохранении нужных имён классов).
Иногда атомарный css очень в тему. Допустим, есть классы иконок ico-accept, ico-decline… Чтобы добавить иконку в коде просто делаешь блок с этим классом. Но в каждом случае еще нужно задать размер иконки. Приходится добавлять еще класс, селектор в стили, и там прописывать размер. Либо сделать проще — один раз определить набор классов size-16, size-18, size-20… и тогда иконки можно полностью определять в html.
<div class="ico-accept size-16" ></div>
Очень упрощает жизнь.
И если завтра всем этим иконкам понадобиться еще и отступ слева, мы смело добавим в этот стиль margin и он не перестанет соответствовать названию.
Все дело в том, что в данном случае стиль несет адаптационное изменение, и только то, что случайным образом оно пока одно, делает его похожим на атомарный.
Если мне понадобится добавить специальные отступы для иконок панели, я естественно добавлю класс left-panel и пропишу его там. Классы size-16 и т.д. всегда строго содержат размер и ничего больше. В этом суть атомарности. Просто, чаще всего не нужно ничего, кроме иконки и размера.
Вот чем лучше:
Содержимое атрибута всегда соответствует своему содержимому, в то время как в классе size-16 может быть задано черт знает что.
Не надо возиться с двумя файлами.
Стиль применяется мгновенно.
А минусы есть?
Вот и назвать его надо ico-leftpanel
Вот только завтра приходит дизайнер и переносит вашу левую панель на право, а ваши иконки по прежнему содержат в себе leftPanel
Подразумевается, что заменят size-16 на size-20 в html. Если кто-то в классе size-16 напишет 20px, ему можно смело отрывать руки: )
Вопрос был задан с целью навести на мысль, что для size-16 замена класса как бы исподволь предполагается, а для ico-leftpanel замена класса по умолчанию запрещена. После чего мне задается пишется нечто вроде «Твой класс плохой потому, что я сказал, что не буду его менять и поэтому не буду его менять. Видишь — я не могу его заменить.»
Вроде бы и логично рассказывает, и какая-то нить прослеживается, но как доходит до практики — ступор. Что делать, как верстать, почему мне это должно быть удобно?
Неинтуитивная система.
БЭМ как-то сразу понятен — ну, во всяком случае основы. И сразу примерно понятно куда двигаться и что делать.
Конечно, со временем всплывают нюансы и тонкие моменты, но это уже дело техники.
Способы организации CSS-кода