Comments 10
<ahref="#" class="D C-white ..."><h3class="Mt0">Some card</h3><p>...</p><spanhref="#" class="D-ib P2u;5u ...">More</span></a>
Читал, читал, на этом стоп.
Тут уже не важен подход в стилизации.
Не эльфийский, а какой то сектантский язык для призыва демонов
Простите, но статья вызывает сомнения в том, что её автор угорал по бэму и пересмотрел все видео и статьи о нём. Ну или смотреть-то смотрел, но нормально не понял. Потому что иначе в примерах с погодой вопрос где тут блок, а где элемент не вызывал бы проблем.
Впрочем, автор тут даааалеко не одинок. Это удивительно, но факт. Бэм (имея в виду методологию именования, а не полный бэм-стек) - это несколько очень понятных правил и пара очень логичных практических принципов, уже чуть позднее наработанных практикой сообщества. Но очень многие разрабы их не осилили, сочиняют какие-то странные интерпретации и потом фрустрируют, что они не работает. Для меня это примерно как обнаружить на мехмате людей, не понявших смысл производной. Для рандомных людей с улицы это нормально, но там - грустновато. У меня когда-то даже была мысль написать статью, как снять проблему придумывания бэм-имен, но тогда чет не собрался, а сейчас наверное уже и смысла нет.
Что касается конкретно вашей библиотеки - писал в прошлой статье о ней, не буду повторяться.
Правила в БЭМ может и простые, понятные, но их реализация не всегда бывает таковой. Безусловно, если взять какой-то уже готовый большой проект и зафиксировать его во времени, то можно уверенно разобраться, где логично оставить что-то элементом, а где уже нужно выделить блок, чтобы в других частях его переиспользовать независимо.
Но, когда команда только развивает проект, перспективы его не очень ясны, а стратегия может меняться довольно быстро, сложно предсказать заранее, не потребуется ли в будущем в качестве блока то, что мы назвали сейчас элементом. БЭМ хорошая методология, и правила у неё на базовом уровне действительно простые. Но даже безупречное их понимание не решает другие проблемы, вроде многословности названий классов, повторения стилей в CSS и появления множества разных сущностей с похожим функционалом. Другие подходы, вроде Atomic CSS, это решают, но имеют уже свои сложности.
Но всё же сравнивать непонимание БЭМ с непониманием производной на мехмате - преувеличение, на мой взгляд. Как минимум есть ещё похожие методологии типа SMACSS, OOCSS, которые тоже нередко используются особенно на Западе, а в СНГ о них кто-то может быть и не слышал. Они ничем не хуже БЭМ-а. А производные всё-таки - это прямо основа основ анализа, без которой никуда дальше ты особо не двинешься в математической науке, чего не скажешь про БЭМ во фронтенде.
В любом случае я не скажу, что я в совершенстве знаю тонкости БЭМ. И я был бы рад понять, как всё-таки взаимно однозначно сопоставлять имена классов блокам и элементам в этой методологии. Так что я был бы рад увидеть вашу статью на эту тему)
Я бы не стал делать далеко идущие выводы о познаниях автора по одному риторическому приему (вопрос с позиции зрителя). В докладе на этом моменте был интерактив, поэтому так.
У меня нет проблем с определением Бэм-сущностей в UI, но эта операция периодически требует мыслетоплива. Момент с погодой в статье как раз это и передает. А если вы знаток Бэма, то покажите класс: напишите ваши варианты названия сущностей из примеров с сайта погоды. Работяги наверняка заценят.
А насчет того, насколько автор шарит за Бэм: если вам не хватило проверки на олда в начале статьи, то давайте еще одну проведем. На Бэм-форуме сидели? А в чем его прикол, знаете?)
Ну и я лично знаком с изобретателем Бэма - Виталя Харисов присутствовал в зале на этом моем докладе. Для меня это была большая честь! Кстати, помните, кто был главным соратником Витали по Бэму в те времена?)
пока молодо, это прикольно. но через пару-тройку проектов вернешься и скажешь, что за абркадабра?
другое дело сделать такой минификатор css, чтобы свой проект прогнал минификатором, и он в брузер выдал что-то подобное, и если у тебя там какая-то кривость выходит ты даже по минифицированной версии класса понял, где шляпу искать
Не сказал бы. Если однажды разобрался до уровня навыка, то он остается с тобой и легко восстанавливается, даже после перерыва. Тем более, если знаешь CSS, то уже почти знаешь mlut - они концептуально довольно близки.
И между проектами на одном атомарном фреймворке будет переключаться даже проще - утилиты везде одинаковые. Что не скажешь о проектах с рукописным CSS на том же Бэме. Там в каждом проекте дефолтные блоки, типа menu и card могут сильно отличаться по смыслу.
Для снижения точки входа хотелось бы версию с удлиненными именами которые бы по такому же принципу строились
Всё очень интересно, но лично меня сбивает с толку что C - color, Ca - color-adjust, а Cs -cursor, потом видишь Csc и уже кажется "мыслетоплива" тут потратишь больше чем где-либо. Нельзя ли как-то сделать одинаковое количество букв? В куче таких символов глаза сломаешь вчитываться, чуть больше читаемости и цены бы не было
Нельзя ли как-то сделать одинаковое количество букв?
В предыдущей статье более детально описано, почему все именно так. Этот алгоритм сокращений стал результатом недель труда и раздумий. Если описать его одним предложением, то:
Чем более популярно CSS-свойство, тем более простое и очевидное у него будет сокращение
color-scheme вы дай бог пару раз в год будете использовать, а вот color - чуть ли не каждый день, если регулярно верстаете) Раз в месяц заглянуть в доку - вроде не критично. А в перспективе у нас и подсказки в коде появятся, как у конкурентов)
Atomic CSS: верстка и легкость бытия