Comments 20
habr.com/ru/company/skillfactory/blog/523130
Читайте (или листайте) Хабр!
Выгод здесь много. Например для смены темы сайта вам бы потребовалось перебивать стили в scss (писать селекторы и свойства, иногда более специфичные), а так достаточно перебить только значения переменных, без всяких специфичностей и селекторов если переменные глобальны.
Или например в ховерах у сложной структуры можно менять значение переменной, а не дублировать структуру для перебивки.
Ну и всегда лучше нативная поддержка, чем препроцессор.
Откуда вы взяли перевод "Автозавершение"?
Применение этих переменных конечно хорошая возможность, но даже не знаю кто сейчас пишет на чистом css, а по поводу перебить свойства спецыфичным селектором или поиск и замена в редакторе, так переменные тут не спасут, потому как если есть глобальная переменная например цвета, а потом она переопределена в какой-то кнопке, то всеравно ее нужно искать и менять в коде, что эквивалентно
1. Код можно разделить на несколько общих файлов куда вынести некоторый код(например _title.scss в котором будет основной код для всех заголовков) и тут найти и поправить что-то будет легче чем в общем 2-4к строчном файле по ctrl-F
2. Если не нужен какой-то блок кода, то просто не импортируешь этот файл, а не вырезаешь из общего, что исключает ошибки каких нибудь забытых скобок или точек с запятыми и дает возможность переиспользовать код по новому в разных проектах
3. Код лучше группирован, например
.btn {
display:inline-flex;
align-items:center;
justify-content:center;
&:hover {
opacity:.9;
}
&-primary {
background-color: blue;
color: white;
&:hover {background-color:lightblue;}
}
}
4. код не избыточен вендорными префиксами и его легче читать, поскольку они добавляются уже после сборки
5. Например в shopify есть поддержка scss из коробки
6. Для маленьких проектов(лендинги всякие, верстка email) да можно обойтись, но для больших лучше использовать препроцессоры, так как отладка происходит быстрее и например удаление большого куска кода = удалению одной строки импорта
7. Код всегда красиво отформатирован, потому как это делается после сборки, а не дергается каждый раз при включенном prettier
8. Собрать условно кастомный bootstrap только на css не получится, а вот выкинуть какие нибудь кнопки и т. д. можно отключив опять же импорты
Но соглашусь в одном — каждый выбирает писать код так как ему нравится или по правилам компании)
- developer.mozilla.org/en-US/docs/Web/CSS/@import
Плюс мне ничего не мешает разбить стили на сколько угодно файлов. Вообще не вижу в этом пункте какой-либо разницы - см п.1
- Код хуже группирован! Он зависим от вышестоящих правил. Чтобы что-то отредактировать, надо вначале проскроллить код, дабы убедиться что мы правим нужный селектор. Я уж молчу про правки «наживую» с помощью веб-инспектора. Слишком много зависимостей во всяких scss, чтобы без проблем править код на лету. Типовая задача — надо изменить какое-то свойство в зависимости от навешиваемого класса у родителя. И понеслась — надо закрывать блочную структуру правил и втискивать правило с классом родителя. Вся структуризация псу под хвост сразу.
Какую угодно группировку я вам легко и всякими табуляциями сделаю. - Вендорные префиксы сейчас практически неактуальны. За последние проектов 10, мне всего лишь один раз для Фокса пришлось что-то специфичное прописать. При этом они очень сильно захламляют код в том же веб-инспекторе
- Понятия не имею что это такое. Ну и «поддержка css из коробки» есть вообще у любой платформы веб-разработки))
- см п.1 Отладка происходит медленнее — несовпадение нумерации строк кода в веб-инспекторе и scss-файле. Плюс постоянно надо держать включенным dev-режим или запускать компилятор. В каком месте тут быстрее??? Я уж молчу, если компилятора под рукой просто нет
- Вы снова повторяетесь. Код забит всякими амперсандами...
- Всё, что можно сделать на препроцессорах — можно сделать и на css. Поскольку в итоге мы все равно имеем скомпилированный css-файл.
Мне пришлось написать и переписать кучу кода как на чистом css, так и на препроцессорах. Лично для меня практически без разницы с чем работать. Ну там первые пол часа надо привыкнуть, чтобы синтаксис вспомнился. Но если я буду писать что-то для себя — только на css. Это более поддерживаемо (код можно правит в любом текстовом редакторе, хоть с телефона). Более наглядно — не надо рыться и искать куда-то запихнутые миксины и т.п. Текущих возможностей современного css с лихвой хватает для того, чтобы не париться с компиляцией.
У меня достаточно большой опыт в верстке, у моих американских и израильских клиентов часто нужна поддержка ie10 и очень редко но и ie9 и всех остальных браузеров не самой последней версии, плюс нативный css import работает медленнее и не во всех браузерах поддерживается, на счет не совпадения строк(нужно использовать sourcemap и никаких проблем с этим нет). Предлагаю закончить эту дискуссию, поскольку мой способ работы, так как и Ваш не мешает нам зарабатывать на этих знаниях деньги
И спасибо за статью! Она великолепна!
А как насчет накладных расходов, том смысле, что браузеру нужно производить дополнительную обработку переменных. В случае препроцессоров эта нагрузка с клиентов снимается.
Понятно, что если нужно править дизайн из js, CSS-переменные все конкуренции, но что если это не требуется? Каков тогда урон производительности?
Не задал бы этот вопрос если бы не цитата в уважаемом MDN: "Данный метод также вызывает проблемы с производительностью. Он отображает страницу медленнее чем обычно, т.к. требует время на разбор" (ссылка).
CSS-переменные