Там написано, что это будет новый шрифт и он будет опубликован в скором времени. Но как минимум сейчас замечательный Fira Code (https://github.com/tonsky/FiraCode) умеет лигатуры.
Если вы про момент «ul > li, table td» — я также где-то в документации об этом читал, что в некоторых случаях это допустимо. Сейчас не могу найти. Если мне это вдруг показалось, поправьте меня. Или вы меня просто неправильно поняли? Смысл в том, что если я создаю блок-таблицу, в которой — я точно знаю — никаких других вложенных таблиц использоваться не будет, то будет избыточно навешивать на каждый tr и td дополнительный класс элемента, т.к. эти узлы уже связаны с родительским узлом, уже сами по себе семантичны, дополнительной семантики навешиванием класса не требуется. Возможно, это не суперстрого по суперстрогому БЭМ, но вполне допустимо при ручном применении БЭМ, о чем и была речь.
О типографике внутри блока докладчик также упоминает. Так в чем же не БЭМ?
Они не лезут вовне контейнера, но лезут внутрь, во вложенные контейнеры. Вы же можете использовать вложенные блоки (если использовать терминологию БЭМ). А что, если внутри этих блоков используются элементы с одинаковыми именами классов? Тогда CSS, примененный к элементу внешнего блока, будет влиять на элементы внутреннего блока, и вам придется бороться с этими стилями. Как вариант — использовать “>” в селекторе. Но тогда встает следующая проблема — если структура блока достаточно сложная, то вам придется использовать умопомрачительные конструкции типа > div > div > div > .element. Селекторы превращаются в жуть, и вы также завязываетесь на структуру блока. Модификация структуры блока будет означать необходимость внимательного и порой напряженного отслеживания отражения этой структуры в CSS.
С другой стороны, использование именования по БЭМ позволяет решить вышеописанную проблему изящным способом. У вас нет жуткой многоэтажной структуры селекторов, элементы вложенных блоков не влияют друг на друга, и бонусом — вы сразу видите, к какому блоку принадлежит данный элемент, когда, например, инспектируете страницу. А еще бонусом — ускорение рендеринга страницы (не нужно недооценивать — в некоторых сложных верстках весьма ощутимое).
Единственное, с чем я могу согласиться, что именование БЭМ выглядит довольно пугающе. Я решил лично для себя эту проблему тем, что именую блоки, элементы и модификаторы по-своему. Например:
Menu — блок;
Menu-item — элемент блока;
Menu--fixed — модификатор.
Я не использую bem-tools, а пишу код традиционно, поэтому для меня читабельные имена классов очень важны. И я пришел к такому компромиссу. Ну и в некоторых случаях действительно красивее и правильнее будет использовать просто вложенные селекторы — типа ul > li, table td и т.д., т.к. они не нуждаются в дополнительном именовании. Например, задавая типографику внутри контента статьи, да и порой в других случаях. Тут нужно смотреть по ситуации, без фанатизма.
Главное — понять, какие проблемы решает БЭМ и взять полезное из его методологии. Не нужно считать популярность БЭМа исключительно следствием продвижения его Яндексом и недооценивать сознательность использующих его разработчиков.
Не мной, а автором Vue. Я всего лишь перевел (так сказать, для полноты картины).
Я-то вообще «ровен» к разным библиотекам и ни в коем случае на агитирую за Vue и против Riot.
Спасибо за ваше дополнение. Лично я обязательно взгляну на Riot поближе.
Кстати, на сайте Vue есть сравнение и с Riot: vuejs.org/guide/faq.html.
По какой-то причине не вошло в перевод. Переведу:
Riot 2.0 предоставляет схожую модель, основанную на компонентах (в Riot они называются тегами — “tag”), с минимальным и прекрасно спроектированным API. Я думаю, что Riot и Vue разделяют многие архитектурные принципы. Тем не менее, несмотря на то, что Vue является чуть более «тяжелым», чем Riot, он также предлагает некоторые существенные преимущества:
Настоящий условный рендеринг (Riot выводит все “if” ветки и просто прячет / показывает их);
Значительно более мощный ротер (API роутинга, предоставляемый Riot, просто крайне минимальный);
Более зрелая поддержка инструментов (см. webpack + vue-loader);
Система «эффектов перехода» (transition effect) (Riot не имеет таковой);
Лучший статус поддержки (на 31 августа 2015 г. Riot имеет 25 открытых багов, в то время как у Vue их 0);
Лучшая производительность (Riot, по факту, использует скорее прямую проверку (dirty checking), чем virtual-dom, и потому страдает от тех же проблем с производительностью, что и Angular).
От себя могу добавить, что автор Vue действительно крайне оперативно реагирует на задачи. Как-то я написал ему о встреченном баге, и он буквально тут же его исправил.
По поводу других вариантов именования блоков, элементов и модификаторов:
ru.bem.info/method/naming-convention/#Альтернативные-схемы-именования
Если вы про момент «ul > li, table td» — я также где-то в документации об этом читал, что в некоторых случаях это допустимо. Сейчас не могу найти. Если мне это вдруг показалось, поправьте меня. Или вы меня просто неправильно поняли? Смысл в том, что если я создаю блок-таблицу, в которой — я точно знаю — никаких других вложенных таблиц использоваться не будет, то будет избыточно навешивать на каждый tr и td дополнительный класс элемента, т.к. эти узлы уже связаны с родительским узлом, уже сами по себе семантичны, дополнительной семантики навешиванием класса не требуется. Возможно, это не суперстрого по суперстрогому БЭМ, но вполне допустимо при ручном применении БЭМ, о чем и была речь.
О типографике внутри блока докладчик также упоминает. Так в чем же не БЭМ?
С другой стороны, использование именования по БЭМ позволяет решить вышеописанную проблему изящным способом. У вас нет жуткой многоэтажной структуры селекторов, элементы вложенных блоков не влияют друг на друга, и бонусом — вы сразу видите, к какому блоку принадлежит данный элемент, когда, например, инспектируете страницу. А еще бонусом — ускорение рендеринга страницы (не нужно недооценивать — в некоторых сложных верстках весьма ощутимое).
Единственное, с чем я могу согласиться, что именование БЭМ выглядит довольно пугающе. Я решил лично для себя эту проблему тем, что именую блоки, элементы и модификаторы по-своему. Например:
Menu — блок;
Menu-item — элемент блока;
Menu--fixed — модификатор.
Я не использую bem-tools, а пишу код традиционно, поэтому для меня читабельные имена классов очень важны. И я пришел к такому компромиссу. Ну и в некоторых случаях действительно красивее и правильнее будет использовать просто вложенные селекторы — типа ul > li, table td и т.д., т.к. они не нуждаются в дополнительном именовании. Например, задавая типографику внутри контента статьи, да и порой в других случаях. Тут нужно смотреть по ситуации, без фанатизма.
Главное — понять, какие проблемы решает БЭМ и взять полезное из его методологии. Не нужно считать популярность БЭМа исключительно следствием продвижения его Яндексом и недооценивать сознательность использующих его разработчиков.
Не мной, а автором Vue. Я всего лишь перевел (так сказать, для полноты картины).
Я-то вообще «ровен» к разным библиотекам и ни в коем случае на агитирую за Vue и против Riot.
Спасибо за ваше дополнение. Лично я обязательно взгляну на Riot поближе.
По какой-то причине не вошло в перевод. Переведу:
От себя могу добавить, что автор Vue действительно крайне оперативно реагирует на задачи. Как-то я написал ему о встреченном баге, и он буквально тут же его исправил.
Похоже, нигде в продаже ее уже нет, а хотелось бы.
Это очень здорово. Скоро во многих редакторах… :)
Бенчмарк от Taylor Otwell: taylorotwell.com/how-lumen-is-benchmarked