Как можно реализовать вот такой прилипающий footer Ryan Fait's HTML5 CSS Sticky Footer на БЭМ?
Проблема в том, что блок должен обернуть содержимое body в тэг-обёртку и кроме того добавить определённые стили в и
Собственно, уже не в первый раз возникает проблема, когда на одном узле нужно разместить несколько сущностей: несколько элементов, несколько блоков и т.д. Это абсолютно не противоречит концепции BEM и называется миксами.
Но когда доходит дело до реализации, получается, что миксуемые сущности не отрабатывают свои шаблоны bemtree и bemhtml, а только добавляют свои классы.
Считаю такое поведение шаблонизатором некорректным, т.к. каждый блок имеет право на самореализацию, даже если он - всего лишь миксин.
Для примера, попробуйте скомпилировать это:
nav__item link popup tag
Это - элемент списка, который отображается в виде тега, является ссылкой, а при наведении, появляется тултип с подсказкой.
Пример, конечно не ахти, но суть в том, что такая ситуация возникнуть может.
Сейчас я это решаю, разнося сущности по разным узлам, увеличивая вложенность, но мне очень не нравится этот способ, т.к. является костылем, который можно не всегда применять, влияет на структуру документа.
Всем привет! Подскажите как правильно переопределять блоки для бандлов. Т.е. у нас есть desktop.blocks/header и touch-phone.blocks/header. Почему блок header определенный в touch-phone.bundles/index/index.bemjson.js подключаются из desktop.blocks, а не touch-phone.blocks?
Правильно ли я понимаю, что нельзя сматчиться на элемент блока, который примиксован к другому блоку?
// bemjson
({
block: 'start-screen',
content: [
{
block: 'button',
mix: {block: 'start-screen', elem: 'button'}
},
]
});
// bemhtml
block('start-screen')(
elem('button').tag()('p')
);
Выдает такой html
<div class="start-screen">
<div class="button start-screen__button"></div>
</div>
То есть правило в bemhtml не заматчилось. Ссылка на песочницу https://bem.github.io/bem-xjst/?bemhtml=block(%27start-screen%27)(%0D%0A%20%20%20%20elem(%27button%27).tag()(%27p%27)%0D%0A)%3B&bemjson=(%7B%0A%20%20%20%20block%3A%20%27start-screen%27%2C%0A%20%20%20%20content%3A%20%5B%0A%20%20%20%20%20%20%20%20%7B%0A%20%20%20%20%20%20%20%20%20%20%20%20block%3A%20%27button%27%2C%0A%20%20%20%20%20%20%20%20%20%20%20%20mix%3A%20%7Bblock%3A%20%27start-screen%27%2C%20elem%3A%20%27button%27%7D%0A%20%20%20%20%20%20%20%20%7D%2C%0A%20%20%20%20%5D%0A%7D)%3B%0A
Привет! А расскажите, пожалуйста, есть ли общепринятый способ, как избежать конфликтов имен блоков, пришедших из разных источников (от разных вендоров)? Где почитать?
Интуиция подсказывает, что раз есть большие компании, поддерживающие свои библиотеки блоков, наверняка же кто-то предусмотрел, что однажды кому-то понадобится подружить в одном проекте popup из библиотеки Яндекса и popup из библиотеки (условно) Mail.ru.
(поиск по "бэм вендор префикс" внезапно показывать что-то не то =))
Thx!
Если в lib1 и в lib2 есть блок с одним и тем же названием button, есть ли способ у себя на проекте использовать блоки из обеих библиотек? Например, lib1/button и lib2/button.
Такой вопрос уже задавали здесь https://ru.bem.info/forum/-234/, но ответов я не увидел.
Всем привет, объясните пожалуйста, как мне поможет БЭМ в случае если у меня есть блок например TopSales (показывает наиболее продаваемые продукты в интернет магазине) И у другого клиента, этот блок выглядит совсем по другому. Как мне использовать существующий блок? Там присутствуют теже сущности, имя, цена, итд, но расположение и логика совсем другие? Например у первого клиента 3 продукта в ряд, а у второго 4, у одного клиента на мобильном 2 продукта, а у другого (на 768пх - 3, 550 - 2 и меньше 55пх -1). Или другой пример мега меню. Вроди бы блок один. Но каждый клиент придумыает какие-то свои особенности, то хочет больше колонок, то хочет картинки товаров, третий хочет картинки с категорий, и каждый раз хотелось бы все переиспользовать, но по факту получается большую часть приходиться делать за ново, затрагивает ли этот аспект БЭМ?
Здравствуйте) Собственно сам вопрос в заголовке. Заметил, что собирается проект и с одним и с другим расширением. Для .bemhtml, соответственно, нет подсветки в phpstorm.
8 years ago
Вопросы по БЭМ
Добрый день! Внимательно прочитал всю доступную документацию в старом виде и в новом, несколько статей, посмотрел несколько вебинаров и лекций. Но некоторые моменты всё равно ускользнули от моего внимания и понимания. В целом эта непонятная ситуация причиняет мне физический дискомфорт. Боюсь, что для понимания многих вещей, придется просмотреть много кода, что бы найти примеры использования, а это камень в огород документации. Без ответа на эти вопросы, я буду плавать в методологии и не смогу ей воспользоваться.
Из документации я не понял:
1. Шаблонизация в браузере когда и зачем нужна? Я предполагаю, что весь HTML будет собираться на сервере, в том числе, что динамично будет отправляться клиенту. Но, коль есть возможность компилировать в браузере, хотелось бы узнать о плюсах и кейсах, когда это может понадобиться. Что, касательно ресурсов, насколько это ресурсозатратно?
2. Возможность частичной сборки и компиляции со статичными html файлами Многие элементы интерфейса - статичные, например, шапка, меню, футер, общие лейауты. Собирать их отдельно для каждого клиента - бессмысленно. Возможно ли как-то объединять уже собранный, статичный HTML и динамичные блоки?
3. Документация про сборку Я прочитал весь раздел про enb, но там скорее кейсы, чем сама архитектура. Мне непонятно, как организовать сборку для проекта в целом.
4. Как организовать сборку для дева, прода, лайв В продолжение предыдущего вопроса - для разработки и для прода требуются разные настройки. Я правильно понимаю, что разные настройки обеспечиваются разными файлами по типу make.js ?
5. Документация про декларацию Я не нашел цельной информации про декларацию (?.bemdecl.js), и всё, что я про это знаю - частички из статей про enb, из-за этого складывается ощущение, что я чего-то не догоняю.
_6. Почему и зачем есть BEMHTML и bh, какой для каких ситуаций лучше _ Я долго пытался понять - что делает bh, пока не понял, что это - еще один шаблонизатор, такой же, как BEMHTML. Так в чём же разница, и как так получилось, что есть два шаблонизатора? Какой из них под какие цели заточен? И, кстати, про bh нет документации.
_7. Где доки про BEMTREE, когда что лучше использовать _ Про BEMTREE лишь сказано, что синтаксис "Такой же, как в BEMHTML, но только с двумя режимами", при всём при том, что это - важный и основной инструмент при сборке. Очень хотелось бы увидеть примеры и объяснения, как делать шаблоны для BEMTREE.
8. Доки про SASS|LESS| любые модули Основной инструмент библиотеки для css - stylus, по историческим причинам. Хотелось бы узнать, как можно использовать другие препроцессоры. Я часто встречал мнение, что БЭМ - навязывает свой стек. Я понимаю, что это не так, просто инструменты дефолтные такие. Хотелось бы узнать, как можно в сборку включать те, что соответствуют моему стеку.
9. Контроллеры для сборки, практики BEM - штука хорошая, но кажется очень замкнутой в себе из-за того, что до конца не ясен сам процесс сборки и связь с внешним миром. Во всех статьях и гайдах говорится в-основном о статичных сайтах. И из-за этого, совсем мне не понятно, как сделать динамичный сайт, как организовать динамичную и частичную сборку, роутинг и т. д.
10. Шапка, лейаут в общем html Возможно, мой мозг еще не переключился в БЭМ-область, но мне до конца не ясно, как сделать общие части интерфейса для всех страниц сайта - каждый раз подключать header, content, footer?
11. Подключение скриптов, стилей, других библиотек. Если подключение своих скриптов, всё худо-бедно понять можно, то как подключить скрипты библиотек? Их ведь нужно указать в head (а некоторые скрипты в футере). Как же это всё делается в рамках шаблонов, страниц? Хардкодить?
12. Какие практики бандлов Из документации мне совсем не понятно что такое и для чего нужны бандлы. Как я понял - это собранные пакеты css и js, но куда их нужно пихать и зачем - непонятно.
13. Борщик Для чего борщик существует внутри enb, ведь в enb есть другие инструменты, для работы с файлами. В чем его отличие и назначение?
Возможно, многие вопросы очевидные или неправильно сформулированы, про неправильное пользование той или иной технологией. Каждый из этих вопросов - для меня важный, прошу, если вы знаете ответ или имеете мнение хоть по одному из них - не стесняйтесь.
Добрый день! Начинаю осваивать БЭМ методологию и пытаюсь понять архитектуру приложения. Мне сейчас непонятны некоторые вещи:
- Если, в зависимости от пришедших данных, мне надо вывести два разных блока, то где мы эту логику определяем? Какая есть практика этих фронтовых контроллеров, или они не нужны вовсе?
- Если внутри одного блока, у меня могут быть различные другие блоки, зависящие от логики, где мне эту логику определять?
- Чем бандлы отличаются от БЭМ блоков в их широком представлении?
Надеюсь, что вы мне поможете разобраться в этих хитросплетениях архитектуры.
Добрый день! В вёрстке в зависимости от задач периодически пишу логику, в которой необходим ajax.
- Сейчас я эмулирую ajax-ответы от сервера у себя в js-файлах. А для программиста оставляю закомментированный кусок чернового ajax-запроса.
- Программист получает от меня мой js-полотенчик
- И изменяет часть кода (убирает эмуляцию и дописывает необходимые ему куски ajax-запроса) Проблема в том, что ему каждый раз, как он получает от меня верстку, приходится вручную проделывать вышеописанные танцы.
Подскажите, как можно обойти эту проблему и не тратить нелишнее время?
Здравствуйте. Как я понял одна из фишек БЭМ - это декларативность написания кода, а также повторное использование блоков. В react и angular также есть директивы и компоненты, которые помогают многие вещи делать декларативно и переиспользовать. Обладает ли БЭМ - платформа какими - то уникальными преимуществами? Есть ли смысл использовать БЭМ в небольших проектах?
Привет!
Блоки должны быть изолированы. Родительские стили не должны на них влиять. Если на сайте, куда я встраиваю свой виджет, указан font-size, то он не должен перебивать размер шрифта в моём виджете. То же касается любых других свойств. Я пробовал решать этот вопрос при помощи postcss-autoreset со сбросом всех-всех стилей. Но если добавлять все css-свойства, чтоб блок в новом окружении НИКОГДА не поехал, то вес стилей же невероятно вырастает. Стилей становится черезмерно много. В связи с этим вопрос:
Какие стили по вашему нужно сбрасывать для блоков?
Насколько я понимаю css, наследуются почти все свойства. А даже если не наследуются, на сайте может быть что-нибудь вроде span {display: block} или более реалистичное a {display: inline-block}, что моему виджету явно помешает. Но как решить эту проблему без разрастания веса моего виджета?
Хочу детектить несколько фич. Кажется логичным сделать это через блок ua однако посмотрев код, я не понял как можно добавить свои проверки. В данный момент меня интересует проверка на поддержку fetch API.
8 years ago
Как быть с "рекурсивными" структурами в DOM (когда в блок вкладывается другой такой же блок)?
Привет! Уже довольно давно ломаю голову, как совокупить БЭМ-подход с регулярно возникающей ситуацией, когда где-то внутри блока нужно разместить один или несколько блоков с тем же названием.
У нас такая практика: есть блок, он описывает DOM-структуру, и к нему через модификатор можно цеплять один из заданных стилей для "раскраски". Например, меню:
<ul class="menu menu_style_main">
<li class="menu__item"><a href="#" class="menu__link">One</li>
...
</ul>
И стили:
.menu_style_main .menu__link {
font-size:20px;
color:#F00;
}
...
.menu_style_alt .menu__link {
font-size:12px;
color:#666;
}
То есть используем разрешенный методологией каскад "блок-с-модификатором - элемент".
Приключения начинаются, когда дизайнер рисует меню, в котором верхние пункты расхлопываются в попап, внутри которого свой маленький мир, как назло включающий пару вложенных меню. Вот картинка (с первого попавшегося сайта), иллюстрирующая идею: http://joxi.ru/1A5pxGZfK6BoB2
В этом случае селектор, выбирающий пункты главной горизонтальной менюшки, поймает и пункты вложенных вертикальных. Кто-нибудь знает более-менее цивилизованный способ, как с этим бороться?
Я вижу такие варианты:
- Явно описывать в CSS структуру блока, используя "стрелку":
.menu_style_main > .menu__item > .menu__link- вроде не труЪ, привязываемся к структуре DOM, вынуждаем себя ее помнить и суппорить изменения в 10 местах. - Спускать модификатор вниз на элементы, то есть вешать на все элементы блока правильный модификатор стиля:
.menu__link_style_mainetc. Если действовать в таком духе (учитывая, что проблема относится к любому модификатору блока), получим что-то типа pyramid of doom, но в стиле БЭМ - когда 90% html-кода расположены в атрибутеclass. Vermicelli of BEM. Как минимум работа со вкладкой Elements консоли разработчика станет очень грустной. - Считать, что это не один блок, а разные (по сути тупо переносим название стиля в имя блока):
.menu-main .menu-main__link {...}Во-первых, похоже на предыдущий вариант (приклеиваем название стиля ко всем элементам, только не как модификатор, как часть имени блока). Во-вторых, это все-таки один блок - семантика та же, поведение для JS то же, выглядит только иначе. - Сделать, чтобы вложенное меню на самом деле не было вложенным на уровне DOM (положить рядом и спозиционировать). Неудобно и не реализуемо для других случаев.
- Забить на все и тупо инлайнить стили прямо в HTML. Не канает, мы не SPA, собирать это все придется на сервере (а там PHP), и потом еще как-то дублировать поведение на клиенте.
Другие примеры "рекурсивности":
- блок "таблица" с элементами-ячейками (для рисования лейаутов, внутри ячейки может возникнуть новая "таблица")
- блок "персона", внутри показываются друзья (тоже "персоны")
- блок "сообщение на форуме", внутри текста может быть процитировано другое "сообщение на форуме"
(Вообще мы делаем конструктор, где юзер сам двигает блоки, и в теории вообще что угодно может оказаться внутри чего угодно).
Кто что посоветует, кто сталкивался с подобными траблами? Сейчас мы используем вариант №1 (селектор прямого потомка), и я склоняюсь к варианту №2 (перенести модификатор на элементы). Потому что зеркалить dom-структуру в CSS приходится руками, а развесить модификаторы мы можем автоматом. И второй вариант вроде бы валиднее с точки зрения методологии.
Расскажите ваши мысли, и может я что-то вообще упускаю? Спасибо )
Я бы хотел спросить, как правильнее по bem методологии. Имеется bh блок table для таблицы, нужно задать фиксированную ширину колонок только для этой таблицы, есть два способа mix и mod, mix больше кода, у элементов больше на один класс, но зато весь внешний вид в блоке 'orders-table' mod наверное правильнее по методологии, но не явно видно в проекте для дальнейшей поддержки, к тому же будут ещё несколько таблиц со своими размерами.
mix:
{
block: 'table',
mix:[{block: 'orders-table'}],
content:[
{
elem: 'colgroup',
content: [
{
elem: 'col',
mix: [{block: 'orders-table', elem: 'col', mods: {column: 'one'}}],
},
{
elem: 'col',
mix: [{block: 'orders-table', elem: 'col', mods: {column: 'two'}}],
}
....код таблицы....
}
]}
mod:
{
block: 'table',
mods: {orders:true},
content:[
{
elem: 'colgroup',
content: [
{
elem: 'col',
mods: {'orders-column':'one'},
},
{
elem: 'col',
mods: {'orders-column':'two'},
}
....код таблицы....
}
]}
Доброго времени суток, подскажите начинающему, как правильно задавать margin независимым блокам, согласно методологии БЭМ? Ведь блок не должен отвечать за свое позиционирование, а только за шрифты, бокс-модель и прочее, но не margin..?
Привет всем! Начал посматривать в сторону redux. Сама идея довольна интересна, хотя окончательно в голове не уложилась. Хотелось бы узнать мнение сообщества о паттерне, укладывается ли он в методологию БЭМ.
Привет господа.
У меня концептуальный вопрос: почему сложные правила именования не упрощают используя встроенные примитивы HTML?
Существует ли формализованный список по которому можно проверить качество вёрстки по БЭМ?
Я буду читать две лекции по БЭМ для junior-разработчиков внутри EPAM и давать домашнее задание. Потом нужно будет оценить качество его выполнения, выставить оценки. Эти оценки непосредственно будут влиять на их перспективы на работе. Слушателей будет около 100 человек, критерии должны быть простые и понятные.
Я пока вижу такой вариант: Задание:
- Сверстать (вручную, BEM CSS) каркас страницы по заданному дизайну — на выходе страничка
- Внести правки:
- переместить какой-то блока между холдерами
- отредактировать какой-то блок
- удалить какой-тоблок
- вставить сторонний блок
Критерий оценки:
- Ничего не должно развалиться
- Верстка должна соответсвовать неким критериям.
Критерии
- Можно четко выделить блок, элемент и модификатор в именах (https://twitter.com/harisov/status/716160112486977540)
- … Ваши предложения, мнение?
Здравствуйте! Изучаю бэм, возник вопрос - правильно ли делать так:
<div class="info-box">
<div class="info-box__item info-box__item_time">Время</div>
<div class="info-box__item info-box__item_money">Деньги</div>
<div class="info-box__item info-box__item_number">Номер</div>
</div>
Смущает _time; _money; _number в названии классов.
Так можно делать?
Естественно при условии, что на _time; _money; _number навешиваются доп стили, на каждый элемент свой стиль.
Всем доброго Как правильнее поступить с точки зрения БЭМ-методологии, чтобы не вводить в ступор опытных разработчиков, и придерживаться классических стандартов? Задачу можно решить разными способами, и именно в этом подвох:
Есть несколько блоков, очень похожих между собой. Пускай это будут куски страницы с разным цветом фона (каждый такой кусок является блоком). А внутри — текстовые элементы (заголовки, списки, параграфы…), которые, в зависимости от фона, нужно выводить разным цветом. Напрашивается вывод об использовании модификаторов.
Т.е. для начала описываем дефолтный (базовый) блок и все его элементы: получается следующий HTML div.b_block>p.b_block__elem, и два стиля впридачу .b_block {…}, .b_block__elem {…}
Но как быть с, к примеру, с инверсной модификацией, когда цвет блока и текста меняются местами?
Что если применить модификатор только к блоку, т.е. div.b_block.b_block--inverted>p.b_block__elem, и селектором .b_block--inverted .b_block__elem { задать стили элементу } (подразумевается, что есть также стиль .b_block--inverted {…})? С таким же успехом можно навесить модификатор и на блок, и на элемент сразу. Или использовать два разных модификатора — один для блока, а другой для элементов.
Вот только как правильнее?
Пример очень упрощен, но хорошо отражает суть моего ступора. Спасибо
Всем привет. В основной моей теме с вопросами по созданию проекта на PHP никто не отвечает, приходится создавать новую =(
Как новичок в этой методологии могу с уверенностью сказать, что самостоятельная точка входа в тему БЭМ за пределами понимания рядового разработчика (по крайней мере говорю о себе). Человеку никогда не работавшему с технологиями используемым в полном стеке БЭМ кроме того что изучить эти технологии, нужно понять как использовать их вместе. Всякие deps файлы, bemtree, bh и т.д. А ещё всё это собирается с помощью ранее неизвестного мне enb, требует установки node.js, хотябы какого-то понимания что такое npm и bower. Человеку всю жизнь использовавшему PHP и C# это начинает казаться реально непростой задачей. Прочитав bem.info думаешь прекрасная концепция, всё понятно. Но берёшься за дело и понимаешь что всё прочитанное ты или забыл, или не правильно понял и всё не так просто. Приходится спамить этот форум или методом тыка и перечитыванием информации искать решение...
В общем: 1) Скачал project-stub 2) Дополнил его библиотекой bem-core-php 3) bem-components-php НЕ СТАВИЛ, ибо пока не знаю зачем оно надо. Других непонятностей итак навалом 4) В папке desktop.bundles пачку index трогать не стал, создал свою firstpage. Положил в неё файлы firstpage.php и firstpage.bh.php, наполнил их в соответствии с примерами из инструкции к установке bh-php (эти примеры заработали у меня) 5) Чисто ради интереса решил попробовать собрать, ниже лог
alexander@achtung-PC:~/DeveloperWorkspace/WEB_BEM_PHP_Yandex$ enb make 22:08:27.321 - build started 22:08:27.374 - [failed] [desktop.bundles/firstpage/firstpage.bemjson.js] file-provider 22:08:27.375 - [rebuild] [desktop.bundles/index/index.bemjson.js] file-provider 22:08:27.384 - [isValid] [desktop.bundles/index/index.bemdecl.js] bemjson-to-bemdecl 22:08:27.401 - [failed] [desktop.bundles/firstpage/firstpage.bemdecl.js] bemjson-to-bemdecl 22:08:27.402 - [failed] [desktop.bundles/firstpage/firstpage.html] bemjson-to-html 22:08:27.403 - [failed] [desktop.bundles/firstpage/firstpage.deps.js] deps 22:08:27.458 - [rebuild] [desktop.bundles/firstpage/firstpage.levels] levels 22:08:27.458 - [rebuild] [desktop.bundles/index/index.levels] levels 22:08:27.459 - [failed] [desktop.bundles/firstpage/firstpage.files] files 22:08:27.464 - [isValid] [desktop.bundles/index/index.deps.js] deps 22:08:27.471 - build failed 22:08:27.472 - [failed] [desktop.bundles/firstpage/firstpage.bemhtml.bemdecl.js] deps-by-tech-to-bemdecl Error: file not found: /home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex/desktop.bundles/firstpage/firstpage.bemjson.js at /home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex/node_modules/enb/techs/file-provider.js:46:47 at Array.
(/home/alexander/DeveloperWorkspace/WEB_BEM_PHP_Yandex/node_modules/vow/lib/vow.js:712:56) at Immediate.callFns as _onImmediate at processImmediate as _immediateCallback
[failed] [desktop.bundles/firstpage/firstpage.bemjson.js] С одной стороны понятно, что мол нет структуры страницы описанной в bemhtml формате. С другой стороны непонятно - firstpage.bh.php разве не то же самое? Обязателен ли этот bemjson как отдельный файл несмотря на то, что я хочу делать проект на php?
[failed] [desktop.bundles/firstpage/firstpage.bemdecl.js] Очень плохо понимаю что это за файл и если не ошибаюсь он не обязателен для сборки проекта с 1-2 блоками и минимальной js функциональностью для них? Для php он нужен вообще?
[failed] [desktop.bundles/firstpage/firstpage.html] Зачем этот файл должен быть в проекте, если мы структуру описываем в bemjson и с помощью шаблонизаторов этот файл должен создаваться как раз таки из этого bemjson. Или я не прав?
[failed] [desktop.bundles/firstpage/firstpage.deps.js] Это я так понимаю как раз то что мне давно надо - привязывает блоки описанные в desktop.blocks к моей firstpage? Если верно понимаю описание технологии DEPS, то способ формирования страницы, который я пытаюсь реализовать с помощью bh-php является динамическим?
Всем привет. Хочу добавлять и переопределять стили в зависимости от платформы (desctop, touch-pad, touch-phone). Делаю так как описано в методологии https://ru.bem.info/method/filesystem/#Разделение-проекта-на-платформы Соответственно создал папки на файловой системе (desktop.blocks, touch-pad.blocks, touch-phone.blocks ) и в make.js добавил уровней:
levels = [
{ path: 'libs/bem-core/common.blocks', check: false },
{ path: 'libs/bem-core/desktop.blocks', check: false },
{ path: 'libs/bem-core/touch.blocks', check: false },
{ path: 'libs/bem-components/common.blocks', check: false },
{ path: 'libs/bem-components/desktop.blocks', check: false },
{ path: 'libs/bem-components/touch-pad.blocks', check: false },
{ path: 'libs/bem-components/touch-phone.blocks', check: false },
{ path: 'libs/bem-components/design/common.blocks', check: false },
{ path: 'libs/bem-components/design/desktop.blocks', check: false },
{ path: 'libs/bem-components/design/touch-pad.blocks', check: false },
{ path: 'libs/bem-components/design/touch-phone.blocks', check: false },
'common.blocks',
'desktop.blocks',
'touch-pad.blocks',
'touch-phone.blocks'
];
Далее создал тестовый блок с разными стилями для разного устройства. Меняю background-color. Ничего волшебного не происходит, стили просто перекрывают друг друга независимо от платформы. Все время цвет фона, прописанный в блоке touch-phone.blocks. Вопрос - каким образом происходит определение устройства или нужно писать свои функции для этого (проект на основе сборки project-stub)?
Всем привет!
Надо сверстать блок "О компании", вот кусок моего варианта реализации:
HTML:
<div class="about">
<div class="about-advantage">
<div class="about-advantage__item">
<div class="about-advantage__wrap">
<img class="about-advantage__img">
<p class="about-advantage__text"></p>
</div>
</div>
<div class="about-advantage__item">
<div class="about-advantage__wrap">
<img class="about-advantage__img">
<p class="about-advantage__text"></p>
</div>
</div>
</div>
</div>
SCSS:
.about{
&-advantage{
&__item{
}
&__img{
}
&__wrap{
}
&__text{
}
}
}
Вопросы:
- Как показать в имени блока то, что он является дочерним блоком? Его надо именовать как элемент
about__advantage? Или создавать миксabout__advantage about-advantage? about-advantage__itemиabout-advantage__wrapявляются элементами блокаabout__advantage, но в то же время содержат в себе другие элементы, а значит, они являются блоками - как их правильно именовать?
P.S. Буду очень рад примерам хорошей верстки :)
Всем привет!
Ребят, подскажите. Студия стала поддерживать проект на бэм инструментах. И недавно у клиента безопасники обрезали доступ к сторонним ресурсам. Т.е. теперь у них не работает jQuery. С ходу не удалось вникнуть, как подключается jQuery. Можно ли как-то локально это сделать? "Пропихнуть" в сам проект или разместить на их сервере и как-то ссылаться?
Есть необходимость сделать такой эффект https://medium.com/@mariusc23/hide-header-on-scroll-down-show-on-scroll-up-67bbaae9a78c#.rhhn4m1i6
И уже на этапе реализации просто зафиксированной шапке возникает вопрос, как ее зафиксировать если к блоку body нужно добавить padding-top? Получется, если я не захочу использовать залипшую шапку на другой странице у меня все равно у body будет отступ... Подскажите как сделать такой блок. Было бы идеально менять тип шапки, например вот так sticky : true. Спасибо.
Можно ли каскадом от модификатора изменять вложенные сущности?
Предположим, есть три одинаковые колонки, но элементы в средней колонке отличаются от элементов в крайних. Я могу каждому из этих элементов дать свой модификатор и получить то, что нужно:
https://jsfiddle.net/h9ms6moy/
А могу задать один модификатор самой колонке, и каскадом от него получить такой же результат:
https://jsfiddle.net/h9ms6moy/1/
Я где-то слышал, что последний вариант приемлем, правда, речь шла о каскаде от модификатора не элемента, а блока.
Противоречят ли такие приемы методологии?
Прошу обратить внимание, что в конкретном случае модификатор сам по себе не несет никаких стилей, а используется только для каскада.
Возможно ли использовать модификаторы для бандлов и стоит ли это делать?
Опишу проблему, которую хотелось бы решить. Кроме разделения на бандлы по платформам (desktop, mobile, tablet), страницы нужно сгруппировать логически (public, profile, admin). В итоге нужно будет собрать несколько мерджей (desktop -> public, desktop -> admin, desktop->profile, mobile->profile, mobile->public итд.)
Здравствуйте! Пытаюсь разобраться с БЭМ, в частности, сейчас пытаюсь понять, как правильно реализовать компоненты MDL в BEMJSON. Например, компонент tabs (ссылка). Если ориентироваться на семантику, лучше всего, наверное, как-то так:
{
block : 'tabs',
content : [
{
elem : 'tab',
name: 'Tab 1',
content : 'Tab 1 content'
}
]
}
Но в готовой вёрстке элементов у блока больше: для названий вкладок дополнительно есть mdl-tabs__tab-bar и mdl-tabs__tab. Можно создать эти элементы из поля name в шаблонизаторе, тогда получается, конечный пользователь ничего не должен знать о существовании этих элементов и их не надо добавлять в документацию. Так можно делать? Если нет, то как сделать лучше всего: неужели в BEMJSON должны быть все элементы, в т.ч. относящиеся к реализации?