БЭМ

[rash]

Работали - мне даже приходилось разгребать эту кучу БЭМ-вского навоза!

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

Испортить можно любую идеологию. Если не понимать ее. То же ООП всегда правильно применяется и никогда не приносит проблем вместо решений? Значит ли это, что идеология плоха? Нет.

[HeadShot]

Работали - мне даже приходилось разгребать эту кучу БЭМ-вского навоза!

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

Испортить можно любую идеологию. Если не понимать ее. То же ООП всегда правильно применяется и никогда не приносит проблем вместо решений? Значит ли это, что идеология плоха? Нет.

Как бэ намекают на доступность, а не максимальный трэш, ради фана.

[lexxcode]

Nanto, мдааа..., мужик, ты даже не понял о чем я тебе сказал. Следи за тем, что и как ты говоришь! "Будь проще и люди к тебе потянутся".

Все засорять тему пустопорожними скандалами с тобой я не собираюсь.

[exessqd1]

Господа, а чем например тогда плох "CSS Less"? Зачем останавливаться на пол-пути оптимизации?

С LESS/SASS ты можешь разрабатывать свой проект в "ООП стиле" как в БЭМ, но CSS который в конечном итоге будет отправлен в браузер, будет таким как если бы ты ничего вообще не делал. LESS/SASS делают разработку немного легче, но они не решают проблем обычной верстки и никак не влияют на быстродействие.

И впринципе никто не запрещает использовать LESS/SASS вместе с БЭМ, например так:

.b-block {
    …
    ._foo {…}
    .__element {
        …
        ._bar {…}
    }
}

[Ялекс]

Вопрос залу.

Зачем тащить кучу зависимостей .name__... если можно пользоваться:

.container > .item

Начиная с IE7.

Edited January 24, 2012 by Ялекс

[rash]

Вопрос залу.

Зачем тащить кучу зависимостей .name__... если можно пользоваться:

.container > .item

Начиная с IE7.

1. От IE 6 еще недавно нельзя было отказаться.

2. Это привязка к структуре (если элемент может лежать как в корне блока, так и в подэлементе, потребуется два селектора).

3. Ну и наконец (в большинстве случаев не так важно) — этот селектор менее эффективен, хоть и достаточно быстр по сравнению со многими другими.

[Ялекс]

Вопрос залу.

Зачем тащить кучу зависимостей .name__... если можно пользоваться:

.container > .item

Начиная с IE7.

1. От IE 6 еще недавно нельзя было отказаться.

2. Это привязка к структуре (если элемент может лежать как в корне блока, так и в подэлементе, потребуется два селектора).

3. Ну и наконец (в большинстве случаев не так важно) — этот селектор менее эффективен, хоть и достаточно быстр по сравнению со многими другими.

1. Я о сегодняшнем положении вещей. Ясное дело, что Яндекс массовый сайт и еще не может просто так отказаться от IE6, хотя уже пора.

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

3. А мне кажется наоборот. Если вам в дереве необходимо выбрать элементы только верхнего уровня, и не учитывать вложенность, то это наоборот должно быть быстрее.

Edited January 24, 2012 by Ялекс

[HeadShot]

Что мешает Яндексу использовать select vizr?

Edited January 24, 2012 by HeadShot

[rash]

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

Есть какой-нибудь блок b-promo. В нем есть красивая кнопка-ссылка на продукт, b-promo__link. Со временем появилась необходимость продвигать несколько продуктов, для чего в блоке были созданы вкладки, в корень вложили еще один элемент — b-tabs. При нынешнем подходе, даже внутри b-tabs ссылки b-promo__link будут оформлены как надо (если не повлияют наследуемые стили, но тут осторожность и внимательность нужна в любом случае). При вашем — .b-promo > .link уже перестанет работать.

То есть это просто уменьшит универсальность. Такой подоход тоже может оказаться уместным, но в ограниченном количестве случаев. Вероятно, в БЭМ во главу угла поставлена универсальность в этом случае.

А мне кажется наоборот. Если вам в дереве необходимо выбрать элементы только верхнего уровня, и не учитывать вложенность, то это наоборот должно быть быстрее.

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

Что мешает Яндексу использовать select vizr?

Вы не знаете? И я не знаю. Но это ведь не значит, что ничто не мешает.

[HeadShot]

https://github.com/stubbornella/oocss/tree/master/core

https://github.com/stubbornella/oocss/wiki

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

Edited January 24, 2012 by HeadShot

[Ялекс]

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

Есть какой-нибудь блок b-promo. В нем есть красивая кнопка-ссылка на продукт, b-promo__link. Со временем появилась необходимость продвигать несколько продуктов, для чего в блоке были созданы вкладки, в корень вложили еще один элемент — b-tabs. При нынешнем подходе, даже внутри b-tabs ссылки b-promo__link будут оформлены как надо (если не повлияют наследуемые стили, но тут осторожность и внимательность нужна в любом случае). При вашем — .b-promo > .link уже перестанет работать.

То есть это просто уменьшит универсальность. Такой подоход тоже может оказаться уместным, но в ограниченном количестве случаев. Вероятно, в БЭМ во главу угла поставлена универсальность в этом случае.

А мне кажется наоборот. Если вам в дереве необходимо выбрать элементы только верхнего уровня, и не учитывать вложенность, то это наоборот должно быть быстрее.

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

Что мешает Яндексу использовать select vizr?

Вы не знаете? И я не знаю. Но это ведь не значит, что ничто не мешает.

У нас ведь цель какая: чтобы классы не пересекались. Да, может быть напряжно искать зависимости в такого рода селекторах.

Я правда, только недавно начал активно пользоваться селектором > в верстке (раньше думал, что данный не поддерживается IE7, оказалось все ок).

Буду вникать во все нюансы - опыта практики в этом вопросе пока маловато чтобы говорить однозначно. За пример спасибо, буду думать.

Edited January 24, 2012 by Ялекс

[HeadShot]

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

Есть какой-нибудь блок b-promo. В нем есть красивая кнопка-ссылка на продукт, b-promo__link. Со временем появилась необходимость продвигать несколько продуктов, для чего в блоке были созданы вкладки, в корень вложили еще один элемент — b-tabs. При нынешнем подходе, даже внутри b-tabs ссылки b-promo__link будут оформлены как надо (если не повлияют наследуемые стили, но тут осторожность и внимательность нужна в любом случае). При вашем — .b-promo > .link уже перестанет работать.

То есть это просто уменьшит универсальность. Такой подоход тоже может оказаться уместным, но в ограниченном количестве случаев. Вероятно, в БЭМ во главу угла поставлена универсальность в этом случае.

А мне кажется наоборот. Если вам в дереве необходимо выбрать элементы только верхнего уровня, и не учитывать вложенность, то это наоборот должно быть быстрее.

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

Что мешает Яндексу использовать select vizr?

Вы не знаете? И я не знаю. Но это ведь не значит, что ничто не мешает.

У нас ведь цель какая: чтобы классы не пересекались. Да, может быть напряжно искать зависимости в такого рода селекторах.

Я правда, только недавно начал активно пользоваться селектором > в верстке (раньше думал, что данный не поддерживается IE7, оказалось все ок).

Буду вникать во все нюансы - опыта пока маловато чтобы говорить однозначно. За пример спасибо, буду думать.

Просто я типовой селектор довольно часто использую. Мне так удобнее, ну и остальное, как бы. Просто очень не хочется чтобы тебя сожрал динозавр(если что про себя говорю).

Edited January 24, 2012 by HeadShot

[exessqd1]

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

Это обсуждалось здесь.

https://github.com/stubbornella/oocss/tree/master/core

https://github.com/stubbornella/oocss/wiki

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

Тоже самое можно сделать с помощью БЭМ-инструментов.

А вообще главная проблема OOCSS в неуникальности классов, а отсюда вытекают большие проблемы, такие как:

1. Увеличение сложности поддержки проекта - за счет того что классы не упорядочены и со временем смешиваются друг с другом, получается клубок шерсти который распутать просто так не получится, например, удалить из проекта часть кода, не затронув при этом другую часть, будет сложно.
   
2. Дублирование кода - раз точно понять к какому блоку относятся те или иные стили не получится, в проекте будут находится те части которые впринципе там не нужны, просто для того чтобы ничего не сломалось.
   

Что мешает Яндексу использовать select vizr?

Во-первых, любое решение эмулирущее какое-либо поведение через js, будет работать медленее чем нативное решение.

Во-вторых, это контекстно-зависимые селекторы и использование их в полной мере, противоречит принципам БЭМ,

их можно использовать для декоративных целей в соответствии с принципом graceful degradation, и в этом случае fallback на js будет не нужен.

Edited January 31, 2012 by exessqd1

[HeadShot]

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

Это обсуждалось здесь.

https://github.com/stubbornella/oocss/tree/master/core

https://github.com/stubbornella/oocss/wiki

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

Тоже самое можно сделать с помощью БЭМ-инструментов.

А вообще главная проблема OOCSS в неуникальности классов, а отсюда вытекают большие проблемы, такие как:

1. Увеличение сложности поддержки проекта - за счет того что классы не упорядочены и со временем смешиваются друг с другом, получается клубок шерсти который распутать просто так не получится, например, удалить из проекта часть кода, не затронув при этом другую часть, будет сложно.
   
2. Дублирование кода - раз точно понять к какому блоку относятся те или иные стили не получится, в проекте будут находится те части которые впринципе там не нужны, просто для того чтобы ничего не сломалось.
   

Что мешает Яндексу использовать select vizr?

Во-первых, любое решение эмулирущее какое-либо поведение через js, будет работать медленее чем нативное решение.

Во-вторых, это контекстно-зависимые селекторы и использование их в полной мере, противоречит принципам БЭМ,

их можно использовать для декоративных целей в соответствии с принципом graceful degradation, и в этом случае fallback на js будет не нужен.

Почему БЭМ не может взять что-то от OOCSS? Он настолько эгоистичен? Это как бы интересно, но для средних проектов и малых OOCSS гораздо больше подходит. Попробую как нибудь на досуге скрестить некоторые части, самому интересно.

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

Я даже не знаю что вам ответить по поводу медленности. У человека, который может настроить свой ПК все будет работать, как надо. Как правило те, у кого IE 6 и подобное имеют на компе такой беспорядок, что производительность браузера там по определению сами догадайтесь где.

Некрофобия какая-то.

[exessqd1]

Документ обновился до версии 0.7

Список изменений:

1. Небольшой косметический ремонт
   
2. Добавлен материал в раздел "Расшифровываем аббревиатуру БЭМ"
   
3. Добавлен материал в раздел "Вопрос-ответ"
   

bemclub.in

Библиотека обновилась до версии 0.35

Список изменений:

.b-grid

1. Исправлен баг IE6 когда ячейки перескакивали при уменьшении размера окна
   
2. Исправлен баг с изображениями в IE7
   

.b-divider

1. Исправлен баг со склеиными блоками в IE6
   

.b-article

1. Поправлен вертикальный ритм
   

bemclub.in/_matrioshka/

[banzalik]

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

Это сильно связывает руки при написании HTML. А это значит, что вы потеряете в гибкости и универсальности.

3. А мне кажется наоборот. Если вам в дереве необходимо выбрать элементы только верхнего уровня, и не учитывать вложенность, то это наоборот должно быть быстрее.

это медленней классов => медленней, чем БЕМ

Edited March 28, 2012 by banzalik

[troll]

Помогите, пожалуйста, понять, как решаются проблемы, связанные с каскадом. Например, в Матрешке в реализации блока .b-article есть такое правило:

.b-article a:visited {color: #974dac;}

Допустим, мне нужно внутрь .b-article вложить кнопку .b-pin с текстом определенного цвета. Я пишу следующий код:

<style>
.b-pin {color: green;}
</style>
<div class="b-article">
    <p>Lorem ipsum</p>
    <a href="/foo" class="b-pin">More</a>
</div>

Но после перехода по ссылке ее цвет изменится.

Как этого избежать? Я вижу следующие способы:

• Делать как Яндекс в библиотеке bem-bl, т.е. не использовать каскад почти никогда, а на каждый элемент навешивать класс. Меня как верстальщика такой подход устраивает, но, боюсь, его не оценят те, кто будет заниматься поддержкой и наполнением сайта.
  
• Использовать !important для повышения приоритета отдельных объявлений. По-моему, плохой способ, способный серьезно запутать код.
  
• Задавать стили, которые с большой вероятностью придется переопределить, с помощью простых селекторов (вместо .b-article a:visited писать a:visited). Тоже мало хорошего: как минимум, придется писать дополнительный код, т.е. к .b-pin дописывать .b-pin:visited.
  

Существует ли какой-нибудь более разумный и удобный вариант?

Edited April 8, 2012 by troll

[MiksIr]

Прикольная тема была.

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

Читаешь с наслаждением

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

[troll]

Неужели мой вопрос настолько глупый, что даже ответа недостоин?

Edited April 10, 2012 by troll

[Softlink]

Неужели мой вопрос настолько глупый, что даже ответа недостоин?

Я бы класс повесил. Что там можно не оценить?

[troll]

Довольно трудоемко навешивать классы вида .b-article__h1, .b-article__p, .b-article__ol без шаблонизатора.

[xeLL]

Уже как год используем на работе свой "форк", избавились от двойных подчеркиваний, например, много изменений в контексте проекта на рельсах, scss и т.п, сами понимаете

[exessqd1]

Ребят, проектом я больше не занимаюсь, хостинг закончится через пару дней. Кому нужно сохраняйте себе страничку/библиотечку, потом поздно будет Я предупредил.

[Svatov]

Спасибо, что хоть предупредил, не хотелось терять такую информацию в доступной форме. Всех людей с вопросами по БЭМ отправлял именно сюда...жаль конечно, что проект прикрыли, может какой-либо специализированный ресурс держал бы материал в качестве библиотеки у себя на хостинге?

Edited April 27, 2012 by Svatov

[psywalker]

Спасибо, что хоть предупредил, не хотелось терять такую информацию в доступной форме. Всех людей с вопросами по БЭМ отправлял именно сюда...жаль конечно, что проект прикрыли, может какой-либо специализированный ресурс держал бы материал в качестве библиотеки у себя на хостинге?

Я уже отписал письмо человеку. Если даст добро, то я всё сделаю.