как я понял выстраиваются новости по дате с учетом высоты предыдущих блоков.
открыв инспектор я удивился - все на position:absolute; left:xxx; top:xxx;
есть какой-то js скрипт, который их расставляет, но правильно ли это с точки зрения хорошей верстки? каким правильным и красивым способом можно реализовать подобную колоночную верстку новостей?
Делал недавно в качестве эксперимента нечто похожее, но без абсолютного позиционирования. Просто нужно немного поменять логику упорядочивания блоков codepen.io/anon/pen/rVqBLK
в вашем примере блоки разбивается по колонкам и если например в первом посте будет много текста то вся колонка будет не очень красиво смотреться. Ну и порядок вывода постов будет сверху вниз:
Вах, глаз радуется от БЕМ, но в то же время кровоточит от CSS — в Codepen ведь можно юзать SASS/CSCC и прочие штуки, в них есть нормальная поддержка вложенности блоков и модификаторов — сразу красивее и нагляднее выглядит.
Что же касается вашего способа — это совсем не то, это только вначале выглядит как требуется в вопросе, но в реальности у вас там 4 колонки и в них, внутрь, вложены блоки — там никак не сделать нормальный респонсив — блоки будут выставлены не по порядку.
Сергей С: нет, порядок вывода блоков можно будет сделать как угодно, но Яваскриптом, а это жесть как жутко и ужасно :) И, да, полноценный masonry там действительно не получится, ибо тексты в разных блоках могут быть разными, поддерживаю.
Артур Мудрик Ну, нотация от БЭМа. Только это не БЭМ. В БЭМе нет классов где элементы внутри элементов. Ознакомьтесь с БЭМом получше. Вот вам доклад из последних: habrahabr.ru/post/261973/.
Александр Петров: ну а как бы вы сделали блоки, если у вас есть некий блок (card), в нем есть заголовок (header) и контент (content) и в обоих есть некая иконка (icon)? Неужели вы бы делали .card__headerIcon и .card__contentIcon? Жесть, бред, некрасиво. Или как-то иначе?
Артур Мудрик Все зависит от того, какие это иконки и в целом от блока. Если это почти одинаковые иконки, можно сделать их с разными модификаторами. Если разные — можно дать класс, который более точно дает понимание что это за иконка, а не просто .card__icon. Возможно, card стоит разбить на несколько блоков (хедер и контент сделать блоками, а не элементами блока).
Но уж я точно не будет писать .card__header__icon или .card__headerIcon и буду бить по рукам подконтрольных мне разработчиков за это. Ибо это всё муть, а не БЭМ.
Александр Петров: именно так и делаю и считаю это самым настоящим БЭМ. И я, конечно же, в курсе про модификаторы и про разбитие одной сущности на несколько — ясно же, что две почти одинкаовые иконки не нужно называть по-разному и распихивать в разные элементы. Но тут ничего не разобъешь — есть некая карточка, всё, точка, там её заголовок нельзя куда-то вынести в отдельную сущность, и иконки там, допустим, абсолютно разные, так, что ничего общего нет, чтобы немного в модификаторах нужно было всего лишь изменить. Вот такая ситуевина.
Артур Мудрик: порядок вывода я буду делать не скриптом, а шаблонизатором. Выводить в каждую колонку 1,5,9,... 2,6,10...3,7,11, 4,8,12 и так далее, за один проход генерится сетка. И это не супер устойчивая верстка, да. Я просто проводил опыт, как будут смотреться карточки разной высоты в сплошном потоке, так сказать.
Pavel Shvedov: ой мааамочки, так вы еще и шаблон будете генерировать на сервере и весь этот ХТМЛ отадавть на клиент... это вообще жесть в эпоху Яваскрипт-фреймворков. Ну и в любом случае, хоть серверный шаблонизатор, хоть клиентский — вам в любом случае Яваскриптом нужно будет рассчитывать, какие будут массивы цифр — все эти "1,5,9,... 2,6,10...3,7,11, 4,8,12 и так далее" нужно будет рассчитать в зависимости от количества элементов и количества колонок.
Артур Мудрик .block__element__element – не БЭМ, чтобы вы не считали. Если иконки разные — так и назовите их по разному, не используйте ни для одной из них `.card__icon`, назовите их конкретнее.
А если вам понадобится поменять иконки местами, что, и классы будете менять?
Есть одно очень хорошее правило для именования сущностей: а если изменятся стили, будет ли название блока \ элементов отражать его суть? Именно поэтому .card__header__icon плохи — иконка может переехать. Именно поэтому плох какой-нибудь card_margin_10. И так далее.
Александр Петров: ну, по букве закона я и раньше знал, что у меня не кошерный БЭМ, но тем не менее я его именно так использую. Возможно даже потому, что когда-то давно в БЭМе можно было так делать. Ваше правило да, абсолютно идеально, но вот как-то никогда не сталкивался, что что-то "может переехать" — в 99% ничего никогда не переезжает, хотя по идеологии это нужно учитывать и это правильно и верно :)
Александр Петров: И, кстати, еще в подходе .block__element__element мне нравится то, что в SASS/SCSS у меня визуально видна вложенность элементов — тобишь, в CSS я вижу, что "вот этот элемент у меня вот там, внутри того".
Артур Мудрик: я не говорил, что шаблонизатор серверный. Просто понятие "скриптом", это для меня jquery ковырять DOM, и добавлять руками элементы. Я прекрасно осведомлен о наличии клиентских фреймворков, с шаблонизаторами.
Артур Мудрик
Про переехать — если у вас цикл проекта это «макет - верстка - сдал - забыл», то да. Но проекты бывают и очень долгосрочные, где менятся может что угодно. БЭМ ведь специально и придумали, чтобы можно было безболезненно все переносить. Если это требование не соблюдается — это тоже не БЭМ.
В БЭМе никогда так не предполагалось делать. Другое дело, что по какой-то причине многим непонятен этот пункт с декомпозицией элементов (и да, я тоже когда-то писал block__element__element)
Вот именно, что в БЭМе есть вложенность только на уровне блок > элемент. Элемент > элемент нет. Подход с .block__header__icon немногим лучше чем .block > .header > .icon. А что? Тоже структуру очень хорошо отображает визуально.
В общем, нравится такая методология? Пожалуйста, никто не против. Но, пожалуйста, не называйте это БЭМом. На основе БЭМа — да. БЭМ? Нет.
Могу еще продолжить, что по-хорошему, в блоке не должно быть, например margin – блок не должен задавать отступы вокруг себя, он должен просто вписывать туда, куда его поставили. Отступы — удел элементов. Это правило очень облегчает жизнь на больших проектах. Но несоблюдение его никак БЭМу не противоречит, просто это правило я вывел для себя и продвигаю в компании, которой работают), может еще кому-нибудь пригодится.
Ну и вообще, я для своих мелких проектов начал отходить от БЭМа в сторону CSS Modules, решают они одну задачу, а стили выглядят проще.
Александр Петров: Ну, почему сразу «макет - верстка - сдал - забыл» — нормальные долгосрочные проекты, всё ок, проблем не было. Жесть типа .block > .header > .icon это вообще никогда, из-за веса селектора :) Ну и переностится всегда блок, а не внутренние элементы, так что перенесете вы .block куда-нибудь и всё будет ок, это никогда не отразится на block__element__element, ничего не произойдет.
Александр Петров: про отступы всё верно, отступы у меня всегда задаются родительским элементом, у которого совсем другой блок. Сам же блок ничего не знает о том, где он находится и какие там у родителя отступы.
Артур Мудрик: в данном случаи, иконки - это самостоятельные блоки, которые скорее всего будут использоваться на странице и в других блоках, поэтому, в соответствии с методологией БЭМ, блоки иконок можно представить так:
где icon - это базовый блок с дефотными значениями - url на спрайт или font-family шрифта, стандартными размерами и т.п., а icon_type_maximize - это блок уже с конкретным модификатором, где можно прописать необходимые background-position или content
Руслан Абдуллаев: да, блок icon это отдельный блок, всё верно, так и делаю, это элементарно. Но в блоке block у вас может быть элемент header и в нем может быть элемент icon — он не выводит иконку (иконку выводит отдельный блок, icon), он позиционирует ваш блок icon. Вот так —
Артур Мудрик: и в чем проблема? Зачем вам отдельный элемент для иконки, когда можно вложить блок иконки непосредственно в элемент header? Можно добавить еще один модификатор, который будет настраивать иконку под конкретный блок.
◅div class="block"▻
◅div class="block__header"▻
◅i сlаss="icon icon_close icon_card-header"▻◅/i▻
◅/div▻
◅/div▻
Руслан Абдуллаев: "Можно добавить еще один модификатор, который будет настраивать иконку" — нет, это уж точно делать нельзя. Иконка это иконка, она знает только о своих размерах (и то не обязательно), бэкграунде или content (это тоже не использую, ибо юзаю inline SVG), но уж точно не позиционирует себя куда-либо. Да и в таком случае у вас в файле icon.scss получится куча классов-модификаторов.
Руслан Абдуллаев: .block__header-icon — ужасно некрасиво, я использую .block__header__icon и всем советую, проблемы нет и не было и не может быть и не будет :)
Артур Мудрик: т.е. наличие .block__header__icon вас не смущает, а класс-модификатор не дает покоя?
Проблем у вас нет, потому-что вы не используете БЭМ и даже то, что вы пишете руками, к БЭМ не имеет отношение
Руслан Абдуллаев: ну не может быть в файле стилей icon.scss куча каких-то левых модификаторов, которые относятся к некоей иконке в некоем заголовке. ну это же бред полный создавать кучу модификаторов в файле icon.scss — там могут быть только модификаторы размеров, например, но уж никак не каке-то левые icon_header-icon — да и что это за header-icon, к какому заголовку это относится? Я пишу идеальнейший БЭМ, можно по этому поводу не сомневаться и не холиварить.
Артур Мудрик: .block__header__icon меня не просто не смущает, а это единственный очевиднейший простейший способ сделать то, о чем название этого класса говорит. И это абсолютно идеальнейший БЭМ.
Простой
