Пишем CSS лучше и красивее / forpes.ru

Главная
Пишем CSS лучше и красивее

Пишем CSS лучше и красивее +6

03.08.2018 06:05

alconost 27 7200 Источник

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

Когда при разработке приложений приходилось браться за CSS, это была не самая радостная часть работы. Но ее ведь не избежать, верно? Сегодня порадовать пользователя дизайном приложения настолько важно, что без CSS — никак.

Когда проект только начинается, все идет хорошо. У вас всего пару селекторов: .title, input, #app — проще простого.

Но постепенно приложение разрастается, и заглядывать в CSS становится страшновато: во всех этих селекторах разобраться уже не так просто. Вы начинаете писать что-то вроде div#app .list li.item a, какие-то куски кода повторяются снова и снова, а всю свою писанину сваливаете в конец файла: вам уже плевать, потому что CSS — отстой. Итог — 500 строк CSS-кода, поддерживать который невозможно.

Это я, когда сражаюсь с CSS

Переведено в Alconost

Моя задача сегодня — научить вас писать CSS лучше. Я хочу, чтобы, взглянув на старые проекты, вы подумали: «О боги! Как можно было написать такое?»

А как же CSS-фреймворки? — спросите вы. Они ведь для этого и придуманы — писать хороший CSS-код.

Правильно. Но у них есть недостатки:

Дизайн на выходе часто получается скучный.
Бывает сложно сделать нужные настройки или выйти за рамки возможностей фреймворка.
Чтобы пользоваться фреймворками, сначала нужно их изучить.

Ну и вы же читаете эту статью — значит, есть причина, правда? Итак, без лишних слов — вперед, научимся писать CSS лучше.

Примечание. Это статья не о том, как создавать красивые приложения, а о том, как писать поддерживаемый CSS-код и как его упорядочить.

SCSS

В примерах я буду использовать SCSS.

SCSS — это препроцессор CSS, по сути — надмножество CSS, которое добавляет некоторые классные возможности, например, переменные, вложенность, импорт и примеси («миксины»).

Далее я расскажу, какие возможности мы будем использовать здесь.

Переменные

В SCSS есть переменные, и основное их преимущество — повторное использование. Предположим, у вас есть палитра цветов для приложения, и основной цвет — синий.

Поэтому синий у вас везде: фон background-color кнопок, цвет color заголовков, ссылок. СИНИЙ — ПОВСЮДУ.

И вдруг синий вам разонравился. Новый фаворит — зеленый.

Если вы не использовали переменные, придется изменять все строки, в которых стоит синий.
А с переменными достаточно изменить значение одной из них.

// Объявление переменной
$primary-color: #0099ff;
// Ссылка на переменную
h1 {
 color: $primary-color:
}

Вложенность

В SCSS можно использовать вложенность. Поэтому из фрагмента

h1 {
 font-size: 5rem;
 color: blue;
}
h1 span {
 color: green;
}

можно сделать такой код:

h1 {
 font-size: 5rem;
 color: blue;

 span {
   color: green;
 }
}

Последнее читается лучше, правда? Вложенность позволяет меньше времени тратить на написание сложных селекторов.

Импорт и частичные файлы

Если нужно обеспечить поддерживаемость и удобочитаемость, хранить весь код в одном огромном файле — плохая идея. Если вы экспериментируете или пишете небольшое приложение, это еще терпимо, но на профессиональном уровне… даже не пытайтесь. К счастью для нас, SCSS решает эту проблему.

Мы можем создавать «частичные файлы» — у которых имя начинается с символа подчеркивания: _animations.scss, _base.scss, _variables.scss и так далее.

Для их импорта используется соответствующая директива: @import. Например, можно сделать так:

// _animations.scss @keyframes appear { 0% { opacity: 0; } 100% { opacity: 1; } } // header.scss @import "animations"; h1 { animation: appear 0.5s ease-out; }

Вы могли подумать: «Ага! У него здесь ошибка! Нужно писать _animations.scss, а не animations».

Не-а. SCSS достаточно умен, чтобы понять, что в этом случае речь идет о частичном файле.

Это все, что нам нужно знать о переменных, вложенности, частичных файлах и импорте. У SCSS есть и другие возможности — примеси, наследование и различные директивы (@for, @if, …), но их я затрагивать здесь не буду.

Если вам интересно — почитайте документацию: она достаточно понятно и хорошо написана.

Упорядочивание CSS-кода: методология БЭМ

Я бесчисленное множество раз использовал общие названия для CSS-классов. Ну, вы знаете: .button .page-1 .page-2 .custom-input.

Часто мы понятия не имеем, какое имя выбрать — хотя именование это важная задача. Представьте, что вы начали писать приложение, а затем решили отложить это дело на несколько месяцев — или, что еще хуже, кто-то взял ваш проект на себя. Если не продумать именование в CSS-коде, будет сложно сходу понять, что имеется в виду в конкретной строчке.

БЭМ помогает решить эту проблему. БЭМ — это соглашение об именовании; расшифровывается как блок, элемент, модификатор.

Эта методология поможет структурировать код, сделать его более модульным и упростить повторное использование. Разберемся, что же значат «блок», «элемент» и «модификатор».

Блоки

Блок можно представить себе как компонент. Возьмем, к примеру, конструктор Lego.

Как из конструктора сделать простой дом? Понадобятся окно, крыша, дверь, пару стен — и всё. Как раз это и есть наши блоки — они несут смысл сами по себе.

Именование: название блока: .block
Примеры: .card, .form, .post, .user-navigation

Элементы

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

Именование: название блока + __ + название элемента: .block__element
Примеры: .post__author, .post__date, .post__text

Модификаторы

Итак, мы сделали какое-то окно. Теперь нам понадобилось зеленое или, например, маленькое окно. Это будут наши модификаторы. Они представляют собой флаги на блоках и элементах, которые используются для изменения поведения, внешнего вида и т. д.

Именование: название блока ИЛИ элемента + -- + название модификатора: .block__element--modifier, .block--modifier
Примеры: .post--important, .post__btn--disabled

Примечания

БЭМ подразумевает именование классов и только классов. Не идентификаторов и не тегов — только классов.
Блоки и элементы могут вкладываться в другие блоки и элементы, но они должны быть полностью независимыми. Обязательно независимыми. Поэтому не нужно добавлять кнопке поля, чтобы она была под заголовком, иначе она будет привязана к заголовку. Лучше использовать вспомогательные классы.
Да, HTML-файл будет перегружен, но это не страшно: преимущества БЭМ перевешивают этот недостаток.

Пример

Небольшое упражнение для читателей. Походите по сайтам, на которых вы часто бываете, и подумайте, какие там могли бы быть блоки, элементы и модификаторы.

Например, такую картину я могу вообразить в магазине Google:

Теперь ваша очередь. Проявите любопытство и подумайте, что можно было бы сделать лучше. И конечно, чтобы совершенствовать собственные навыки, нужно самостоятельно искать, экспериментировать и писать код.

Упорядочивание CSS-файлов: принцип «7–1»

Я вас еще не утомил? Отлично! Давайте разберемся, как же упорядочить CSS-файлы. Это здорово повысит эффективность работы и поможет мгновенно находить CSS-код, который нужно поправить.

Пришло время познакомиться с принципом «7–1».
Эти цифры ни о чем вам не говорят, да?

Но всё довольно просто. Нужно следовать двум правилам:

Размещайте частичные файлы в 7 папках.
Импортируйте их все в один файл main.scss, расположенный в корне. Вот и всё.

Семь папок:

Папка base — шаблонный CSS-код, который вы пишете всякий раз, когда начинаете новый проект. Это могут быть правила верстки, анимации, вспомогательные классы (например, margin-right-large, text-center, …) и так далее.
Папка components — все компоненты, используемые для формирования страниц: кнопки, формы, модули листания — «свайперы», всплывающие окна и т. д.
Папка layout — для компоновки различных частей страницы, то есть шапки, подвала, навигации, разделов, собственной сетки и т. д.
Папка pages — для страниц, которым нужен отдельный стиль, отличающийся от стандартного.
Папка themes — для различных тем приложения (темный режим, администрирование и т. д.).
Папка abstracts — все функции, переменные и примеси. Короче говоря, вспомогательные штуки.
Папка vendors — внешние библиотеки, без которых не обходится, пожалуй, ни одно приложение. В папке vendors лежат файлы, которые от вас не зависят: файлы Font Awesome, Bootstrap и всё такое.

Основной файл

Сюда импортируются все частичные файлы.

@import abstracts/variables;
@import abstracts/functions;
@import base/reset;
@import base/typography;
@import base/utilities;
@import components/button;
@import components/form;
@import components/user-navigation;
@import layout/header;
@import layout/footer;
…

Да, выглядит немножко раздуто, признаю. Но эта архитектура придумана для крупных проектов — а для задач помельче есть другой вариант.

Во-первых, нам не понадобится папка vendors: весь внешний CSS-код будет в теге link, помещенном в заголовок. Также не нужна папка themes: скорее всего, у небольшого приложения будет всего одна тема. Наконец, не будет и стилей для конкретных страниц — поэтому убираем соответствующую папку. Итак, осталось четыре папки — отлично!

Теперь у нас два варианта:

Если следовать принципу «7–1», нужно сохранить папки abstracts, components, layout и base.
Если вам удобнее работать с большой папкой, в которой будут все частичные файлы и main.scss, получится что-то такое:

sass/
 _animations.scss
 _base.scss
 _buttons.scss
 _header.scss
 …
 _variables.scss
 main.scss

Решать вам.

Убедил! Как всё это применять? В смысле, браузеры же не поддерживают файлы scss, да?

Верно подмечено! На последнем этапе мы будем компилировать SCSS в CSS.

Из SCSS делаем CSS

Нам понадобятся Node.js и NPM (или Yarn).

Мы будем использовать пакет node-sass, который позволит компилировать файлы .scss в .css.

Интерфейс у него довольно простой:

node-sass <вход> <выход> [параметры]

Мы будем использовать только два параметра:

Параметр -w — следить за каталогом или файлом. Пакет node-sass будет ждать изменений в коде, а как только обнаружит их, сразу же скомпилирует соответствующий файл в CSS, что очень удобно при разработке.
Параметр --output-style — как будет выглядеть выходной CSS-файл. Может принимать следующие значения: nested|expanded|compact|compressed. Мы будем использовать этот параметр при сборке CSS-файла.

Если вам любопытно (надеюсь, так и есть: разработчику должно быть любопытно!), полная документация — здесь.

Теперь мы знаем, какие инструменты будут использоваться. Остальное сделать еще проще:

Создаем проект: mkdir my-app && cd my-app
Инициализируем его: npm init
Добавляем библиотеку node-sass: npm install node-sass --save-dev
Создаем нужные папки, файлы index.html и main.scss:

touch index.html
mkdir -p sass/{abstracts,base,components,layout} css
cd sass && touch main.scss

Добавляем в файл package.json такие сценарии:

{
 …
 "scripts": {
   "watch": "node-sass sass/main.scss css/style.css -w",
   "build": "node-sass sass/main.scss css/style.css --output-style compressed"
 },
 …
}

Добавляем ссылку на скомпилированный CSS-файл в тег head файла index.html:

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="UTF-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
 <meta http-equiv="X-UA-Compatible" content="ie=edge">
 <b><link rel="stylesheet" href="css/style.css"></b>
 <title>My app</title>
</head>
<body>
 <h1 class="heading">My app</h1>
</body>
</html>

Вот и всё! Когда будете писать код, запустите npm run watch и откройте в браузере файл index.html. Чтобы уменьшить CSS, достаточно запустить npm run build.

Кое-что еще

Перезагрузка на лету

Чтобы работа лучше спорилась, можно добавить автоматическую перезагрузку локального файла index.html.

Для этого делаем так:

Устанавливаем пакет live-server: npm install -g live-server
Примечание: это глобальный пакет.
Добавляем npm-run-all в зависимости проекта: npm install npm-run-all --save-dev — это позволит запускать несколько сценариев одновременно.
Добавляем в package.json такие сценарии:

{
 …
 "scripts": {
<b>   "start": "npm-run-all --parallel liveserver watch",
   "liveserver": "live-server",</b>
   "watch": "node-sass sass/main.scss css/style.css -w",
 },
 …
}

Теперь, если запустить npm run start, изменения будут отображаться сразу — без лишних движений с вашей стороны.

Автоматические префиксы

Мы настроили инструменты разработки — отлично! Теперь поговорим об инструментах сборки, в частности — об этом: Autoprefixer.
Этот инструмент (а точнее, плагин «postcss») анализирует CSS и добавляет к правилам CSS префиксы поставщиков, используя значения из Can I Use.

При создании веб-сайта могут использоваться новые функции, которые поддерживаются не во всех браузерах. Реализовать поддержку таких функций позволяют префиксы поставщиков.

Пример того, как оно будет выглядеть:

-webkit-animation-name: myAnimation;
-moz-animation-name: myAnimation;
-ms-animation-name: myAnimation;

Да-да, писать это вручную — утомительно. Облегчит нам жизнь инструмент для автоматического добавления префиксов, который сделает CSS-код совместимым с браузерами без дополнительных усилий.

Итак, чтобы собрать CSS:

Компилируем все SCSS-файлы в один CSS-файл.
Добавляем префиксы, используя Autoprefixer.
Сжимаем CSS-файл.

Осталось всего ничего — не переключайте канал.

Добавляем две зависимости — postcss-cli и autoprefixer: npm install autoprefixer postcss-cli --save-dev
Изменяем сценарий build и добавляем в package.json эти строки:

{
 …
 "scripts": {
   "start": "npm-run-all --parallel liveserver watch",
   "liveserver": "live-server",
   "watch": "node-sass sass/main.scss css/style.css -w",
<b>   "compile": "node-sass sass/main.scss css/style.css",
   "prefix": "postcss css/style.css --use autoprefixer -o css/style.css",
   "compress": "node-sass css/style.css css/style.css --output-style compressed",
   "build": "npm-run-all compile prefix compress"</b>
 …
}

Теперь при запуске npm run build будут добавлены префиксы поставщиков, а сам CSS-код будет сжат. Просто магия!

А хотите еще немножко волшебства? Я поднял репозиторий — чтобы вы могли разобраться побыстрее?

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

И… это всё на сегодня! Теперь вы умеете писать поддерживаемый модульный CSS-код с возможностью повторного использования.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее

Комментарии (27)

lemproix
03.08.2018 09:41
#18953303
+1
Вас лучше статью скрыть в черновики или вовсе удалит, так как данный материал уже имеется тут

https://m.habr.com/company/ruvds/blog/418825/

qnok
03.08.2018 09:44
#18953313
.title input #app

У меня знакомство с CSS только базовое, но разве многократное использование идентификаторов это хорошо, там где встречаются слова «лучше» и «красивее»?
".title input #app" вместо "#app" предполагает наличие или нескольких блоков #app или его сильно различное поведение в зависимости от родителя (и тогда вроде все ок, но все равно какое-то ощущение неправильности).
Но это все равно какая-то страшная конструкция — элемент с идентификатором в элементе input.
1. qnok
  03.08.2018 09:46
  #18953323
  Ан, нет, оказывается по ссылке m.habr.com/company/ruvds/blog/418825 всё имеет другой смысл и там перечисление: .title, input, #app

immaculate
03.08.2018 10:01
#18953381
Ещё существует мнение, что благодаря прорывам в CSS за последние 4-5 лет, SCSS уже не нужен. В частности, например, переменные уже есть в CSS и поддерживаются всеми браузерами.
1. Flying
  03.08.2018 10:32
  #18953467
  SCSS — это далеко не только CSS переменные. Вложенные селекторы, типизированные данные, mixins, placeholders и т.п. — всего этого нет и не будет в CSS, просто потому что там всему этому не место. Конечно есть и альтернативы более близкие к CSS, тот же PostCSS, но во многом SCSS — незаменимый инструмент в написании большого количества поддерживаемого CSS кода
  1. immaculate
    03.08.2018 10:37
    #18953485
    Я не занимаюсь фронтендом, но так как часто приходится смотреть или делать мелкие правки, пытаюсь быть в курсе происходящего.
    
    К сожалению, выводы к которым я пришел: большинство даже во фронтенде не знаю возможностей даже голого CSS, не говоря уже о SCSS. Например, те же mixin'ы в коде, не являющемся частью какого-нибудь фреймворка, я почти не встречал. Более того, масса верстальщиков, дизайнеров и т.д. до сих пор вкрячивает свойства с префиксами типа -moz, -webkit вручную в SCSS даже там, где все браузеры включая IE поддерживают свойства без префиксов уже несколько лет.
    
    Может быть, это локальный феномен, беда маленьких компаний, и мне так не везет, конечно.
    
    JustDont
    03.08.2018 10:54
    #18953545
    -1
    Более того, масса верстальщиков, дизайнеров и т.д. до сих пор вкрячивает свойства с префиксами типа -moz, -webkit вручную в SCSS даже там, где все браузеры включая IE поддерживают свойства без префиксов уже несколько лет.
    
    Может быть это станет для вас открытием, но не все люди используют браузеры последних версий. И IE6-то до сих пор не умер вот чтоб прям совсем полностью, несмотря на активное удавливание его самим Microsoft.
    
    immaculate
    03.08.2018 11:01
    #18953585
    Не открытие, я даже работал в проектах, где было важно поддерживать совместимость со старыми браузерами.
    
    Но я говорю о тех проектах, где пользователь с IE6 в принципе не может встретиться. Просто пишут на автомате, и самое главное без использования средств SCSS для автоматического раскрытия таких пропертей.
    
    Даже более того, приходится следить и бить по рукам, когда пишут константы в SCSS (например, цвета) без использования переменных.
    
    Но я понимаю, что это в первую очередь вопрос грамотности разработчиков, не каждая компания может позволить себе нанять лучших из лучших.
    
    Просто очень часто сталкиваюсь с ужасным кодом CSS, и когда его запихивают в SCSS не становится лучше.
    
    JustDont
    03.08.2018 11:08
    #18953607
    Просто очень часто сталкиваюсь с ужасным кодом CSS, и когда его запихивают в SCSS не становится лучше.
    
    А это потому, что CSS в своей основе настолько печален, что никакой препроцессор поверх этого — ситуацию не улучшает сам по себе.
    CSS не «бьет по рукам», и не имеет возможности этого делать, да и вообще обладает запредельно скудными возможностями структурирования, так, что даже очень простые вещи поверх, типа тех же CSS Modules, уже воспринимаются как прорыв. От добавления в это всё новых фич ничего принципиально не меняется — фичи можно использовать во благо, а можно и нет.
    
    Тут спасает только написание внутренних дев-доков относительно правил и нормативов пользования фичами препроцессора, и потом код-ревью для проверки соответствия. Тогда еще можно как-то немного прибираться.
    
    Flying
    03.08.2018 11:25
    #18953647
    В защиту CSS всё-таки стоит сказать что во многом то, как он сделан, определяется тем как он используется. Я имею в виду то что сама суть CSS — это описание правил стилизации элементов документа браузерами. Причём не просто стилизации, а realtime стилизации (уверен что вы понимаете разницу). Требование очень высокой производительности (а, я думаю, никто не против того что высокая производительность здесь необходима) подразумевает введение различного рода ограничений которые вне контекста кажутся странными и глупыми.
    
    К примеру, думаю, многие в курсе что в CSS селекторах нет т.н. back references т.е. нельзя сделать селектор вида "элемент перед которым стоит другой элемент". Попытка ввести такой селектор была в CSS Selectors Level 4, но в итоге от неё отказались несмотря на то что фича явно полезная. Причина — это замедлит работу CSS движка т.к. сейчас CSS всегда идёт по DOM дереву слева направо, введение потенциальной необходимости идти и в другом направлении усложнит и замедлит код.
    
    Ещё один пример с которым сам столкнулся недавно: у весьма интересного нового свойства position: sticky нет возможности с помощью CSS узнать в каком же состоянии находится элемент (т.е. нет какого-нибудь псевдо-класса типа :stuck хотя он явно напрашивается). Вот здесь можно почитать обсуждение W3C CSS WG по данному вопросу, рекомендую ознакомиться, очень интересно, особенно этот и этот комментарии.
    
    JustDont
    03.08.2018 11:37
    #18953697
    Требование очень высокой производительности
    
    … ушло в прошлое уже давненько, на самом деле. В нынешнее время, в эпоху фреймворков и прочего JS в гигантских объемах, выполняющего в миллионы (и хорошо если только в миллионы) больше операций, чем это реально нужно — говорить о «необходимости высочайшей производительности ЦСС» лицемерно.
    
    Попытка ввести такой селектор была в CSS Selectors Level 4, но в итоге от неё отказались несмотря на то что фича явно полезная.
    
    Ага, вот только отказались от неё не из-за производительности, а потому, что все сказали «ребята, мы уже миллионы лет делаем однократный проход по DOM, а вы тут нам щас предлагаете ради одного селектора многопроходность лепить?».
    
    И я больше чем уверен, что через некоторое время таки прогнутся и сделают.
    
    ЗЫ: И весь этот разговор опять же не имеет никакого отношения к отсутствию структурирования. Вот уж структурирование в ЦСС можно было преспокойно запиливать, никакие соображения производительности тут помешать не могут.
    
    justboris
    05.08.2018 12:01
    #18958841
    Вот доклад с конференции этого года про статус и планы на container queries:
    https://www.youtube.com/watch?v=0wA4CMo9_EU
    
    Если коротко, то добавлять многопроходность в CSS никто не будет, слишком много всего придется переписать, зато появится новое DOM-API, ResizeObserver, в котором можно размеро-зависимые стили оформить через Javascript.
  1. exdeniz
    03.08.2018 21:37
    #18955995
    +1
    Чушь это все. Недавно слезли со stylus в пользую postcss с исключительно поддержкой стандарта будущего. Ничто не пострадало, мир не упал и поддерживаемость кода такая же. Если у вас при обычном css страдает поддержка, то вам стоит задуматься о методологии/архитектуре.

Amareis
03.08.2018 10:14
#18953423
Про CSS Modules упомянуть бы, очень облегчают жизнь. В том же Vue нечто похожее вообще из коробки идет.

ArsenAbakarov
03.08.2018 11:29
#18953657
и зачем все импортить, не проще ли пройти сборщиком и собрать нужный бандл, уже минифицированный и с другими плюшками?
1. Flying
  03.08.2018 11:32
  #18953665
  Для того чтобы сборщик собрал всё необходимое — как раз и нужны импорты, он же по ним строит дерево зависимостей. Иначе как он узнает порядок включения файлов (который имеет значение)?
1. dagen
  03.08.2018 12:30
  #18953919
  У вас всё равно будет где-то зашита эта информация о списке файлов и о порядке их включения. Так зачем же её вытаскивать в сборщик, если можно оставить в стилях?

Sabubu
03.08.2018 12:25
#18953901
Если человек не может писать нормальный код на CSS (например, с использованием БЭМ), то на SCSS с его богатыми возможностями он наворотит еще более запутанный код. Ему нужен не препроцессор, а курс изучения CSS.

Например, возможность вкладывать стили приводит к тому, что люди в SCSS копируют структуру HTML, создавая по 5-6 (!) уровней вложенности и пишут бредовые конструкции вроде

.header {
div {
span {
a {
span {

Я знаю, многие подумают «ну бред, как такое можно писать». А я это видел своими глазами.

Или пишут вложенные блоки длиной в несколько экранов, так, что не понять, где ты находишься.

Или разрывают названия классов:

.header {
&_logo {

Так, что в итоге их нельзя искать поиском. Вдумайтесь! Вы не сможете узнать, где какой класс используется.

Миксины дают возможность конфликта CSS правил (когда миксин определяет одно правило и оно мешает заданному явно правилу).

Так как это не упомянуто в статье, а содержатся лишь похвалы, то я подозреваю, что ее писал неопытный человек, который нашел в интернете описание фич SCSS и «нареврайтил» из них хвалебную статью.

Имена файлов, начинающиеся с подчеркивания, имхо, выглядят отвратительно. _как _это _предложение.

Идея имопртировать все в один файл нездоровая и приводит к тяжеленным CSS файлам как на гитхабе, где используется лишь 5-10% правил. Да, в гитхабе крутые разработчики, но в плане навыков использования CSS они не сильно отличаются от фрилансера Васи.

Из плюсов — удобно для адаптивной верстки писать media правила внутри блока.

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

Ну и отдельно доставляет необходимость использовать ноду. Она тормозная, может только запускаться несколько секунд, а в режиме watch с большим количеством каталогов любит есть CPU как легкая инди-игра.

Еще раз напомню, тот, кто не видит недостатков SCSS, просто или не имеет достаточного опыта или зрения.
1. dagen
  03.08.2018 23:36
  #18956283
  Ну и отдельно доставляет необходимость использовать ноду.
  Ужас-ужас. Как же у вас npm работает? На Воле Божьей? Аль по щучьему велению?
1. dpr
  06.08.2018 00:44
  #18960337
  +1
  Или разрывают названия классов:
  
  .header {
  &_logo {
  
  Так, что в итоге их нельзя искать поиском. Вдумайтесь!
  
  Если мы придерживаемся той же методологии именования БЭМ, то нам не нужно искать класс .header_logo! Нам достаточно найти класс-имя блока, и в нем мы увидим всё остальное. Вдумайтесь! =)
  1. noodles
    06.08.2018 12:26
    #18961745
    Имена файлов, начинающиеся с подчеркивания, имхо, выглядят отвратительно. _как _это _предложение.
    
    нижнее подчёркивание не просто так… оно указывает «sass-компилятору» игнорировать этот файл и не создавать из него лишний .css файл.

dagen
03.08.2018 12:38
#18953937
В статье автор рядом расположил scss и postcss (autoprefixer). Но если есть postcss, то зачем ещё один инструмент для сборки стилей (node-sass)? Если очень хочется использовать этот DSL, например в силу привычки, то есть postcss-scss (он не компилирует, он лишь парсит, открывая возможность для остальных postcss-плагинов обрабатывать scss исходники).

Но ИМХО для сохранения sass/scss-синтаксиса нет особого смысла в новом проекте, плагины postcss покрывают большую часть функционала SASS и добавляют кучу дополнительных возможностей.
1. justboris
  05.08.2018 11:55
  #18958823
  Пробовал так делать, использовал precss. К сожалению, встретилось слишком много досадных багов (раз, два, плюс вопрос про стабильность проекта).
  
  Откатились обратно на SASS, с ним работает намного надежнее.

olexandr17
03.08.2018 14:29
#18954451
я недавно пытался свой цсс в ангулар приложении привести к бэму и у меня возник вопрос.
в какой-то из статей я встречал совет, что в имени класса не должно быть больше одного элемента (бЭм), но класс хедера я назвал — header, класс контейнера логотипа — header__logo, а самой картинки — header__logo__image.
стили у меня прописаны для всех 3 уровней вложенности. как правильно называть эти классы в моем случае?
1. anttoshka
  04.08.2018 07:32
  #18956591
  Одна и та же ошибка у всех. По БЭМ нельзя в элемент вкладывать другой элемент. Т.е. Должен быть класс header__logo и header__logo-image (header__image). Или если необходимо — для логотипа делать отдельный блок logo с структурой .header>.header__logo.logo>.logo__image

R4_Serega
03.08.2018 23:10
#18956247
+1
А вот мне наоборот нравится писать CSS, и с опытом все красивее и удобнее получается, и вложенности и классы и тд. А вот с SCSS не сложилось, несколько раз пробовал начинать, но явных преимуществ не видел

alex6636
05.08.2018 13:12
#18959031
Последнее читается лучше, правда?
Как по мне так же, как если бы h1 span сделать с отступом