• Синтаксис или как правильно?

    vicodin
    @vicodin
    Имею некоторый опыт
    <div class="circular" v-bind:style="{ 'background-image': 'url(' + image + ')' }"></div>

    этот запрос было несложно ввести в поисковик
    Ответ написан
    Комментировать
  • Как сделать чтобы git не видел .idea?

    nazarpc
    @nazarpc
    Open Source enthusiast
    Папка .idea это ваше локальное окружение, оно в репозитории упоминаться не должно, не нужно его засовывать в .gitignore.
    Вот что нужно сделать:
    d4cbe31f7e4147a8ab3ae319c639fb93.pngedaf451152dd4a79b82e9d394b0da31f.png
    Ответ написан
    4 комментария
  • Как сделать чтобы git не видел .idea?

    27cm
    @27cm
    TODO: Написать статус
    Для начала удалите папку из git: git rm -r --cached .idea

    В .gitignore должно быть просто .idea/ без звёздочки. Пример.

    Кстати, для .gitignore в PhpStorm есть плагин.

    Если сделать, как посоветовал Назар Мокринский, то файлы будут игнориться только при работе с git через PhpStorm, что в общем-то серьёзное ограничение. Тогда уж лучше использовать .git/info/exclude, но все эти способы отказаться от gitignore, скажем так, не пользуются популярностью.
    Ответ написан
    2 комментария
  • В каком случаи использовать --save и --save-dev в NPM?

    k12th
    @k12th
    console.log(`You're pulling my leg, right?`);
    Компиляторы-транспиляторы-трансляторы (типа Coffee, LESS, Jade), тест-раннеры, стайл-чекеры и линтеры (mocha, chai, karma, (js|es)lint, jscs), плагины для таск-раннеров (grunt-contrib-watch, gulp-jade) — все это обычно ставится как --save-dev, потому что нужно только тем, кто контрибьютит в этот проект, работает с его кодом.

    Библиотеки и фреймворки (expressjs, jquery, backbone), на основе которых работает ваш код, без которых ваш код не запустится у его потребителя — ставятся как --save.
    Ответ написан
    3 комментария
  • Как поступать с тегами, которые генерируются БЭМ?

    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 — неплохо знать как сам вордпресс, так и методологию, и инструменты, которыми будете все это собирать.
    Ответ написан
    Комментировать