Почему лучше верстать в соответствии с БЭМ — практические примеры

Вы сами в статье заметили, что от головняков это не спасает, а наоборот — создаёт новые на совершенно пустом месте (пример со ссылками).
Кроме того, существует мнение, что семантика — это не только название тега, но и совокупность его атрибутов, в том числе class и id, от которого вообще предлагают отказаться.

БЭМ — это не просто способ записывать названия стиля.

Стоит уточнить, пока камни не полетели, это не всетаки не в чистом виде БЭМ с БЭМ нотацией, но _очень_ близко к этому.

Причины использования БЭМа Яндексом или Гуглом, в разработке собственных сервисов, предельно понятны и обоснованы.
Автор статьи же, как и верстальщики Яндекса, рекомендует применять БЭМ везде.

<table style="list-style-type: circle; border: solid 1px #ffffff"> <tr> <td style="display: table-cell;">Привет</td> <td style="display: table-cell;">Пока</td> </tr> </table>
Назад в будущее?

Не стоит пугаться, прописывается все это не руками, а специальной программой, генерирующей код исходя из заложенной логики.

Эта возможность есть, и не теоретическая, а практическая. Google Closure + Soy Templates умеют это по дефолту.
То что яндекс чудачит таким образом оставляя имена в чистом виде, либо недоработка, либо продукт все еще находится в стадии отладки.

Возможность есть. Но измерения показали, что после гзипования разницы между двумя документами с длинными классами и короткими нет. Поэтому мы отказались от идеи такой конвертации.

Что значит «сломался»? Вы меняете часть работающей системы, и ожидаете, что все будет работать также, как и прежде? БЭМ может гарантировать это со 100% уверенностью? Нет? К чему тогда весь этот огород из классов?

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

Ну и да, как уже не раз было отмечено, SASS/LESS/Stylus позволяют минимизировать любые «мазохизмы», на более высоком уровне.

Иконку без проблем можно добавить фоном к ссылке. С паддингом, разумеется.

Откуда такая инфа?

Это тоже не по БЭМ — вложенные классы… По БЭМ скорее так:

.nav{}
.nav__item {} 
.nav__item-link {}

Вполне допускаю, что руками в яндексе тоже тягают не так много — по крайней мере xslt позволяет это делать, а для сохранения целостности css у них БЭМ и есть. Другое дело, что это в любом случае выливается в необходимость тягать какие-то куски, которые не будут меняться. И чем больше они не будут меняться — тем проще этим зверинцем управлять.

Не совсем, вместо псевдоклассов лучше использовать (если возможно) JS, который будет навешивать классы виде .element__hover или типа того.

Верно, получается заранее неизвестно, что именно самый маленький блок, и потому проще разбить вплоть до элементов.
С другой стороны если что-нибудь из мира less:

.search_bar {
bla bla bla
a {
color: blue;
}
}

И здесь можно легко копипейстнуть 'a'.

Пример выше посмотрите, как у них бэм реализован. Бредовый не коммент, а большинство решений яндекса.

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

>Все-таки не стоит с молоду приучать себя к готовым продуктам. Хороший верстальщик обязан разобраться во всем сам. Остальное — вопрос потраченного времени.

Я обычно для своих проектов сам делаю верстку, хотя ни разу не виртуоз less/css, но, допустим, у браузеров есть вшитые default стили. Обычно это полный отстой, подлежащий обнулению. И это первое с чем сталкивается кто-то с молоду. Мне вот хочется чтобы этот пережиток просто исчез и никогда больше не упоминал о себе. Потом новичок сталкивается с html селекторами, допустим, что есть и , он сидит, чешет репу и не очень понимает как именно правильно, потом он сталкивается с тегами представления и опять в задумчивости над .

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

Человек не будет совершать ошибки, если у него нет выбора, bootstrap своей структурой классов и их привязкой кроме прочего навязывает очень корректный html, например нормально прописывать бирки к полю в форме (я до сих пор повсюду вижу формы, где поля и подписи к ним сделаны двухколоночной таблицей) или caption к таблице. В итоге, новичок, который просто полез в его мануал впитывает хорошие практики, и только после этого, на мой взгляд, стоит вникать в детали шестеренок.

>С другой стороны, есть огромный круг задач, где не обойтись использованием каких-то определенных концепций / фреймворков и тп. и приходится подстраиваться под логику бэкэнда, а там, поверьте, бардак не меньший.

Хороший вариант логики бэкэнда это он вообще не в курсе про html и css, и предоставляет удобный api, который в свою очередь использует front-end на js, который занимается шаблонизацией и всем прочим. Негоже жаловаться на бардак если область его возникновения не была вовремя изолирована. Если очень нужно выдавать именно html с серверной стороны, то можно задуматься о службе шаблонизации между бэком и выдачей, которая в случае невозможности этого процесса на клиенте возьмет ее на себя. К этому все идет и это, с точки зрения архитектуры, наиболее внятная схема.

Идея сплавить front-end и back-end лучше всего была выражена в gwt и судьба его при всех плюсах и продуманности сложилась просто никак.

>Все-таки не стоит с молоду приучать себя к готовым продуктам. Хороший верстальщик обязан разобраться во всем сам. Остальное — вопрос потраченного времени.

Я обычно для своих проектов сам делаю верстку, хотя ни разу не виртуоз less/css, но, допустим, у браузеров есть вшитые default стили. Обычно это полный отстой, подлежащий обнулению. И это первое с чем сталкивается кто-то с молоду. Мне вот хочется чтобы этот пережиток просто исчез и никогда больше не упоминал о себе. Потом новичок сталкивается с html селекторами, допустим, что есть <button> и <input type="submit">, он сидит, чешет репу и не очень понимает как именно правильно, потом он сталкивается с тегами представления и опять в задумчивости над <b> <strong> <span class="strong">.

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

Человек не будет совершать ошибки, если у него нет выбора, bootstrap своей структурой классов и их привязкой кроме прочего навязывает очень корректный html, например нормально прописывать бирки к полю в форме (я до сих пор повсюду вижу формы, где поля и подписи к ним сделаны двухколоночной таблицей) или caption к таблице. В итоге, новичок, который просто полез в его мануал впитывает хорошие практики, и только после этого, на мой взгляд, стоит вникать в детали шестеренок.

>С другой стороны, есть огромный круг задач, где не обойтись использованием каких-то определенных концепций / фреймворков и тп. и приходится подстраиваться под логику бэкэнда, а там, поверьте, бардак не меньший.

Хороший вариант логики бэкэнда это он вообще не в курсе про html и css, и предоставляет удобный api, который в свою очередь использует front-end на js, который занимается шаблонизацией и всем прочим. Негоже жаловаться на бардак если область его возникновения не была вовремя изолирована. Если очень нужно выдавать именно html с серверной стороны, то можно задуматься о службе шаблонизации между бэком и выдачей, которая в случае невозможности этого процесса на клиенте возьмет ее на себя. К этому все идет и это, с точки зрения архитектуры, наиболее внятная схема.

Идея сплавить front-end и back-end лучше всего была выражена в gwt и судьба его при всех плюсах и продуманности сложилась просто никак.

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

Ну вообще, вешая стили на какой-то тег, сразу стоит понимать, чем это может обернуться. Вот я, например, раньше вешал бордер на input по молодости.
)

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