Артур Мудрик
Про переехать — если у вас цикл проекта это «макет - верстка - сдал - забыл», то да. Но проекты бывают и очень долгосрочные, где менятся может что угодно. БЭМ ведь специально и придумали, чтобы можно было безболезненно все переносить. Если это требование не соблюдается — это тоже не БЭМ.
В БЭМе никогда так не предполагалось делать. Другое дело, что по какой-то причине многим непонятен этот пункт с декомпозицией элементов (и да, я тоже когда-то писал block__element__element)
Вот именно, что в БЭМе есть вложенность только на уровне блок > элемент. Элемент > элемент нет. Подход с .block__header__icon немногим лучше чем .block > .header > .icon. А что? Тоже структуру очень хорошо отображает визуально.
В общем, нравится такая методология? Пожалуйста, никто не против. Но, пожалуйста, не называйте это БЭМом. На основе БЭМа — да. БЭМ? Нет.
Могу еще продолжить, что по-хорошему, в блоке не должно быть, например margin – блок не должен задавать отступы вокруг себя, он должен просто вписывать туда, куда его поставили. Отступы — удел элементов. Это правило очень облегчает жизнь на больших проектах. Но несоблюдение его никак БЭМу не противоречит, просто это правило я вывел для себя и продвигаю в компании, которой работают), может еще кому-нибудь пригодится.
Ну и вообще, я для своих мелких проектов начал отходить от БЭМа в сторону CSS Modules, решают они одну задачу, а стили выглядят проще.
Артур Мудрик .block__element__element – не БЭМ, чтобы вы не считали. Если иконки разные — так и назовите их по разному, не используйте ни для одной из них `.card__icon`, назовите их конкретнее.
А если вам понадобится поменять иконки местами, что, и классы будете менять?
Есть одно очень хорошее правило для именования сущностей: а если изменятся стили, будет ли название блока \ элементов отражать его суть? Именно поэтому .card__header__icon плохи — иконка может переехать. Именно поэтому плох какой-нибудь card_margin_10. И так далее.
Артур Мудрик Все зависит от того, какие это иконки и в целом от блока. Если это почти одинаковые иконки, можно сделать их с разными модификаторами. Если разные — можно дать класс, который более точно дает понимание что это за иконка, а не просто .card__icon. Возможно, card стоит разбить на несколько блоков (хедер и контент сделать блоками, а не элементами блока).
Но уж я точно не будет писать .card__header__icon или .card__headerIcon и буду бить по рукам подконтрольных мне разработчиков за это. Ибо это всё муть, а не БЭМ.
Артур Мудрик Ну, нотация от БЭМа. Только это не БЭМ. В БЭМе нет классов где элементы внутри элементов. Ознакомьтесь с БЭМом получше. Вот вам доклад из последних: habrahabr.ru/post/261973/.
mishapsv Вы уже задавали вопрос про неё и сказали, что она сложная ;) Речь про: https://github.com/CSSSR/csssr-project-template . Если что, пишите, могу помочь разобраться (лучше пишите сразу в скайп, быстрее получится).
copal spritesmith генерирует набор переменных и миксин(для препроцессоров) или сразу классы (для чистого CSS).
Сам миксин уже содержит: путь до картинки, размеры иконки, её положение.
Т.е нужно лишь вызывать миксин (на стайлусе, например: sprite $icoName) и всё.
Вадим Егоров Вы таки распутайтесь, наведите порядок у себя в голову, а потом скажите точно что вам нужно.
Причем тут поддержка хештега? Везде поиск по хештегам идет через нормальный урл, а не через хеш.
Мы вас заупутали? Вы свой исходный вопрос-то прочтите. Хешбенг уж тем более не стоит сейчас юзать. И хешбенг использовался не для поддержки хештегов, а для навигации внутри SPA, когда не было History API.
И поймите уже. Что хештег и хеш не связывает вообще ничего. Ну, кроме того, что у обоих есть символ #.
Хеш — это часть в урле после #. Она используется для обозначения блока на странице (по его ID). И, соответственно, браузер скроллит к этому блоку чтобы его показать. Всё. То, что хеш в разные эпоху веба для чего только не использовался (хешбанг, например), показывает лишь то, что у разработчиков не было других вещей, а не то что хеш можно использовать для реализации чего угодно.
Ну а хештег — это уже приблуда из всяких социалок.
И зачем вам связывать эти две вещи — непонятно.
Вадим Егоров Разработчики твиттера криворукие. Разработчики ФБ криворукие. Разработчики инстаграмма криворуки. Разработчики ВК криворукие (мне продолжать?).
Один вы умный, ога. Вот этим вы и показали свой уровень.
Вадим Егоров Стыдно должно быть. Хештег и хеш в браузере — вещи ну вообще никак не связанные и нужны совсем для разных вещей. Хотябы посмотрел на на реализацию в разных местах. Вот вам урл от #productivity: https://twitter.com/hashtag/productivity. Видите у урле хеш?
desuvin а из самого свг-файла fill убрали? fill – наследуется. В стилях вы его ставите на svg и далее он наследуется до path. Но если у path уже стоит fill – он будет приоритетнее.
