dom1n1k

Да дело даже не в любви, а просто для браузера визуальный рендеринг страниц — это тот основной функционал, ради которого всё и затевается. Если его нет (ну хоть в каком-то виде) — нет и браузера, есть только набор вспомогательных кирпичей.

Я бы закрыл такой подозрительный аккаунт нафиг. Или нет, не закрыл бы, а просто положил в тумбочку и раз в полгода кидал на него 10 руб. А сам ушел бы на другой.

Поездки за грибами на еду или на продажу?

Пингвин мне скажет: тут можно не тратить время.

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

У меня для десктопа староватая версия Adobe Reader, ещё до того, как в него вкрутили весь этот блекджек с социалками и облаками. Для андроида — гугловский вьюер.

Когда-то Foxit был, топорненьким, но многообещающим продуктом. Сейчас это жирное и кривое страшилище, взявшее от продуктов Adobe все худшее и недобравшее лучшее.

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

Блин. Цсс это технология или язык если угодно, бэм — методология наподобии архитектурного паттерна. Какие задачи решают паттерны?

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

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

Там смысл был в том, что каскады влияли на скорость reflow.
И если вдруг ваше веб-приложение так устроено, что reflow случается часто (а способов его вызвать довольно много) — это могло вылиться в ощутимые подлагивания.

Оно потом в зависимости от фреймворка либо к классам хэши припишет, либо на атрибуты с хешами завяжется. В девтулс потом всё это смотреть — в глазах рябит.

Каскад действительно работает медленнее классов без вложенности, яндексоиды публиковали тесты.
Но реально заметную на глаз разницу это давало только на очень больших страницах — десятки тысяч узлов. В реальной жизни такие почти не встречаются.
Но некоторая разница всё-таки есть, это факт.

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

Никогда у меня такого не было. Обычно у элемента для каждого медиа-запроса переопределяется пара-тройка свойств, а то и вообще ноль. Элемент это ведь маленькая простая сущность, чему там меняться? Ну размер или отступ какой-то.
Повторюсь: если там реально приходится писать 132 строки, нужна декомпозиция.

На тупой вопрос тупой ответ: это удобно.

Тег tbody может быть, а может не быть. Или вместо него может быть thead/tfoot. Вместо тэга td может быть th.

В реальной жизни лейаут не константа, он постоянно меняется — это аксиома. И любая сильно связанная система быстро вступит в противоречие сама с собой.

Ага, уже проклюнулись первые зачатки бэма — modal блок, header элемент.
Какими символами они при этом разделены, совершенно неважно, это вопрос договоренностей и вкуса. Вы на правильном пути. Осталось понять, а зачем во втором случае привязываться к body?

У вас жуткая каша в голове.

В мобильном приложении

Это было объяснено несчетное количество раз, но многие почему-то не понимают. Или не хотят понимать, что вероятнее. Очень кратко в стопиццотый раз. Пример утрированный, чтоб на пальцах.

Есть страница, у неё есть шапка и подвал. Есть модальное окно, у него тоже есть шапка и подвал. Если написать так

body header { ... }
.modal header { ... }

то стили глобального хедера применятся не только где надо, но и к хедеру модалки тоже. Ну потому модалка очевидно входит тоже входит в body.

Но погодите! — скажет любой неофит, окончивший курс «Верстка за 24 часа» — ведь можно написать вот так:

body > header { ... }
.modal > header { ... }

Можно, но только в идеальном мире, где html-структура делается один раз и навсегда. А в мире реальном она в ходе жизни проекта меняется много раз — доработки дизайна, функционала, багофиксы… Хотелки заказчика, дизайнера, сеошника… И частенько бывает нужно вставить промежуточную обертку. Или переподчинить узел другому родителю. Или сменить тэг. Или перенести что-то в другое место страницы.

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

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

Но собственно спецификация html задает тегам семантику. h1 — это тег заголовка. Бэмчики кладут на спецификацию и создают свой значит класс «desktop-header__title», для них он имеет значение, а сам тег html (h1) -нет.

Семантика и стилизация это почти ортогональные вещи.

Даже функционал ссылок симулируется с помощью div и javascript, ну что это такое?

Тут вообще ловкая подмена понятий. Эмуляция ссылок через div+js — это одна из самых плохих практик, она всячески порицается, и к БЭМ-у имеет отношение… правильно, никакое.

Преимуществ несколько, но все их собирательно можно обозначить как «общие множители полезно выносить за скобку»

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

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

И как следствие: распутывать каскады и делать в них правки выходит настолько муторно, что каждое поколение разрабов идет по пути наименьшего сопротивления и лепит быстрые перекрывающие заплатки с еще более длинными каскадами и импортантами. Да и менеджмент подстегивает — надо поскорее. Со временем эти говнофиксы копятся и копятся, наслаиваются и наслаиваются… Я лично встречал каскады в 6-8 ступеней.
И в какой-то момент наступает понимание, что это необратимо — даже если я и хочу сделать всё правильно, я уже не могу. Там такие авгиевы конюшни, что разгрести его не представляется возможным, только сжечь. И даже самый добросовестный разработчик смиряется и просто плывёт по течению.

Сейчас вам расскажут, что новый человек не знаком с файловой структурой проекта, поэтому он сделает файл-дубликат в отдельной папке.
Любую систему можно сломать при должном уровне криворучия.

Бутстрап это пример очень таксебешного кода.
Не потому, что его пишут глупые люди, а потому что он:
а) ориентирован на нишу верстального фаст-фуда (я не хочу думать, я хочу фигачить тэги);
б) тянет на себе легаси-концепции из прошлого десятилетия.

Элемент на 100 строк тоже требует декомпозиции. Скорее всего, он вполне потянет на отдельный блок. У меня стили для одного элемента обычно не превышают 20-30 строк.

Если там несколько раз по 500 строк, блоку совершенно точно требуется декомпозиция.
Я бы начал задумываться о декомпозиции уже после ~100-150 строк суммарно на весь блок, включая все элементы и модификаторы.

Вероятность такой проблемы есть всегда.
Но если она случается, при использовании БЭМ-а она сравнительно легко решается, потому что блоки независимы — где-то что-то переименовали, и оно дальше работает. Просто небольшой рефакторинг, нормальный рабочий процесс.
А вот если там было месиво из многоступенчатых каскадов, да размазанных по разным файлам… Удачи в отладке :)

У вас несколько разных и при этом равноправных каталогов? Допустим.
Но тогда вы их как-то различаете? Условно говоря, один будет primary-catalog, другой secondary-catalog. Соответственно получаем .primary-catalog-products-list.
Или может один будет promo-catalog или ещё как-то. Ноги обычно растут из бизнес-логики, никакие имена классов не выковыриваются из носа.

Эта проблема ортогональна БЭМ-у, она возникает (и довольно легко решается) при любой методологии.
Решение: запрещено использовать имена блоков, состоящие из одного слова, потому что однословные имена всегда слишком общие и расплывчатые.

Ну назову я список .products (товары) и что? У меня товары есть в каталоге, в корзине, в вишлисте, в инвойсе, в истории заказов…
Другой пример: блок .header — сразу признак малоопытного верстальщика. Хедер может быть у страницы, у статьи, у сайдбара, у модалки, у чего угодно. Это камешек в огород тех чудаков, которые думают, что семантические тэги header или nav решат все их проблемы.

Помимо принадлежности к странице, еще нужно различать группы товаров и собственно товары.

Поэтому в 99% случаев имя блока состоит из 2-3 слов. 4 слова и более уже многовато и используется только изредка.

.catalog-products-list — список товаров в каталоге
.catalog-products-list__item — элемент списка, отвечающий за позиционирование вложенного блока
.catalog-products-item — отдельный товар (каждый блок знает только собственное устройство, но ничего не знает о своем позиционировании)
.catalog-products-item__title — заголовок товара и так далее

Предвижу возражения.

1. Это же так длинно и нечитабельно!
Да, длинновато. Нет, вполне читабельно. К длине классов быстро привыкаешь и вскоре именно они становятся очень удобны и информативны. Прочитал и сразу все понятно. А не ползанаешь по дев-тулс в попытках понять, из какого каскада класс .list подхватил это свойство…

2. Почему не использовать модификаторы?
Типа вместо .catalog-products-list не написать .products-list--catalog.
Иногда можно. Но вообще модификаторы предназначены для смены декора, а семантически и по конструкции блок должен быть один и тот же. В нашем примере список товаров в каталоге и корзине существенно отличаются по всем показателям.

Нет, скорость они называли как один из факторов, но не основной.
Найдите и посмотрите видео Харисова, он подробно рассказывал откуда, как и почему появился БЭМ.

Один-единственный недостаток, но увы принципиальный — это невозможно.
Количество комбинаций таких хотелок устремится к бесконечности, их невозможно учесть, просчитать и отладить.

Частные настройки (цветовая тема или размер шрифта, например) вполне возможны. Или выбор из 2-3 фиксированных режимов лейаута — тоже могут быть. Ключевое слово тут «фиксированных» — то есть таких, которые спроектированы дизайнером и контролируемы разработчиками.

Скины (то есть полная перелицовка внешнего вида в свободной форме) — нет. Это огромный источник гемора и выхлоп от них незначителен. Вспоминая тот же Винамп — к нему существовали сотни, тысячи скинов, но приемлемых среди них было наверное 1%, а всё остальное колхозные поделки в стиле «я у мамы фаташопир».

Вот именно — выбирать из имеющихся вариантов и как-то компоновать их.
А не прийти в магазин и сказать: мне вот эти самые ботинки, только каблук на 2 см выше, вместо кожи я хочу замшу, шнурки вместо 5 дырок на 7 и чтоб по канту узор в виде меандра… А в остальном всё как есть, я просто под себя ваш продукт настроил.

Прочитав заголовок, я подумал, что внутри будет одно из двух. С вероятностью 95% это очередной горе-разоблачитель, который рассматривает БЭМ как набор чьих-то странных прихотей и совершенно не понимает, почему он устроен именно так и какие проблемы призван решать. Ну и с вероятностью 5% я узнаю какую-то новую, крутую, интересую идею. К сожалению, теорвер не подвел.

Многолетний опыт верстки мне говорит: БЭМ не идеален, но это лучшее из имеющегося. Никакая другая методология не выдерживает конкуренции с ним на практике. (Единственное исключение — css-in-js, но это игрок с несколько другого поля). Существенно лучше него может быть только радикальная переделка всего стандарта CSS, с блекджеком и неймспейсами.
Ценой некоторой многословности он решает огромную кучу проблем.
Каскад БЭМ не отрицает, а лишь призывает к ограниченному его применению. Изобретался каскад в древние времена, когда сайты были на порядок проще, а сейчас условия изменились — вылезли на поверхность побочные эффекты.
Препроцессоры он тоже не отрицает, а наоборот прекрасно с ними сотрудничает.
Остальное даже комментировать нечего.
Короче, учиться и ещё раз учиться.

Честно говоря, возможность кастомизации в том виде, каком вы ее описываете (а ля винамп), выглядит признаком школотронской софтины. Школотронской в смысле целевой аудитории. Серьезному приложению это не нужно, потому что а) не нужно, никто не будет этим заниматься, некогда б) лишний огромный источник багов.
Просто UI должен быть хорошо проработан и отполирован. Кастомизаторская чесотка — она знаете ли, не на пустом месте возникает, а от плохих UI.
Настройка UI должна ограничиваться сменой темы (светлая/темная, как у телеграма или хабра) и расположением/отключением кнопок на тулбаре (бразеры, офис и пр).