Комментарии 14
Длинные цепочки селекторов утяжеляют файл стилей, затрудняют его чтение
Я думал что если использовать sass/less то нет необходимости читать скомпилированный файл.
А чтобы небыло соблазна что-нибудь там исправить компилирую в упакованом виде.
Например, когда мы смотрим в инспектор хрома, файрбаг или иной другой инструмент, то каша из тегов
… очень затруднит дебаг, особенно, если это чужой проект.
—
Разумеется, есть специальные расширения, например, для веб-инспектора, позволяющие понимать less
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
Здесь даже не в чтении дело, а в производительности рэндеринга страницы. Мы взяли себе за правило — максимум 3 глубины вложенности и только «дети»:
.container {
// styles
> .sub { }
> .foo {
> .bar {}
}
}
На самом деле браузеры справляются практически со всеми селекторами одинаково быстро, если конечно на странице не сотни тысяч элементов.
Минус длинных селекторов — это лишние килобайты кода.
Минус длинных селекторов — это лишние килобайты кода.
На самом деле вы ошибаетесь. Есть огромная разница между
'.foo .bar' и '.foo > .bar'. И первый вариант использовать нельзя — первое производительность, второе чрезмерное размытие контекста. Вот небольшой тест на jsperf. На «вебкитах» разница существенная. И это учитывая, что браузер лишь один элемент сопоставляет с одним селектором. И не сложно прикинуть, как картина будет выглядеть при рендеринге, когда будет просто сотни элементов и сотни селекторов.Разница конечно есть, но на общем фоне это работает достаточно быстро. Я веду к тому, что мы часто, наблюдая разницу в производительности, зацикливаемся на этом не принимая во внимание общую производительность системы.
Согласен,
Архитектурный недостаток
Style Recalculation на фоне Script Evaluation / Parse HTML занимает довольно мало времени. (Ну по крайней мере, тот css который у нас в приложениях). Но уверяю вас, что если зацикливаться на таких вещах, то и вся система в целом будет производительной, отзывчивой и приятной. Из этого происходит стиль программиста — если он не обращает на такие вещи внимания, то зачастую и на многие другие также не будет обращать внимания. Собственно именно из этого возникают все разговоры, что вэб приложения, особенно под мобильные устроиства, «тормознутые». Мы видим совсем иную картину — оказывается можно писать быстрые и сложные мобильные вэб-приложения.Архитектурный недостаток
'.foo .bar' пока умолчим.Смею предположить, сам не раз сталкивался, что на моб. устройствах веб-приложения чаще тормозят от длинных репеинтов, что вызвано неэффективным использованием некоторых CSS свойств. Перфекционизм — отличная черта для разработчика, но иногда мы готовы тратить часы на то, что в действительности, в свете производительности современного железа, уже не так важно ;) В любом случае длинные селекторы зло, по многим причинам.
А как по мне, то чтение затрудняется в самом лесс файле
++ использовать lesshat.
Учите БЭМ
Я крайне не люблю вложенные правила из-за худшей читаемости. Можно поспорить когда блоки простые, но как правило блок нулевого уровня редко влазит в один экран.
Ого, Less-разработчик! Так и до HTML-архитектора недалеко :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько советов less-разработчику