Эх, померли наконец… Моя первая постоянная работа. Пару лет там фронтэндил (2011-2012) *.qip.ru. Полный редизайн news и files (последнее было должно было интегрироваться с 4shared, но так и не взлетело), отделение fishki.net в самостоятельную организацию, реклама «новейшего IE9» и т.п. Основной домен (qip.ru), кстати, тогда был 6-ым по посещаемости в рунете (под 2 млн. хостов).
А про саму организацию (РБК) вообще ничего плохого сказать не могу.
Меня бэкэндщики тоже любят — я частенько сам внедряю. А ещё приятнее внедрять бэкэнд, когда классы нормально читабельны, а возникновение костылей и подводных камней — это уже не проблема бэкэнда, над этим должен думать фронтэнд. Так что сомнительный довод.
А давайте я вам теперь своё видение расскажу. Вот открываю я БЭМный код и вижу ".button.button_large". И мне это вообще ничего не говорит! Есть ещё блоки с таки классом и или нет. Мне это говорит только о том что человеек делавший вёрстку использовал синтаксис БЭМ. Всё! Мне все равно придётся открывать браузер и веб-инспектор, проверять, прокликивать и т.д. Или что, по-вашему БЭМный синтаксис сразу даёт какую-то гарантию?
Так я про то же речь и веду! Его надо продумывать. Просто сверстать по макету вообще не проблема. Но приходится учитывать например, что переход на мобильную версию осуществлялся только стилями на той же структуре HTML (а не display:block/display:none). Тот же flex — довольно гибкая штука (пардон за тавтологию) — главное изначально всё правильно поставить.
Нет. Для меня особое удовольствие доставляет мозговой штурм при проектировании каркаса лэйаута и корректном определении глобальных стилей — задача довольно опасная (и не необходимая). Но при это «читаемость кода» значительно возрастает.
Вообще незачем. Просто по аналогии с вашим верхним постом. Это даже вредно — без нужды повышает приоритет правил.
Ну так а при чём тут БЭМ? Это же всё довольно очевидные вещи. При этом БЭМ задаёт довольно жёсткие рамки, а я призываю к гибкости, а не копипастному следованию «философии БЭМ». Ладно, это всё бессмысленные споры и им уже не один год. Кто привык сидеть на БЭМ — будет защищать эту технологию и наоборот.
Почему противников тотального использования БЭМа принято считать полными идиотами? И всё у них разваливается постоянно, и классы они одни и те же используют, и каскады из тэгов строят… Если очевидно что стили затронут другой элемент DOM не имеющий каких-то наследственных признаков с родительским (сознательно не употребляю «блок»), то зачем к нему обращаться через подобный каскад? Причём тут вообще БЭМ? Дурак и на БЭМе напишет .header_wrap для обоих блоков.
Разве Яндекс говорил, что БЭМ следует всегда использовать всем? Вот автор данной статьи категорично заявляет, что никто никогда не должен им пользоваться.
Да, но занимается довольно активной рекламой. Так что мне неоднократно приходилось слышать требования к вёрстке одностраничного хомяка «БЭМ, SASS, Bootstrap»…
Т.е. мне ещё надо разбираться с конкретным препроцессором, вычленять оттуда нужные стилевые свойства и т.п. К тому же у механика работы препроцессоров идёт в разрез с философией БЭМ. А что, градиент (стилевое свойство отдельного блока) в БЭМ уже вдруг является отдельной сущностью? А псевдо-элементы в БЭМ тоже отдельными блоками реализуются?
Понимаете, вы смотрите на это со своей кухни — когда работаете в одной команде над одними и теми же проектами несколько лет — конечно, вам нет особой нужды смотреть на подобные вещи более абстрактно. Ну так вот пусть и яндекс проповедует это как собственную внутреннюю кухню, а не как «стандарт для веба».
А БЭМ разве не добавляет класс? Как он производит модификацию блока?
В то время я (не ограниченный жёсткими рамками БЭМ) могу как навесить доп.класс этому блоку, так и просто поставить цепочку контекстных селекторов (ведь у этого блока наверняка есть родитель с классом) — тут всё зависит от конкретного проекта. Есть гибкость. Я внизу статьи добавил комментарий о том, как инкапсуляция блоков сильно мешает поддерживать проект.
Хорошо, раз уж вопрос встал про поддерживаемость. Куча откликов что, дескать, в крупных проектах по другому нельзя. В крупных проектах и без того имеются свои правила написание кода, договоренности по именованию сущностей и т.п.
Первая проблема БЭМ — он по факту абсолютно не поддерживаем. Представьте, вам дают совершенно незнакомый проект на БЭМ и… скажем, говорят «у нас на сайте используется фирменный градиент с анимацией, надо бы поменять в нём цвета и сделать его двойным». Вы открываете стилевой файл и… что делать? Открывать веб-инспектор и вручную прокликивать каждый блок, потому что:
Не имеет смысла объединять разные по типу блоки, только потому что у них, например, одинаковый цвет или размер.
В любом вменяемом css-файле, где-нибудь ближе к началу наверняка будет определение а-ля ".blue-gradient".
Из этого вытекает вторая проблема БЭМ — он абослютно не гибок. Проекты бывают разные. Где-то надо нагородить несколько сотен блоков, а где-то хватит и пары (а всё остальное графика), а где-то вообще не используются блоки. И подходить ко всей этой кухне с такой категоричностью «не использует», «не должны», «не может», «не рекомендуется». То, что Яндекс вполне успешно пропагандирует внутри своей компании эту философию, вовсе не означает что её надо бегом возводить в разряд спецификаций. В разработке важен гибкий подход и выбор подходящего инструментария для каждой конкретной задачи, а вовсе не «только БЭМ, остальное говнокод».
Вообще ничего не понял! Если БЭМ нужен только для изоляции, то к чему тогда вообще городить велосипед? С задачей изоляции как раз справляются уникальные именования классов (что БЭМ как раз никак не решает).
Ну и поехавший блок как раз может разворотить всю вёрстку. И искать причину (какой нибудь font-size:0;) вы можете очень долго.
P.S. Почему-то у сторонников БЭМ всегда есть аргумент — «поналепят каскады тэгов, а потом удивляются почему вёрстка поехала». При этом почему БЭМ противопоставляется исключительно каскадам тэгов — не очень понятно…
Простите, почему у меня вдруг «внезапно стили… окажутся»? Я как бы не вслепую верстаю. На img всегда можно навесить свой класс. Более того, наследование CSS-свойств определяется ещё на этапе присвоения классов.
Я точно так же, как и БЭМ, могу спокойно обвешать классами каждую сущность. Только вот в отличие от БЭМ, я могу очень гибко пользоваться наследованием стилевых свойств. Определив классы для какой-то вышестоящей по иерархии сущности, я сразу их определяю для целого ряда вложенных сущностей, чтобы избавляет меня от нужды по несколько раз копипастить участки кода.
Этими правилами покрываются все возможные варианты оформления. Более того, в CSS файле каскад селекторов даёт наглядную демонстрацию уровня иерархии. Если потом возникнет нужда изменить оформление пунктов меню — то просто переписываем свойства в ".nav .item" — заодно сразу подхватятся стили и для пунктов вложенного меню. И только если возникнет задача — изменить пункты верхнего меню, не трогая пункты подменю, то тогда можно просто навесить новый класс и дописать:
Ср.
А про саму организацию (РБК) вообще ничего плохого сказать не могу.
А давайте я вам теперь своё видение расскажу. Вот открываю я БЭМный код и вижу ".button.button_large". И мне это вообще ничего не говорит! Есть ещё блоки с таки классом и или нет. Мне это говорит только о том что человеек делавший вёрстку использовал синтаксис БЭМ. Всё! Мне все равно придётся открывать браузер и веб-инспектор, проверять, прокликивать и т.д. Или что, по-вашему БЭМный синтаксис сразу даёт какую-то гарантию?
Ну так а при чём тут БЭМ? Это же всё довольно очевидные вещи. При этом БЭМ задаёт довольно жёсткие рамки, а я призываю к гибкости, а не копипастному следованию «философии БЭМ». Ладно, это всё бессмысленные споры и им уже не один год. Кто привык сидеть на БЭМ — будет защищать эту технологию и наоборот.
Почему противников тотального использования БЭМа принято считать полными идиотами? И всё у них разваливается постоянно, и классы они одни и те же используют, и каскады из тэгов строят… Если очевидно что стили затронут другой элемент DOM не имеющий каких-то наследственных признаков с родительским (сознательно не употребляю «блок»), то зачем к нему обращаться через подобный каскад? Причём тут вообще БЭМ? Дурак и на БЭМе напишет .header_wrap для обоих блоков.
Да, но занимается довольно активной рекламой. Так что мне неоднократно приходилось слышать требования к вёрстке одностраничного хомяка «БЭМ, SASS, Bootstrap»…
Понимаете, вы смотрите на это со своей кухни — когда работаете в одной команде над одними и теми же проектами несколько лет — конечно, вам нет особой нужды смотреть на подобные вещи более абстрактно. Ну так вот пусть и яндекс проповедует это как собственную внутреннюю кухню, а не как «стандарт для веба».
В то время я (не ограниченный жёсткими рамками БЭМ) могу как навесить доп.класс этому блоку, так и просто поставить цепочку контекстных селекторов (ведь у этого блока наверняка есть родитель с классом) — тут всё зависит от конкретного проекта. Есть гибкость. Я внизу статьи добавил комментарий о том, как инкапсуляция блоков сильно мешает поддерживать проект.
Первая проблема БЭМ — он по факту абсолютно не поддерживаем. Представьте, вам дают совершенно незнакомый проект на БЭМ и… скажем, говорят «у нас на сайте используется фирменный градиент с анимацией, надо бы поменять в нём цвета и сделать его двойным». Вы открываете стилевой файл и… что делать? Открывать веб-инспектор и вручную прокликивать каждый блок, потому что:
В любом вменяемом css-файле, где-нибудь ближе к началу наверняка будет определение а-ля ".blue-gradient".
Из этого вытекает вторая проблема БЭМ — он абослютно не гибок. Проекты бывают разные. Где-то надо нагородить несколько сотен блоков, а где-то хватит и пары (а всё остальное графика), а где-то вообще не используются блоки. И подходить ко всей этой кухне с такой категоричностью «не использует», «не должны», «не может», «не рекомендуется». То, что Яндекс вполне успешно пропагандирует внутри своей компании эту философию, вовсе не означает что её надо бегом возводить в разряд спецификаций. В разработке важен гибкий подход и выбор подходящего инструментария для каждой конкретной задачи, а вовсе не «только БЭМ, остальное говнокод».
Ну и поехавший блок как раз может разворотить всю вёрстку. И искать причину (какой нибудь font-size:0;) вы можете очень долго.
P.S. Почему-то у сторонников БЭМ всегда есть аргумент — «поналепят каскады тэгов, а потом удивляются почему вёрстка поехала». При этом почему БЭМ противопоставляется исключительно каскадам тэгов — не очень понятно…
Я точно так же, как и БЭМ, могу спокойно обвешать классами каждую сущность. Только вот в отличие от БЭМ, я могу очень гибко пользоваться наследованием стилевых свойств. Определив классы для какой-то вышестоящей по иерархии сущности, я сразу их определяю для целого ряда вложенных сущностей, чтобы избавляет меня от нужды по несколько раз копипастить участки кода.
Имеем, например такой HTML:
Ну и набор правил:
Этими правилами покрываются все возможные варианты оформления. Более того, в CSS файле каскад селекторов даёт наглядную демонстрацию уровня иерархии. Если потом возникнет нужда изменить оформление пунктов меню — то просто переписываем свойства в ".nav .item" — заодно сразу подхватятся стили и для пунктов вложенного меню. И только если возникнет задача — изменить пункты верхнего меню, не трогая пункты подменю, то тогда можно просто навесить новый класс и дописать:
Но лично мне подобные задачи встречались крайне редко.