на старте разработки css правила быстрее и проще писать в одном файле.
b-name/b-name.css
.b-name { .. }
.b-name__item { .. }
.b-name_mod_val { .. }
быстрее кодить, проще рефакторить. преимущества от раскидывания кода по отдельным файлам появляется существенно позже, когда кода становится много, либо возникает необходимость в точечных переопределениях. есть-ли какая-то инструментина для распиливания такого css и раскладывания по файлам?
какрас сегодня думал почему никто не делает даклад о проблеммах БЕМ-а. разбивка компанента на множество мелких файлов одна из ярких странностей БЕМ-а
имхо если для компонента требуется более 1-го css файла то стоит подумать о том чтоб разбить этот компонент на более мелкие.
В официальном наборе такого инструмента нет.
Сделать его не должно быть сложно. Для парсинга css можно использовать gonzales.
Вы можете не разбивать css блока на несколько файлов, если вам это не удобно. Методология в этом месте не накладывает ограничений.
все же сборочный фрейморк, разруливая зависимости, работает с файлами, а не правилами css. когда весь код находится в одном файле появляется засада с переопределениями. для них важен порядок правил, но он будет верным лишь в случае, когда сущности разложены по файлам.
а есть какой-то неофициальный набор (мм.. неужели Яндекс опенсорсит лишь необходимый, но не достаточный стек технологий)?
ну так люди читают документацию, потом видят примеры (даже в самых простых) и думают что так и должно быть.
за ссылку спасибо. для того, чтобы глубже разобраться как устроена механика бэм, прояснить ряд непонятных для себя моментов, и как-то оптимизировать работу с версткой, пробую писать бэм-декомпиляторы (про html -> bemjson вроде уже говорил тут).
распиливание css сначала тоже показалось простым (и я даже не стал писать юнит-тесты %)). но на деле задачка оказалась полной интересных особенностей и неоднозначностей. есть-ли какой-то мануал, где описаны правила раскидывания css по файлам?
пока пытаюсь делать догадки. с простыми селекторами все поняно. но селекторы могут быть составными, а еще для них важен порядок (что на практике выражается в уровнях переопределения).
с уровнями все более или менее понятно - парсим правила по-порядку (A A B), одноименные группируем ((A A)
для составных css селекторов ".a .b { .. }" придумалося следующий принцип: помещать код в файл для максимально конкретной сущности. который представляется думя правилами. 1. селектор читается справа-налево. 2. элемент конкретнее блока, а модификатор конкретнее всех.
например, результат разложения селетора
разложится в файл b-form-input/__popup-items/b-form-input__popup-items.css т.к селектор элемента popup-items стоит правее, а значит он конкретнее.
или вот
будет помещн в файл b-link/_pseudo/b-link_pseudo_yes.css , а не в b-link/b-link__inner.css , т.к. модификаторы обычно используют когда нужно указать какое-то специальное поведение.
а вот как быть вот в таких случаях?
b-search/__input/b-search__input.css или b-input/__text/b-input__text.css - ума не приложу? следуюя правилу, сейчас получается второе. но кажется что должно быть певое, т.к. b-input похож на библиотечный блок, а специальная сущность в данном случае это b-search (которая переопределяет контрол внутри себя). что упускаю?
в общем, как обычно в исследованиях, вопросов много, а времени мало. код пишется в сотоянии неструктурированного аффекта, поэтому гитхабные ссылки показывать стесняюсь, чтобы не портить карму.
Неофициального набора нет, но кто-то же мог уже подобное написать (и никому не рассказать)
Как обрабатывается правило, где сначала идёт модификатор блока, а потом модификатор элемента? Модификатор элемента в этом случае «конкретнее» модификатор блока.
Правильнее, при прочих равных, первый класс считать более «конкретным», куда и помещать стили. Потому что первый класс в селекторе задаёт контекст, внутри которого нужно применять определённые правила.
В первом примере это b-form-input__popup, во втором — b-search__input.
И спасибо за попытку написать такой тул!
ксати, да. похоже я начал с плохих примеров, где приписывание контекста слева часто использовалось, чтобы добавить вес целевому правилу, не неся особой смысловой нагрузки.
чувствую, что нюансы перестали помещаться в голове - вернусь когда напишу тесты.
Тут кому как удобнее. У нас верстальщики заводят отдельные файлы под каждый блок, мельче не дробят только из-за того, что начинаются проблемы с производительностью сборки (используется не bem-tools). А хотели бы дробить меньше, чтобы для каждого элемента блока - свой файл со стилями.
Я не уверен, но мне кажется, что такой подход с опытом перестает казаться "яркой странностью" и приходит понимание правильности.
Мне кажется, то, что дают ребята из Яндекса - это намного больше, чем необходимо, для того, чтобы разрабатывать по БЭМ. Необходимой и достаточной была бы, наверное, статья про методологию)
Если вы сделаете такой инструмент - это будет интересно и вы будете молодец, конечно - но, честно говоря, мне бы его писать не пришло в голову. Он не поможет тем, кто собирается мигрировать на БЭМ-разработку - у них нечего будет раскидывать по файлам, потому что в CSS бардак. Он не поможет тем, кто сразу разрабатывает по БЭМ - потому что у них и так должно быть все по полочкам. Он поможет только тем, кто зачем-то начал все писать в одном файле, но при этом используя БЭМ-наименование. Аргумент, что так "быстрее кодить", на мой взгляд, не аргумент - быстрее (в целом) будет, если сразу все делать хорошо. Да и еще: правила мало будет раскидать по файлам, нужно будет еще и поправить соответствующим образом зависимости - а это уже задача посложнее. Может быть, конечно, я какого-то очевидно полезного применения не вижу...