• Newtoo — разработка полноценного браузерного движка с нуля в 2018?
    +13
    Да дело даже не в любви, а просто для браузера визуальный рендеринг страниц — это тот основной функционал, ради которого всё и затевается. Если его нет (ну хоть в каком-то виде) — нет и браузера, есть только набор вспомогательных кирпичей.
  • Билайн отправляет детализацию разговоров посторонним людям
    0
    Я бы закрыл такой подозрительный аккаунт нафиг. Или нет, не закрыл бы, а просто положил в тумбочку и раз в полгода кидал на него 10 руб. А сам ушел бы на другой.
  • Как уйти на пенсию до 40 лет с миллионом долларов на счету в банке
    +2
    Поездки за грибами на еду или на продажу?
  • Вопросы на собеседовании, которые вы считаете глупыми. Но на самом деле нет
    +5
    Пингвин мне скажет: тут можно не тратить время.
  • Вопросы на собеседовании, которые вы считаете глупыми. Но на самом деле нет
    +4
    Количество талантливых людей минимум на порядок меньше, чем людей, которые считают себя талантливыми и ждут когда их оценят по достоинству.
  • Правильный планшет
    0
    У меня для десктопа староватая версия Adobe Reader, ещё до того, как в него вкрутили весь этот блекджек с социалками и облаками. Для андроида — гугловский вьюер.
  • Правильный планшет
    +1
    Когда-то Foxit был, топорненьким, но многообещающим продуктом. Сейчас это жирное и кривое страшилище, взявшее от продуктов Adobe все худшее и недобравшее лучшее.
  • BEM'a не должно существовать
    0
    Это слишком сложно для аудитории бутстрапа, несколько другой уровень мышления.
  • BEM'a не должно существовать
    0
    Блин. Цсс это технология или язык если угодно, бэм — методология наподобии архитектурного паттерна. Какие задачи решают паттерны?
  • Hourly, приложение для тайм-трекинга
    +1
    Видимо, если вам потом умножать время на рубли, дроби окажутся удобнее.
  • BEM'a не должно существовать
    +1
    Это очень абстрактное утверждение. В зависимости от условий узкие места могут меняться. В принципе я согласен, что на практике CSS не является узким местом почти никогда. Но потенциально может им быть.

    Там смысл был в том, что каскады влияли на скорость reflow.
    И если вдруг ваше веб-приложение так устроено, что reflow случается часто (а способов его вызвать довольно много) — это могло вылиться в ощутимые подлагивания.
  • BEM'a не должно существовать
    0
    Оно потом в зависимости от фреймворка либо к классам хэши припишет, либо на атрибуты с хешами завяжется. В девтулс потом всё это смотреть — в глазах рябит.
  • BEM'a не должно существовать
    0
    Каскад действительно работает медленнее классов без вложенности, яндексоиды публиковали тесты.
    Но реально заметную на глаз разницу это давало только на очень больших страницах — десятки тысяч узлов. В реальной жизни такие почти не встречаются.
    Но некоторая разница всё-таки есть, это факт.
  • BEM'a не должно существовать
    +5
    Это своего рода праздник непослушания. Толпы говнокодеров обрадовались, что они не одиноки в своем невежестве.
    Ведь автор реально невежда, как и множество его предшественников.
    На самом деле, я бы удовольствием отсыпал плюсов статье с серьезной критикой бэма и предложениями по его усовершенствованию/замене. Но таковых пока не видел.
    Все виденные мною «разоблачители» — это люди, которые просто ни черта не поняли в теме. И на самом деле они критикуют не сам бэм, а свои очень кривые его трактовки.
  • BEM'a не должно существовать
    0
    Никогда у меня такого не было. Обычно у элемента для каждого медиа-запроса переопределяется пара-тройка свойств, а то и вообще ноль. Элемент это ведь маленькая простая сущность, чему там меняться? Ну размер или отступ какой-то.
    Повторюсь: если там реально приходится писать 132 строки, нужна декомпозиция.
  • BEM'a не должно существовать
    0
    На тупой вопрос тупой ответ: это удобно.
  • BEM'a не должно существовать
    0
    Тег tbody может быть, а может не быть. Или вместо него может быть thead/tfoot. Вместо тэга td может быть th.
  • BEM'a не должно существовать
    0
    В реальной жизни лейаут не константа, он постоянно меняется — это аксиома. И любая сильно связанная система быстро вступит в противоречие сама с собой.
  • BEM'a не должно существовать
    +2
    Ага, уже проклюнулись первые зачатки бэма — modal блок, header элемент.
    Какими символами они при этом разделены, совершенно неважно, это вопрос договоренностей и вкуса. Вы на правильном пути. Осталось понять, а зачем во втором случае привязываться к body?
  • BEM'a не должно существовать
    –1
    У вас жуткая каша в голове.
  • Microsoft собирается радикально улучшить Skype
    0
    В мобильном приложении
  • BEM'a не должно существовать
    0
    Это было объяснено несчетное количество раз, но многие почему-то не понимают. Или не хотят понимать, что вероятнее. Очень кратко в стопиццотый раз. Пример утрированный, чтоб на пальцах.

    Есть страница, у неё есть шапка и подвал. Есть модальное окно, у него тоже есть шапка и подвал. Если написать так
    body header { ... }
    .modal header { ... }

    то стили глобального хедера применятся не только где надо, но и к хедеру модалки тоже. Ну потому модалка очевидно входит тоже входит в body.

    Но погодите! — скажет любой неофит, окончивший курс «Верстка за 24 часа» — ведь можно написать вот так:
    body > header { ... }
    .modal > header { ... }

    Можно, но только в идеальном мире, где html-структура делается один раз и навсегда. А в мире реальном она в ходе жизни проекта меняется много раз — доработки дизайна, функционала, багофиксы… Хотелки заказчика, дизайнера, сеошника… И частенько бывает нужно вставить промежуточную обертку. Или переподчинить узел другому родителю. Или сменить тэг. Или перенести что-то в другое место страницы.

    Каскад нужно во-первых переписывать, а во-вторых молиться, чтобы эти изменения не поломали что-то в совершенно другом месте. Поэтому часто никто этим не заморачивается, а просто херачит рядом перекрывающий более специфичный селектор. Очень скоро всё это дело выходит из-под контроля.
    При БЭМ-е доработки тоже понадобятся, но точечные.

    Не понимать побочных эффектов каскада может только либо полный новичок, либо верстальщик, всегда работавший по принципу «сверстал, отдал, забыл» — потому что для него страница статична, он никогда не видел что с ней происходит потом.
  • BEM'a не должно существовать
    +2
    Но собственно спецификация html задает тегам семантику. h1 — это тег заголовка. Бэмчики кладут на спецификацию и создают свой значит класс «desktop-header__title», для них он имеет значение, а сам тег html (h1) -нет.
    Семантика и стилизация это почти ортогональные вещи.
    Даже функционал ссылок симулируется с помощью div и javascript, ну что это такое?
    Тут вообще ловкая подмена понятий. Эмуляция ссылок через div+js — это одна из самых плохих практик, она всячески порицается, и к БЭМ-у имеет отношение… правильно, никакое.
  • BEM'a не должно существовать
    0
    Преимуществ несколько, но все их собирательно можно обозначить как «общие множители полезно выносить за скобку»
  • BEM'a не должно существовать
    +2
    Никаких проблем. Компоновать стили надо по смыслу, а не по технологиям.
    Если у меня есть блок, то я хочу видеть его поведение сразу и полностью, а не ползать по нескольким файлам, сравнивая их построчно.
  • BEM'a не должно существовать
    +1
    Нет, медиа именно так и нужно писать, а за отдельные файлы бить по рукам.
    Кого беспокоят лишние байты — есть специальные плагины для сборщиков, которые вытянут и скомпонуют.
  • BEM'a не должно существовать
    +1
    И как следствие: распутывать каскады и делать в них правки выходит настолько муторно, что каждое поколение разрабов идет по пути наименьшего сопротивления и лепит быстрые перекрывающие заплатки с еще более длинными каскадами и импортантами. Да и менеджмент подстегивает — надо поскорее. Со временем эти говнофиксы копятся и копятся, наслаиваются и наслаиваются… Я лично встречал каскады в 6-8 ступеней.
    И в какой-то момент наступает понимание, что это необратимо — даже если я и хочу сделать всё правильно, я уже не могу. Там такие авгиевы конюшни, что разгрести его не представляется возможным, только сжечь. И даже самый добросовестный разработчик смиряется и просто плывёт по течению.
  • BEM'a не должно существовать
    0
    Сейчас вам расскажут, что новый человек не знаком с файловой структурой проекта, поэтому он сделает файл-дубликат в отдельной папке.
    Любую систему можно сломать при должном уровне криворучия.
  • BEM'a не должно существовать
    +2
    Бутстрап это пример очень таксебешного кода.
    Не потому, что его пишут глупые люди, а потому что он:
    а) ориентирован на нишу верстального фаст-фуда (я не хочу думать, я хочу фигачить тэги);
    б) тянет на себе легаси-концепции из прошлого десятилетия.
  • BEM'a не должно существовать
    0
    Элемент на 100 строк тоже требует декомпозиции. Скорее всего, он вполне потянет на отдельный блок. У меня стили для одного элемента обычно не превышают 20-30 строк.
  • BEM'a не должно существовать
    +2
    Если там несколько раз по 500 строк, блоку совершенно точно требуется декомпозиция.
    Я бы начал задумываться о декомпозиции уже после ~100-150 строк суммарно на весь блок, включая все элементы и модификаторы.
  • BEM'a не должно существовать
    0
    Вероятность такой проблемы есть всегда.
    Но если она случается, при использовании БЭМ-а она сравнительно легко решается, потому что блоки независимы — где-то что-то переименовали, и оно дальше работает. Просто небольшой рефакторинг, нормальный рабочий процесс.
    А вот если там было месиво из многоступенчатых каскадов, да размазанных по разным файлам… Удачи в отладке :)
  • BEM'a не должно существовать
    0
    У вас несколько разных и при этом равноправных каталогов? Допустим.
    Но тогда вы их как-то различаете? Условно говоря, один будет primary-catalog, другой secondary-catalog. Соответственно получаем .primary-catalog-products-list.
    Или может один будет promo-catalog или ещё как-то. Ноги обычно растут из бизнес-логики, никакие имена классов не выковыриваются из носа.
  • BEM'a не должно существовать
    +1
    Эта проблема ортогональна БЭМ-у, она возникает (и довольно легко решается) при любой методологии.
    Решение: запрещено использовать имена блоков, состоящие из одного слова, потому что однословные имена всегда слишком общие и расплывчатые.

    Ну назову я список .products (товары) и что? У меня товары есть в каталоге, в корзине, в вишлисте, в инвойсе, в истории заказов…
    Другой пример: блок .header — сразу признак малоопытного верстальщика. Хедер может быть у страницы, у статьи, у сайдбара, у модалки, у чего угодно. Это камешек в огород тех чудаков, которые думают, что семантические тэги header или nav решат все их проблемы.

    Помимо принадлежности к странице, еще нужно различать группы товаров и собственно товары.

    Поэтому в 99% случаев имя блока состоит из 2-3 слов. 4 слова и более уже многовато и используется только изредка.

    .catalog-products-list — список товаров в каталоге
    .catalog-products-list__item — элемент списка, отвечающий за позиционирование вложенного блока
    .catalog-products-item — отдельный товар (каждый блок знает только собственное устройство, но ничего не знает о своем позиционировании)
    .catalog-products-item__title — заголовок товара и так далее

    Предвижу возражения.

    1. Это же так длинно и нечитабельно!
    Да, длинновато. Нет, вполне читабельно. К длине классов быстро привыкаешь и вскоре именно они становятся очень удобны и информативны. Прочитал и сразу все понятно. А не ползанаешь по дев-тулс в попытках понять, из какого каскада класс .list подхватил это свойство…

    2. Почему не использовать модификаторы?
    Типа вместо .catalog-products-list не написать .products-list--catalog.
    Иногда можно. Но вообще модификаторы предназначены для смены декора, а семантически и по конструкции блок должен быть один и тот же. В нашем примере список товаров в каталоге и корзине существенно отличаются по всем показателям.
  • BEM'a не должно существовать
    +1
    Нет, скорость они называли как один из факторов, но не основной.
    Найдите и посмотрите видео Харисова, он подробно рассказывал откуда, как и почему появился БЭМ.
  • Microsoft собирается радикально улучшить Skype
    0
    Один-единственный недостаток, но увы принципиальный — это невозможно.
    Количество комбинаций таких хотелок устремится к бесконечности, их невозможно учесть, просчитать и отладить.
  • Microsoft собирается радикально улучшить Skype
    0
    Частные настройки (цветовая тема или размер шрифта, например) вполне возможны. Или выбор из 2-3 фиксированных режимов лейаута — тоже могут быть. Ключевое слово тут «фиксированных» — то есть таких, которые спроектированы дизайнером и контролируемы разработчиками.

    Скины (то есть полная перелицовка внешнего вида в свободной форме) — нет. Это огромный источник гемора и выхлоп от них незначителен. Вспоминая тот же Винамп — к нему существовали сотни, тысячи скинов, но приемлемых среди них было наверное 1%, а всё остальное колхозные поделки в стиле «я у мамы фаташопир».
  • Microsoft собирается радикально улучшить Skype
    0
    Вот именно — выбирать из имеющихся вариантов и как-то компоновать их.
    А не прийти в магазин и сказать: мне вот эти самые ботинки, только каблук на 2 см выше, вместо кожи я хочу замшу, шнурки вместо 5 дырок на 7 и чтоб по канту узор в виде меандра… А в остальном всё как есть, я просто под себя ваш продукт настроил.
  • BEM'a не должно существовать
    +13
    Прочитав заголовок, я подумал, что внутри будет одно из двух. С вероятностью 95% это очередной горе-разоблачитель, который рассматривает БЭМ как набор чьих-то странных прихотей и совершенно не понимает, почему он устроен именно так и какие проблемы призван решать. Ну и с вероятностью 5% я узнаю какую-то новую, крутую, интересую идею. К сожалению, теорвер не подвел.

    Многолетний опыт верстки мне говорит: БЭМ не идеален, но это лучшее из имеющегося. Никакая другая методология не выдерживает конкуренции с ним на практике. (Единственное исключение — css-in-js, но это игрок с несколько другого поля). Существенно лучше него может быть только радикальная переделка всего стандарта CSS, с блекджеком и неймспейсами.
    Ценой некоторой многословности он решает огромную кучу проблем.
    Каскад БЭМ не отрицает, а лишь призывает к ограниченному его применению. Изобретался каскад в древние времена, когда сайты были на порядок проще, а сейчас условия изменились — вылезли на поверхность побочные эффекты.
    Препроцессоры он тоже не отрицает, а наоборот прекрасно с ними сотрудничает.
    Остальное даже комментировать нечего.
    Короче, учиться и ещё раз учиться.
  • Microsoft собирается радикально улучшить Skype
    +17
    Честно говоря, возможность кастомизации в том виде, каком вы ее описываете (а ля винамп), выглядит признаком школотронской софтины. Школотронской в смысле целевой аудитории. Серьезному приложению это не нужно, потому что а) не нужно, никто не будет этим заниматься, некогда б) лишний огромный источник багов.
    Просто UI должен быть хорошо проработан и отполирован. Кастомизаторская чесотка — она знаете ли, не на пустом месте возникает, а от плохих UI.
    Настройка UI должна ограничиваться сменой темы (светлая/темная, как у телеграма или хабра) и расположением/отключением кнопок на тулбаре (бразеры, офис и пр).