Как стать автором
Обновить

Комментарии 61

Зачем? Беминфо поддерживает большое количество яндексоидов, а гетбем — всего два, причем последнее крупное обновление было больше 3-х месяцев назад.
Спасибо за уточнение, не о знал об этом. Просто getbem мне кажется более лаконичным и удобным.
НЛО прилетело и опубликовало эту надпись здесь
Владимир, на сайте можно повтыкать про элементы-модфикаторы и кажется что на этом весь БЭМ и заканчивается.
Ссылок «куда пойти, что почитить» или нет, или их сложно найти.
Беминфо, как я и говорил, поддерживают Яндексоиды и там есть что почитать после 15-ти минутного курса. А это очень клёви :)
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, что собрали в одном месте.
Спасибо, очень полезная информация. Особенно для тех, кто только начинает программировать с помощью css.
Думаю, что слово «программировать» немного неуместно.
Виноват, согласен.
Да нет, вполне логичный этап после освоения программирования на HTML.
НЛО прилетело и опубликовало эту надпись здесь
SASS, LESS пробовал. Они скорее в некоторой мере упрощают написание кода и помогают легче взаимодействовать с тем же PHP либо другими средствами. Да в них есть циклы, уловия, переменные, функции. При правильном подходе заменяют некоторую часть JS. Но не думаю что это прям программирование. Хотя есть много чего схожего.
НЛО прилетело и опубликовало эту надпись здесь
Пожалуй, самая популярная сейчас методология в мире Яндексе. Название означает «Блок, элемент, модификатор».

Fixed.
Вы подозреваете автора в предвзятости? Он, в общем-то, прав, BEM действительно невероятно популярен в мире.
Хорошо, я согласен пересмотреть свою точку зрения. Только давайте разберёмся, какие топовые мировые ресурсы сделаны по этой методологии?

«Невероятно популярен» — это не «про это пишут статейки с кучей лайков для профильной аудитории», а «на этом работает Твиттер и Фейсбук».
Вот вам пример из разметки твиттера =)

Картинка
image

А вообще, БЭМ — очень общая система, позволяющая значительно упростить поддержку кода, поэтому используется сейчас в том или ином виде очень широко.
Все хорошие верстальщики верстают так, без всяких соглашений, статей и прочего. Еще до появления БЕМ в яндексе. Собственно, как он по вашему появился то? Яндексу спасибо, за популязацию метода среди тех верстальщиков которые так не делали. С таким же успехом это мог быть и Гугол, и Твиттер и кто угодно, кто звучит авторитетно.
>> Собственно, как он по вашему появился то?
Насколько я знаю (возможно, ошибаюсь), методология «вёрстки независимыми блоками» была сформулирована именно в Яндексе (Виталием vithar Харисовым). А уже на её основе построили БЭМ.
История создания БЭМ: ru.bem.info/method/history

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

Сейчас каждый школьник знает, что Земля круглая, а когда-то это знание стоило жизни.
Однако автор статьи считает это плохой практикой (каждый раз, когда в стилях появляется id селектор, где-то в мире грустит котенок). Используйте классы и будет вам счастье.

Надо было раскрыть тему, хотя бы поверхностно
По поводу написания css в целом и использование id в css в честности есть очень хорошее руководство: http://cssguidelin.es/
Описанные в статье способы организации css-кода там так-же рассматриваются.
Спасибо за ссылку, но я её конкретизирую — cssguidelin.es/#ids-in-css.

Как я понял из нее, самая большая проблема использования id в css — селектор становится СЛИШКОМ специализированным и уже ничем не перебить установленные таким образом свойства.

Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?
Так же я слышал, что и в html использовать id тоже плохо. Правда, ни разу не получал ответа почему. Раз уж пошла такая пьянка, не просвятите?

Первый раз такое слышу. А как тогда заставить работать anchor в пределах страницы? А javascript? :)

На сколько я понимаю вопрос, «плохо» не просто использовать id, а использовать его не по назначению. Если в css-файле появился селектор с id, это не катастрофа, это сигнал о том, что глобальная модель css-правил не оптимальна.
НЛО прилетело и опубликовало эту надпись здесь
На сколько мне известно, использование id или class влияет на поиск элемента в DOM и соответственно на производительность. Так как предполагается, что id уникален в пределах документа, то при поиске по id, браузер останавливает поиск как только находит нужный элемент, а при поиск по классу он производит поиск пока не проверит все элементы в DOM, даже если нужный элемент был единственный, и найден в самом начале. Поэтому использовать нужно и то и другое, в зависимости от ситуации.
Проведите простой эксперимент: сделайте на одной странице несколько элементов с одним id и примените к этому id какой-нибудь стиль. Результат не шокирует, но спойлерить не буду.
Проведите простой эксперимент: ознакомьтесь со спецификацией и не занимайтесь тем, что ей настолько сильно противоречит.

Ваш совет равносилен предложению снять с автомобиля три колеса из четырех и на основании этого утверждать, что использование колес в автомобиле в принципе — крайне плохая практика.
А вы, как я погляжу, любитель развести спор на пустом месте, да? Мой комментарий вообще никаким боком не относится к допустимости или недопустимости использования id в css. Вот вообще. Никак. Абсолютно. На 146%.
Мой комментарий был ответом — и только ответом — на комментарий VitaliiDel, озвучившего предположение о том, что браузер обрабатывает стили для id только для первого найденного элемента с соответствующим id. Я предложил провести элементарный эксперимент для того, чтобы убедиться, что это не так, и браузер обработает все элементы с соответствующим id, сколько бы их не было, будь это хоть трижды нарушением каких бы то ни было спецификаций.
Скорее всего имелся ввиду JavaScript, а не браузер.
Мне кажется, обзору крайне не хватает RSCSS.
Спасибо, ознакомлюсь.
С примерами кода было бы лучше.
Спасибо за статью, как раз стоит задача организации css кода.

а за пример
.block {
  &-element {...}
}

отдельное спасибо, не знал, что так можно =)
потом замучаешься в ide искать нужную css-ку, особенно если приходится поддерживать чужой код и его много
Для этого существую map-файлы
Ну вообще в БЕМ достаточно точно определена файловая структура, так, что зная css класс можно легко найти и файл где этот класс описан
это в идеальном мире достаточно точно определена файловая структура, а бывает что человек просто увидел возможность писать код так и пишет, а следующий за ним разработчик испытывает массу неудобств, когда не может обычным поиском в проекте найти нужный кусок кода
Если вы выбираете какою-либо методологию для разработки проекта, то все кто этот проект пилят, сначала знакомятся с ней, а уже потом начинают работать над проектом. В принципе в этом главный плюс любой методологии — единый стиль для всех.

Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
вы встречали такие проекты в своей практике, т.е. не проекты где вы в одиночку пилите интернет магазин, а проекты где над кодом поработало много разных людей, у которых разные методологии в голове были и вот вам такой проект достался в наследство? у одного 5 лет назад была методология ХРЕН, у второго БЭМ и вы получили ХРЕН-БЭМ, умаешься там искать нужные селекторы
НЛО прилетело и опубликовало эту надпись здесь
Постоянно ловлю себя на мысли, что сталкиваюсь с проблемами которые легко можно бы было решить используя БЭМ. Но от него отталкивает как раз то, что БЭМ фактически убивает каскадность.
Сам использую нечто похожее на SMACSS.
А вот за атомарный CCS ни раз хотелось уже убить.
Каскадность сильно мешается при изменении html-разметки. Считайте, что БЭМ привносит каскадность в понятиях «блок-элемент», без привязки к HTML.
Например,
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> 

Очень упрощает жизнь.

А я вот не согласен, что это атомарный стиль. Да он называется КАК атомарный. Да он содержит одно правило КАК атомарный. Но его смысл иной. Сделать иконку подходящей под левую панель. Вот и назвать его надо ico-leftpanel
И если завтра всем этим иконкам понадобиться еще и отступ слева, мы смело добавим в этот стиль margin и он не перестанет соответствовать названию.
Все дело в том, что в данном случае стиль несет адаптационное изменение, и только то, что случайным образом оно пока одно, делает его похожим на атомарный.

Если мне понадобится добавить специальные отступы для иконок панели, я естественно добавлю класс left-panel и пропишу его там. Классы size-16 и т.д. всегда строго содержат размер и ничего больше. В этом суть атомарности. Просто, чаще всего не нужно ничего, кроме иконки и размера.

В этом случае атрибут style всегда к вашим услугам. Чем хуже его использование чем использование атомарных классов?
Вот чем лучше:
Содержимое атрибута всегда соответствует своему содержимому, в то время как в классе size-16 может быть задано черт знает что.
Не надо возиться с двумя файлами.
Стиль применяется мгновенно.

А минусы есть?

Очевидный минус в том, что size-16 содержит набор свойств:


.dv-ico.size-16 {
    width: 16px;
    height: 16px;
    background-size: 16px 16px; 
}

Указывать каждый раз 3 свойства с дублирующимися значениями громоздко.

Не честная, жульническая атомарность.
Вот и назвать его надо ico-leftpanel


Вот только завтра приходит дизайнер и переносит вашу левую панель на право, а ваши иконки по прежнему содержат в себе leftPanel
А то что завтра придет дизайнер и изменит размер с 16 на 20, а у вас так и останется класс size-16 вас значит не волнует?

Подразумевается, что заменят size-16 на size-20 в html. Если кто-то в классе size-16 напишет 20px, ему можно смело отрывать руки: )

Точно так же заменим класс на правильный ;)
Вопрос был задан с целью навести на мысль, что для size-16 замена класса как бы исподволь предполагается, а для ico-leftpanel замена класса по умолчанию запрещена. После чего мне задается пишется нечто вроде «Твой класс плохой потому, что я сказал, что не буду его менять и поэтому не буду его менять. Видишь — я не могу его заменить.»
Похоже, БЭМ претендует на нечто большее, чем просто организация CSS. Со своими библиотеками это больше Transform View паттерн. Видимо, противоположное популярным сейчас фреймворкам вроде Angular, Backbone и др.
БЭМ — это скорее Web Components, только придуманные теми, кто реально пишет код и использует то, что придумывает ;)
Есть БЭМ-методология и bemtools – вариант реализации этой методологии. Никто не мешает использовать саму методологию с любым другим фреймворком (или вообще без них).
НЛО прилетело и опубликовало эту надпись здесь
Про MCSS и читал, и видео докладов на конференциях смотрел — но не понимаю.
Вроде бы и логично рассказывает, и какая-то нить прослеживается, но как доходит до практики — ступор. Что делать, как верстать, почему мне это должно быть удобно?
Неинтуитивная система.

БЭМ как-то сразу понятен — ну, во всяком случае основы. И сразу примерно понятно куда двигаться и что делать.
Конечно, со временем всплывают нюансы и тонкие моменты, но это уже дело техники.
Как автор MCSS, рекоммендую теперь уже использовать именно БЭМ. С тех пор он стал менее строгим, и более понятным.

MCSS может пригодится только на очень большом, монолитном проекте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории