Website development
CSS
Perfect code
HTML
Comments 61
+2
В ссылки раздела по БЭМ стоит добавить еще и http://getbem.com
0
Зачем? Беминфо поддерживает большое количество яндексоидов, а гетбем — всего два, причем последнее крупное обновление было больше 3-х месяцев назад.
0
Спасибо за уточнение, не о знал об этом. Просто getbem мне кажется более лаконичным и удобным.
UFO landed and left these words here
0
Владимир, на сайте можно повтыкать про элементы-модфикаторы и кажется что на этом весь БЭМ и заканчивается.
Ссылок «куда пойти, что почитить» или нет, или их сложно найти.
Беминфо, как я и говорил, поддерживают Яндексоиды и там есть что почитать после 15-ти минутного курса. А это очень клёви :)
UFO landed and left these words here
-4
Спасибо, очень полезная информация. Особенно для тех, кто только начинает программировать с помощью css.
0
Да нет, вполне логичный этап после освоения программирования на HTML.
UFO landed and left these words here
0
SASS, LESS пробовал. Они скорее в некоторой мере упрощают написание кода и помогают легче взаимодействовать с тем же PHP либо другими средствами. Да в них есть циклы, уловия, переменные, функции. При правильном подходе заменяют некоторую часть JS. Но не думаю что это прям программирование. Хотя есть много чего схожего.
UFO landed and left these words here
+1
Пожалуй, самая популярная сейчас методология в мире Яндексе. Название означает «Блок, элемент, модификатор».

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

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

Картинка
image

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

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

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

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

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

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

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

На сколько я понимаю вопрос, «плохо» не просто использовать id, а использовать его не по назначению. Если в css-файле появился селектор с id, это не катастрофа, это сигнал о том, что глобальная модель css-правил не оптимальна.
UFO landed and left these words here
+1
На сколько мне известно, использование id или class влияет на поиск элемента в DOM и соответственно на производительность. Так как предполагается, что id уникален в пределах документа, то при поиске по id, браузер останавливает поиск как только находит нужный элемент, а при поиск по классу он производит поиск пока не проверит все элементы в DOM, даже если нужный элемент был единственный, и найден в самом начале. Поэтому использовать нужно и то и другое, в зависимости от ситуации.
0
Проведите простой эксперимент: сделайте на одной странице несколько элементов с одним id и примените к этому id какой-нибудь стиль. Результат не шокирует, но спойлерить не буду.
0
Проведите простой эксперимент: ознакомьтесь со спецификацией и не занимайтесь тем, что ей настолько сильно противоречит.

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

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

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

Добавьте к этому код-ревью(чтобы избежать отклонений от методологии) и вы получите ваш «идеальный мир».
0
вы встречали такие проекты в своей практике, т.е. не проекты где вы в одиночку пилите интернет магазин, а проекты где над кодом поработало много разных людей, у которых разные методологии в голове были и вот вам такой проект достался в наследство? у одного 5 лет назад была методология ХРЕН, у второго БЭМ и вы получили ХРЕН-БЭМ, умаешься там искать нужные селекторы
UFO landed and left these words here
0
Постоянно ловлю себя на мысли, что сталкиваюсь с проблемами которые легко можно бы было решить используя БЭМ. Но от него отталкивает как раз то, что БЭМ фактически убивает каскадность.
Сам использую нечто похожее на SMACSS.
А вот за атомарный CCS ни раз хотелось уже убить.
0
Каскадность сильно мешается при изменении html-разметки. Считайте, что БЭМ привносит каскадность в понятиях «блок-элемент», без привязки к HTML.
Например,
b-article, b-article-title, b-article-content, b-article-controls и т.д. Каскадность видна невооружённым глазом, однако изменение html-разметки, в данном случае, никак не повлияет (конечно, при сохранении нужных имён классов).
0

Иногда атомарный css очень в тему. Допустим, есть классы иконок ico-accept, ico-decline… Чтобы добавить иконку в коде просто делаешь блок с этим классом. Но в каждом случае еще нужно задать размер иконки. Приходится добавлять еще класс, селектор в стили, и там прописывать размер. Либо сделать проще — один раз определить набор классов size-16, size-18, size-20… и тогда иконки можно полностью определять в html.


<div class="ico-accept size-16" ></div> 

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

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

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

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

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

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


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

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

0
Вот и назвать его надо ico-leftpanel


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

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

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

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

MCSS может пригодится только на очень большом, монолитном проекте.
Only those users with full accounts are able to leave comments., please.