Ответы пользователя по тегу CSS
  • Как организовать файлы в библиотеке компонентов?

    qfox
    @qfox
    Ответы есть у меня
    У нас есть блок "Кнопка", у нее есть дочерний элемент "Кнопка__иконка" и модификатор "Кнопка--Иконка-Слева"(уменьшает отступ слева, чтоб иконка смотрелась лучше).
    У этой кнопки есть три модификатора размера (sm,m,l). У каждого размера будет разный отступ слева при модификаторе "Кнопка--Иконка-Слева".


    Легко решается через CSS Custom Properties и типографские константы
    --sm, --m, --l при этом выставляют эти константы, а другие модификаторы и элементы их используют в нужных им местах.

    Добавим изменение размера "Кнопка__иконка" для разных размеров кнопки (если это иконочный шрифт можно использовать font-size всей кнопки, но мы как современные используем svg иконки и размер нужно задавать вручную).


    Лучше делать враппер над иконкой, чтобы не завязываться на svg или нет.
    Если библиотека компонент общая — ситуации могут быть разные.
    Такая структура более менее:
    <Button>
      <Button__icon><Icon ... /></Button__icon>
      <Button__body>Текст на кнопке</Button__body>
    </Button>


    Если иконка есть — выводим `Button__icon`, если нет — не выводим. Стили вешаем на `Button__icon`.

    Для кастомизации — оставляем `Button__body`, потом пригодится в кастомных `Select`.

    В идеале нужна структура, чтоб видеть все связи (пример выше), для быстрого доступа к нужному свойству, но также инструмент, который умеет удалять не нужные стили по связям. Удалив элемент "Кнопка__иконка" в сборку не должны попасть модификаторы "Кнопка--Иконка-Слева" разных размеров.

    Может кто то встречался с решением или рекомендациями по данному вопросу.


    Звучит как сборка стилей по зависимостям из bemjson/jsx. Технически, есть возможность даже из html получить bemjson и инициировать для него сборку css/js.
    Процесс будет выглядеть примерно так:
    const fs = require('fs');
    const miss = require('mississippi');
    const html2bemjson = require('html2bemjson');
    const bemjsonToDecl = require('bemjson-to-decl');
    const src = require('gulp-bem-src');
    const gconcat = require('gulp-concat');
    const vfs = require('vinyl-fs');
    
    src(
        ['path/to/blocks'],
        bemjsonToDecl.convert(
            html2bemjson(
                String(fs.readFileSync('path/to/your.html')))),
        'css',
        { // дополнительные настройки
            skipResolvingDependencies: false, // отключаем зависимости
            {
                'path/to/blocks': { scheme: 'nested' } // у 'path/to/blocks' схема nested 
            }
        }
    ).pipe(gconcat('path/to/your.css')).pipe(vfs.dest('.'))

    Ну и всё
    Ответ написан
    3 комментария
  • Как сочетать BEM и динамический контент?

    qfox
    @qfox
    Ответы есть у меня
    У вас здесь 2 проблемы:
    • нужны ли классы для динамического контента;
    • как, если нужно, модифицировать структуру динамического контента.

    Проблема структуры не относится к BEM, она относится к семантике и SEO.

    Если же не смотреть на структуру и тэги (использовать ли small внутри или span, заворчивать ли в article) — то вопрос в сущности нужны ли классы на динамическом контенте или нет. Учитывая, что контент динамический, и нет необходимости иметь классы на тэгах, то допустимо сделать каскад на тэги от некоторого блока: например, dynamic-content или content, text.

    Почему именно теги? Потому что WYSIWYG по умолчанию генерирует теги. Но вы можете использовать какие-то доп. инструменты, которые подправят итоговый html, расставят классы и т.д. (например, с помощью инструментов типа https://github.com/posthtml/posthtml ).

    При необходимости можно дополнительно пометить стили тегов классами.

    <div class="text">
      <h1>Caption <small>Some Foo Bar</small></h1>
      <article>
        <p>Lorem ipsum...</p>
        <div class="text__p">Dolor sit...</div>
      </article>
    </div>


    .text h1, .text__title { /* main title styles */ }
    .text h1>small, .text__sub-title { /* sub-title styles */ }
    .text p, .text__p { /* paragraph styles */ }


    Таким образом вы инкапсулируете все пользовательские стили в одном месте (одном блоке) и не имеете проблем с созданием контента.
    Ответ написан
    2 комментария
  • Правильно ли так использовать модификатор?

    qfox
    @qfox
    Ответы есть у меня
    Да, вполне рабочий вариант.
    Ответ написан
    Комментировать
  • Как разрабатывать при помощи bem-core и bem-tools?

    qfox
    @qfox
    Ответы есть у меня
    Самый простой способ — это склонировать https://github.com/bem/project-stub через git, удалить папку .git, установить node, зависимости (npm install), и начать работать над проектом.

    Чуть сложнее в настройке, но тоже простой — использовать yo и bem-stub, для этого нужно установить ноду, эти два пакета: npm -g install yo generator-bem-stub; и далее в новой папке можно будет запустить yo bem-stub, поотвечать на вопросы, и проект сгенерируется.

    Важно понимать, что bem server скоро начнет внутри использовать enb, так что можно уже сейчас на него переходить и использовать enb server.

    А вообще, на такие вопросы очень быстро можно получить ответ на bem.info и форуме. ;-)
    Ответ написан
    Комментировать
  • Как сместить target index в jcarousel с первого слайда на второй?

    qfox
    @qfox
    Ответы есть у меня
    Насколько я понимаю, проще всего подписаться на событие изменения таргета и выставлять свой класс на следующий после таргета элемент. Либо же какие-то другие события посмотреть.
    Я бы читал код и документацию.

    Не очень тянет на вменяемый ответ, но уж коль ничего другого нет ;-)
    Ответ написан
  • Существует ли в природе подобный слайдер?

    qfox
    @qfox
    Ответы есть у меня
    Имхо, это все css3, js тут мало играет.

    Делаете прямоугольный «слайдер», который загибаете, а его элементы наоборот разгибаете. При наличии какого-то класса сдвигаете, опять же, css3 свойствами и ставите нужную прозрачность (или меняете картинку), тени.

    Вариант 2: svg. В этом случае, делаете inline svg, с нужной формой элементов, классы там тоже поддерживаются и при наличии класса active на элементе двигаете его вниз и меняете прозрачность.
    Ответ написан
  • Какие есть методологии верстки независимыми блоками?

    qfox
    @qfox
    Ответы есть у меня
    Инлайн стили это одно, а скрипты это другое, бэм собирает все вместе, и еще и html туда же при помощи i-bem.js

    Примеры — многие проекты яндекса, часть мейл.ру, ну megafon.ru респонсив часть ;-) А вообще уже достаточно много сайтов на бем переходят.
    Ответ написан
    Комментировать
  • В чем разница в подходах к проектированию страниц между БЭМ и GWT?

    qfox
    @qfox
    Ответы есть у меня
    Наверное тем, что в 2006 году никто не думал, как далеко зайдет веб.
    html vs bemhtml+bemjson, т.е. декларативная шаблонизация. Если чтото похожее есть в GWT (типа не html, а xslt, и на входе xml с данными), то в этом плане практически тоже не отличаются, просто осевременно и работает быстрее (xjst+json).
    В БЭМ-блоке вы можете складывать какой-то серверный функционал, документацию, и много чего еще — как с этим у GWT?
    Примешивания блоков — как с этим?
    Нативная поддержка js (как серверного так и браузерного) ?
    i-bem.js ?

    Думаю, половины из этого точно нет в GWT, но корни явно схожие, спасибо за освежение в памяти этого троебучия.

    Ну и самое главное, что это обсуждение разницы в инструментах, где у GWT застолблена поляна очень давно. А BEM себя позиционирует в первую очередь как методология, а не фреймворк.
    Ответ написан
    Комментировать
  • Как поступать с тегами, которые генерируются БЭМ?

    qfox
    @qfox
    Ответы есть у меня
    Че-то второй вопрос по бэм и опять 3 подвопроса.

    (1) Поступать с тегами нужно нежно. Лучше всего, если хотите бэм в вордпрессе, поискать готовые плагины/темы, на базе которых делать свое. В контенте без языков разметки бэму делать нечего, ибо это неудобно руками писать. В этом случае удобнее всего завернуть все в некий блок user-content, которому прописать стили для всех каскадов — таким образом у вас получится наибольшая польза от бэм с наименьшим кол-вом проблем от классического подхода. Т.е. вы все эти проблемы локализуете внутри блока user-content, все остальное будет стабильнее, в зависимости от навыков.

    (2). Обертки это немножко другое, чем то, что вы хотите. Для центровки всех элементов можно родительскому блоку пользовательского контента user-content, в который вставляется то, что приходит из админки, выставить text-align: center, и оно разойдется по всем дочерним. А вообще, если такое нужно не везде, то лучше сделать соотв. модификатор или элемент, который можно будет навешивать на тэги контента. Имя блока можно сократить до uc, например: user-content_align_center или uc_align_center, или uc__centered (если использовать, как подмешанный элемент).

    (3) Про вложенные блоки есть такая идея: создаете модификатор _level_N, или depth_K, где N, К — натуральные числа, этим модификаторам задаёте нужные цвета текста. Родительскому блоку по умолчанию выставляете тот самый одинаковый цвет. Профит.
    Про дублирование стилей 7 раз — не очень понимаю, если у вас будет один и тот же блок — просто навешиваете его и нет проблем, если разные — цвета прописываете в модификаторах.
    Кроме прочего, есть csso, который оптимизирует все это богатство и ужаса никакого не будет.
    Кроме прочего, задача какая-то вымученная, потому что color по стандарту передается в дочерние элементы, и его будет достаточно прописать в style="color: red" родительской ноды.
    Независимыми должны быть блоки, а не ноды. Разница между ними такая же, как между классом и объектом, или как между схемой и таблицей, или как между трафаретом и надписью им сделанной, и т.д. Одно — правила, второе — результат. Один и тот же блок может быть навешан на 50 хтмл нодах (тэгах), и все они будут иметь похожее или одинаковое поведение и отображение.
    Например, есть у вас на сайте яндекс.карты, а в них 100 меток, все эти метки разные, но в чем-то сходятся, например, у них одинаковые или похожие стили, а при клике на любой из них выводится попап, в котором разные данные. Так вот метка и попап — это одни блоки, а данные в попапах будут в других блоках. И стили, скрипты про вид метки и про открытие попапа мы описываем в одном месте единожды, сам попап в другом месте и тоже единожды, а когда будем выводить эти данные — это уже будет контент и там уже мы будем выводить многократно один и тот же класс (название блока) в разные дом ноды (тэги).
    В различных инструментах (bem-tools/enb) есть удобные шаблонизаторы как раз для автоматической генерации таких деревьев дом нод, чтобы было меньше путаницы: bemhtml, bh. Кроме того, такой подход позволяет генерировать шаблоны для сборки на клиенте в браузере. Но чтобы интегрировать все вместе — нужно разобраться. А чтобы еще и использовать с wordpress — неплохо знать как сам вордпресс, так и методологию, и инструменты, которыми будете все это собирать.
    Ответ написан
    Комментировать
  • Именование классов в БЭМ

    qfox
    @qfox
    Ответы есть у меня
    daydiff все верно заметил. Немного дополню.
    (1) — При чем вы можете обернуть как элемент в блок, так и блок в элемент. Проще первое, т.е. .menu>.menu__content, но возможно и наоборот. Методология ничего не запрещает, но частенько крайне интенсивно рекомендует, поскольку её разработчики собаку много на чем съели.
    С другой стороны, я не понимаю почему вам придется переписывать css? Даже если добавите какой-то враппер элемент, который пойдет внутри блока на всю его ширину/высоту, то допишите стили чисто для него, в крайнем случае перенесите ему стили блока, а блоку допишите нужные.

    (2) — Чтобы не было пересечений между элементами разных блоков и состояниями разных элементов/блоков, на которые кто-то захочет повесить js обработчики или стили.

    (3) — Если сборка страниц/бандов делается инструментами, то в папке блока рядом с остальными: blockname.ie*.css. Если руками — то как удобнее, сложно знать ваше окружение.
    Ответ написан
    Комментировать
  • Вопрос верстальщикам. Плюсы и минусы, вёрстка vs. изображение

    qfox
    @qfox
    Ответы есть у меня
    Странно, что никто не сказал про рендеринг.
    Всякие CSS3 фишки весят меньше, но рисуются на клиенте. И каждая перерисовка будет заставлять браузер перерисовывать и эти ваши модные штуки. Таким образом, скорость работы сайта, перегруженного css3 может быть заметна глазу на слабых машинках — это уже не хорошо.
    С другой стороны, как уже много говорили, перекрасить картинку — автоматически крайне сложно, иногда нереально, а перекрасить css3 — не сложнее, чем скушать печеньку.
    Нужно искать золотую середину. Не использовать новомодные штуки там, где они не нужны, и стараться использовать там, где будет полезно, даже если для ie6/7/8/9 придется делать отдельные стили. Их все равно придется делать отдельно.
    Ответ написан
    3 комментария