БЭМ

[psywalker]

В вашем случае нужно что-то вроде .b-slider__title-emphasis, но не .b-slider__title__emphasis, в этом все дело.

Дружище, а почему? И что означает тире и название класса через него?

[Softlink]

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

.b-slider - класс блока

.b-slider__title-emphasis - класс модификатора. Т.о. первая часть класса показывает, что он относится к .b-slider, а вторая(через подчеркивание) указывает на то, что это модификатор.

[psywalker]

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

.b-slider - класс блока

.b-slider__title-emphasis - класс модификатора. Т.о. первая часть класса показывает, что он относится к .b-slider, а вторая(через подчеркивание) указывает на то, что это модификатор.

Нее, нее, это я знаю. Меня интересует конкретно вот эта часть "-emphasis". Что означает тире и что может идти после него?

[Softlink]

Нее, нее, это я знаю. Меня интересует конкретно вот эта часть "-emphasis". Что означает тире и что может идти после него?

Да ничего оно не показывает. Это просто название такое и все. Насколько я помню, Яндекс использует дефис только в названиях классов, а модификаторы отделяет подчеркиванием. Т.е. этого дефиса может и не быть.

[Gaspode]

.b-slider__title-emphasis - класс модификатора. Т.о. первая часть класса показывает, что он относится к .b-slider, а вторая(через подчеркивание) указывает на то, что это модификатор.

Ну здрасьте. Модификаторы не так пишутся.

.b-slider__title_size_big — вот это модификатор, например. И вешается он не на часть заголовка, а на весь заголовок, который, в данном случае, больше обычного.

В вашем случае нужно что-то вроде .b-slider__title-emphasis, но не .b-slider__title__emphasis, в этом все дело.

Да, я тоже к этому пришёл.

И что означает тире и название класса через него?

Да ничего, по сути) Просто название класса из двух слов. Надо же его как-то назвать, чтоб понятно было, что он означает.

Edited January 5, 2012 by Gaspode

[Softlink]

Ну здрасьте. Модификаторы не так пишутся.

.b-slider__title_size_big — вот это модификатор, например. И вешается он не на часть заголовка, а на весь заголовок, который, в данном случае, больше обычного.

Так и какая разница с тем что я написал?

[Gaspode]

Разница в том, что модификатор модифицирует весь блок/элемент, а не его часть. А в описанном случае надо только часть.

[Ялекс]

За матрешку спс. Поразбираю, такие решения нужно держать под рукой.

Какая лицензия продукта?

В перспективе хочется изменить именование классов для open source CMS.

Edited January 5, 2012 by Ялекс

[Radiocity]

В перспективе хочется изменить именование классов для open source CMS.

Только если дополнительным модулем, а то убьешь проект, который мне нравится

Почему? Потому что БЭМ - это Михалков интернет технологий.

Edited January 5, 2012 by Radiocity

[Ялекс]

В перспективе хочется изменить именование классов для open source CMS.

Только если дополнительным модулем, а то убьешь проект, который мне нравится

Почему? Потому что БЭМ - это Михалков интернет технологий.

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

Я еще поработаю с 960s. Многие советуют. Из проекта Матрешка хочу взять CSS готовых элементов, если конечно автор не против.

Просто сейчас создание лэйаута форм в админе не очень удобное, хочется стандартизировать и сделать проще.

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

Edited January 5, 2012 by Ялекс

[Gaspode]

А вообще, есть тут кто-нибудь, кто может авторитетно проконсультировать по теме? В личном порядке, чтобы форум не засорять. Вопросы постоянно возникают, и иногда гораздо проще картинку показать, чем рассказать, а картинки я тут показывать далеко не всегда могу. Если заплатить надо, ну окей.

[exessqd1]

Ялекс, автор не против.

Gaspode, спрашивай здесь, потом добавим в "Вопрос-ответ".

[rash]

Почему? Потому что БЭМ - это Михалков интернет технологий.

Ой, ошибаетесь, впрочем как и я года полтора-два назад.

БЭМ как технология, может (даже точно) нужен не всем, а вот от его составляющей - подхода АНБ точно никому хуже не будет.

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

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

[exessqd1]

Ветка комментариев закрыта, а ещё так хотел побеседовать

Как вывод можно сказать, что сейчас нет ни одной причины не использовать БЭМ на своих проектах.

[psywalker]

Ветка комментариев закрыта, а ещё так хотел побеседовать

Вот именно, что закрыта. Закрыта из-за тебя, между прочим

А я ведь тоже хотел для себя там узнать полезную информацию

Как вывод можно сказать, что сейчас нет ни одной причины не использовать БЭМ на своих проектах.

Опять же, это твой вывод.

[Gaspode]

подхода АНБ точно никому хуже не будет.

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

А есть место, где эти правила изложены? Всё, что я находил, — либо общие слова, либо совсем уж детские примеры, которые непонятно как интерполировать на что-нибудь покрупнее.

Edited January 7, 2012 by Gaspode

[pepelsbey]

Как вывод можно сказать, что сейчас нет ни одной причины не использовать БЭМ на своих проектах.

ORLY

[psywalker]

Как вывод можно сказать, что сейчас нет ни одной причины не использовать БЭМ на своих проектах.

ORLY

Да а чё ты смеёшься? Это фанат, идущий слепо вперёд, не замечая никого и нечего вокруг себя. БЭМ - это Бог для него

[Ялекс]

Как вывод можно сказать, что сейчас нет ни одной причины не использовать БЭМ на своих проектах.

ORLY

Да а чё ты смеёшься? Это фанат, идущий слепо вперёд, не замечая никого и нечего вокруг себя. БЭМ - это Бог для него

Поддерживаю. По меньше бы фанатизма, побольше бы объективного взгляда на вещи не помешало.

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

Edited January 7, 2012 by Ялекс

[mishka]

Конечно ситуация неоднозначна.

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

Но в противном случае... думаю многие наступали на все те грабли которые описаны на http://bemclub.in/ в пункте "Правила хорошего тона в верстке".

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

Да большая часть начинающих верстальщиков так делают:

- меньше классов.

- меньше вложенность.

- больше списков.

Много здесь верстальщиков которые свободно ковыряются в чужом коде? Почему так много верстальщиков в своем резюме сразу пишут: "не занимаюсь доработкой чужого кода"?

Есть все же рациональное зерно в БЭМ.

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

Да и БЭМ можно будет потом постепенно внедрить, кирпичик за кирпичиком, если это будет необходимо в будующем данного проекта.

Но все таки полноценное использование БЭМ -- это максимальный гарант надежности и гибкости на протяжении всего существования проекта.

[Ялекс]

Все преимущество БЕМ меркнет, когда в стили лезут сторонние люди ради небольших доработок.

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

Если для личных проектов, или проектов внутри одной компании с обученным персоналом: ок.

Для других, где с проектом будут работать сторонние разработчики: преимущества сомнительны, потому что вся семантика отношений сразу разрушится и превратится в кашу с !important-ми.

Сейчас не многие научились и поняли как использовать HTML5, а уже прививать идеологию БЕМ или даже настоятельно обращать на путь истинный - это делать куда сложнее.

Я не против стандартизации методов работы со стилями, я даже очень даже за. Это небольшие вольные размышления.

Ну автору за труды естесcтвенно спасибо.

[amazori]

Вопрос к спецам по БЭМ. В примерах использован такой код (сократил для наглядности):

<div class="b-comment">

    <div class="b-divider b-divider_comment-head">
        <div class="b-divider__side">
            <a href="" class="b-comment__close">?</a>
        </div>
        <div class="b-divider__base b-comment__head">Заголовок</div>
    </div>

</div>

Для чего нужно совмещать блоки? Почему нельзя написать отдельный? К примеру:

<div class="b-comment">

    <div class="b-comment__head">
        <div class="b-comment__side">
            <a href="" class="b-comment__close">?</a>
        </div>
        <div class="b-comment__base">Заголовок</div>
    </div>

</div>

На мой взгляд при смешивании блоков становиться труднее разбираться в коде. Понятно, что CSS будет чуть больше, если блоки не совмещать, но в чем глобальные преимущества первого примера?

[Gaspode]

Для других, где с проектом будут работать сторонние разработчики: преимущества сомнительны, потому что вся семантика отношений сразу разрушится и превратится в кашу с !important-ми.

Это недостаток не БЭМ, это недостаток кривой организации работы. Та же самая фигня произойдёт и с вёрсткой, сделанной традиционным способом.

Нет ни одного метода делания чего-либо, который нельзя похерить, если руки растут из заднего места. Это не означает, что все методы делания чего угодно — плохи или что нет необходимости в разработке новых методов.

Edited January 7, 2012 by Gaspode

[exessqd1]

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

А есть место, где эти правила изложены? Всё, что я находил, — либо общие слова, либо совсем уж детские примеры, которые непонятно как интерполировать на что-нибудь покрупнее.

Официальная спецификация здесь.

На мой взгляд при смешивании блоков становиться труднее разбираться в коде. Понятно, что CSS будет чуть больше, если блоки не совмещать, но в чем глобальные преимущества первого примера?

Повторное использование кода.

[amazori]

Повторное использование кода.

Все же я вижу недостатки такого подхода. Объясню на примере. У нас уже есть готовый блок из библиотеки b-elastic. Пример.

На его основе решаем отобразить товары в интернет-магазине. Добавляем модификаторы для настройки внешнего вида. Пример.

Спустя время появляется необходимость отобразить эти товары вертикально. Приходится перезаписать c помощью модификаторов некоторые стили блока b-elastic. Пример. Тут даже проблема не в самом перезаписывании, а в логике. Изначально блок b-elastic предназначен для растягивания элементов по ширине горизонтально, а теперь в нем элементы отображаются вертикально. Ну либо придется менять сам HTML-код, что еще проблематичнее.

А вот если бы мы изначально не смешивали блоки (пример), то для изменения расположения элементов, нам потребовалось бы изменить лишь пару строк в CSS. Пример.

P. S. На Яндексе есть примеры со смешанными блоками?