Несколько советов less-разработчику

[@ReMaker]

Длинные цепочки селекторов утяжеляют файл стилей, затрудняют его чтение

Я думал что если использовать sass/less то нет необходимости читать скомпилированный файл.
А чтобы небыло соблазна что-нибудь там исправить компилирую в упакованом виде.

[@Carduelis]

Например, когда мы смотрим в инспектор хрома, файрбаг или иной другой инструмент, то каша из тегов

form.type#typeAddress table td.value b,
form.typeform#typeReview table td.value b,
form.type#typeAddress table td.title b,
form.typeform#typeReview table td.title b {
  color: #ccc;
}
form.type#typeAddress table td.value p,
form.typeform#typeReview table td.value p,
form.type#typeAddress table td.title p,
form.typeform#typeReview table td.title p {
  border-left: 0.25rem solid #ece;
}

… очень затруднит дебаг, особенно, если это чужой проект.
—
Разумеется, есть специальные расширения, например, для веб-инспектора, позволяющие понимать less

[@hell0w0rd]

source maps

[@tenbits]

Здесь даже не в чтении дело, а в производительности рэндеринга страницы. Мы взяли себе за правило — максимум 3 глубины вложенности и только «дети»:

.container {
   // styles

    > .sub { }
    > .foo {
         > .bar {}
    }
}

[@roman01la]

На самом деле браузеры справляются практически со всеми селекторами одинаково быстро, если конечно на странице не сотни тысяч элементов.

Минус длинных селекторов — это лишние килобайты кода.

[@tenbits]

На самом деле вы ошибаетесь. Есть огромная разница между '.foo .bar' и '.foo > .bar'. И первый вариант использовать нельзя — первое производительность, второе чрезмерное размытие контекста. Вот небольшой тест на jsperf. На «вебкитах» разница существенная. И это учитывая, что браузер лишь один элемент сопоставляет с одним селектором. И не сложно прикинуть, как картина будет выглядеть при рендеринге, когда будет просто сотни элементов и сотни селекторов.

[@roman01la]

Разница конечно есть, но на общем фоне это работает достаточно быстро. Я веду к тому, что мы часто, наблюдая разницу в производительности, зацикливаемся на этом не принимая во внимание общую производительность системы.

[@tenbits]

Согласен, Style Recalculation на фоне Script Evaluation / Parse HTML занимает довольно мало времени. (Ну по крайней мере, тот css который у нас в приложениях). Но уверяю вас, что если зацикливаться на таких вещах, то и вся система в целом будет производительной, отзывчивой и приятной. Из этого происходит стиль программиста — если он не обращает на такие вещи внимания, то зачастую и на многие другие также не будет обращать внимания. Собственно именно из этого возникают все разговоры, что вэб приложения, особенно под мобильные устроиства, «тормознутые». Мы видим совсем иную картину — оказывается можно писать быстрые и сложные мобильные вэб-приложения.

Архитектурный недостаток '.foo .bar' пока умолчим.

[@roman01la]

Смею предположить, сам не раз сталкивался, что на моб. устройствах веб-приложения чаще тормозят от длинных репеинтов, что вызвано неэффективным использованием некоторых CSS свойств. Перфекционизм — отличная черта для разработчика, но иногда мы готовы тратить часы на то, что в действительности, в свете производительности современного железа, уже не так важно ;) В любом случае длинные селекторы зло, по многим причинам.

[@Djamah]

А как по мне, то чтение затрудняется в самом лесс файле

[@tenbits]

++ использовать lesshat.

[@Sytrus]

Учите БЭМ

[@tbicr]

Я крайне не люблю вложенные правила из-за худшей читаемости. Можно поспорить когда блоки простые, но как правило блок нулевого уровня редко влазит в один экран.

[@twenty]

Ого, Less-разработчик! Так и до HTML-архитектора недалеко :)