Термин «качество кода» не является новым для программистов. В конце концов, каждый разработчик знает, что для работы кода недостаточно. Он также должен обладать другими качествами: он должен быть читаемым, хорошо отформатированным и последовательным. Он также должен соответствовать определенному стандарту количественных метрик. К сожалению, это часто упускается из виду при написании CSS. Мы можем потратить много времени, обсуждая, почему это происходит, но важная часть заключается в том, что CSS — это такой же код, как JavaScript, PHP или что-то еще, и мы должны обратить внимание на то, как мы его пишем. В противном случае это может привести к тому, что все будет сложнее, чем должно быть.
В этой статье мы рассмотрим, как мы можем использовать PostCSS, чтобы помочь нам поддерживать более высокое качество нашего кода CSS. Во-первых, давайте попробуем определить, что мы на самом деле подразумеваем под «лучшим кодом CSS». Есть несколько вещей, на которые стоит обратить внимание:
- Код должен быть согласованным по стилю. Вы можете выбирать, как называть свои классы, где размещать новые строки или как вы перечисляете свойства, но вы должны делать это одинаково для всех ваших таблиц стилей. Последовательный стиль улучшает читабельность и облегчает понимание кода.
- Код должен соответствовать некоторым стандартам метрик. Существуют количественные метрики, которые мы можем измерять и поддерживать на определенном пороге, например, максимальную точность любого селектора или количество уникальных цветов, используемых на странице.
- Следует избегать хаков — некоторые конструкции, такие как директива
!important
Конечно, это не полный список, но давайте сосредоточимся на вышеупомянутых проблемах. Они могут показаться очевидными, но их легко можно упустить из виду при работе над большим проектом с большой командой, в которой люди могут иметь разные навыки. Нам нужен инструмент, который может помочь нам автоматически внедрить эти стандарты посредством анализа кода. Вот тут и приходит PostCSS.
Как может помочь PostCSS
В предыдущей статье о PostCSS здесь, в SitePoint, мы рассмотрели, что такое PostCSS и как его плагины можно использовать для различных целей. В этой статье мы сосредоточимся на нескольких плагинах PostCSS, которые могут помочь нам сохранить качество нашего CSS-кода в лучшем виде.
Прежде чем мы начнем, давайте настроим проект песочницы, с которым мы можем поэкспериментировать. В отличие от использования PostCSS через командную строку, как в предыдущей статье, вместо этого мы будем использовать Gulp. Начните с создания новой папки и запуска там проекта npm. После этого нам нужно будет установить Gulp, плагин PostCSS и репортер для просмотра вывода плагинов PostCSS. Для этого перейдите к вновь созданному проекту и запустите:
npm i gulp gulp-postcss postcss-reporter --save-dev
После этого создайте пустой файл style.cssgulpfile.js
var gulp = require('gulp');
gulp.task('analyze-css', function () {
var postcss = require('gulp-postcss');
var reporter = require('postcss-reporter');
return gulp.src('style.css')
.pipe(postcss([
reporter()
]));
});
Это определит задачу, которая будет сканировать содержимое style.css Вы уже можете запустить gulp analyze-css Давайте добавим наш первый плагин для линтинга.
Stylelint
К настоящему времени, безусловно, есть линтер для любого языка, и CSS не является исключением. Stylelint позволяет вам проверять ваш CSS-код на соответствие заранее определенному набору правил, которые могут проверять ваш код на предмет согласованного форматирования, использования определенных правил, единиц или директив, а также возможных ошибок (таких как неправильные цвета). Он позволяет вам определить более сотни правил — некоторые из них выполняют базовые функции, например, гарантируя наличие пробела между селектором и следующей фигурной скобкой или что используются только одинарные кавычки. Другие интереснее. Вот несколько примеров:
- Свойства
property-blacklistunit-blacklist -
property-no-vendor-prefixраздела «Могу ли я использовать» . -
declaration-no-important!important -
selector-max-specificity
Stylelint поставляется со всеми правилами, отключенными по умолчанию, поэтому вы должны сами настроить правила. Это может занять некоторое время, учитывая количество правил, которые оно имеет. Кроме того, вы можете использовать предопределенную конфигурацию, такую как stylelint-config-standard, и расширять ее своими правилами.
Давайте настроим stylelint со стандартным набором правил:
npm i stylelint stylelint-config-standard --save-dev
Вам также нужно расширить свой gulpfile, чтобы включить новый плагин:
var gulp = require('gulp');
gulp.task('analyze-css', function () {
var postcss = require('gulp-postcss');
var stylelint = require('stylelint');
var reporter = require('postcss-reporter');
return gulp.src('style.css')
.pipe(postcss([
stylelint(),
reporter()
]));
});
Правила stylelint могут быть встроены в gulpfile, но я предпочитаю хранить их в отдельном файле. Создайте файл .stylelintrc
{
"extends": "stylelint-config-standard"
}
Это скажет stylelint, что наш собственный набор правил будет основан на стандартной конфигурации. Теперь давайте обновим наш файл style.css
.title,.content{
background: #FFFFFF;
font-size:0.9em;
margin: 0;
}
Просто запустите gulp analyze-css
style.css
1:7 ⚠ Expected newline after "," (selector-list-comma-newline-after) [stylelint]
1:15 ⚠ Expected single space before "{" (block-opening-brace-space-before) [stylelint]
1:17 ⚠ Expected newline after "{" of a multi-line block (block-opening-brace-newline-after) [stylelint]
1:17 ⚠ Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
2:5 ⚠ Expected indentation of 2 spaces (indentation) [stylelint]
2:17 ⚠ Expected "#FFFFFF" to be "#ffffff" (color-hex-case) [stylelint]
2:17 ⚠ Expected "#FFFFFF" to be "#FFF" (color-hex-length) [stylelint]
2:25 ⚠ Expected newline after ";" in a multi-line rule (declaration-block-semicolon-newline-after) [stylelint]
2:25 ⚠ Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
3:5 ⚠ Expected indentation of 2 spaces (indentation) [stylelint]
3:15 ⚠ Expected single space after ":" with a single-line value (declaration-colon-space-after) [stylelint]
4:4 ⚠ Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
5:4 ⚠ Unexpected whitespace at end of line (no-eol-whitespace) [stylelint]
6:5 ⚠ Expected indentation of 2 spaces (indentation) [stylelint]
7:1 ⚠ Unexpected missing newline at end of file (no-missing-eof-newline) [stylelint]
Использование этого плагина действительно может помочь вам применять передовые методы при написании CSS. Продолжите, исследуя список правил и переопределяя те из стандартной конфигурации, с которыми вы не согласны. Позже вы можете распространять эти правила в виде своего набора проектов и команд. Если нет правила, которое соответствует вашим потребностям, вы всегда можете реализовать его самостоятельно .
Я использую
При написании CSS большая боль возникает из-за попыток помнить, на какие браузеры вы ориентируетесь и какие функции в них можно использовать. Do I Use — это плагин, который поможет вам убедиться, что написанный вами CSS поддерживается вашими целевыми браузерами. Вы начинаете с определения того, какие браузеры вы хотите поддерживать. После этого, когда вы запустите плагин, он просканирует ваш код, проверит его по базе данных caniuse.com и выдаст ошибку, если какой-то код не поддерживается.
Использовать этот плагин довольно просто. Установите это:
npm i doiuse --save-dev
И обновите свой gulpfile:
return gulp.src('style.css')
.pipe(postcss([
doiuse({
browsers: ['ie >= 9', 'last 2 versions'],
}),
reporter()
]));
Эта конфигурация говорит о том, что мы стремимся поддерживать последние 2 основные версии каждого браузера, а также IE9 и новее.
Чтобы продемонстрировать результат, мы запустим плагин для нового модного CSS, который использует функции из модуля компоновки сетки.
body {
display: grid;
grid-columns: 200px 1% 1fr;
grid-rows: auto 15px auto 15px auto;
}
Вот что должен сказать по этому поводу doiuse:
style.css
11:2 ⚠ CSS3 Multiple column layout not supported by: IE (9), Firefox (43,44), Chrome (48,49), Safari (8,9), Opera (34,35), iOS Safari (8.1-8.4,9.0-9.2) (multicolumn) [doiuse]
Обидно, но на момент написания статьи модуль CSS-сетки еще недостаточно развит. Но давайте сосредоточимся на хорошей части: теперь у нас есть инструмент, который поможет нам не отставать от отслеживания возможностей браузера!
Неизменный CSS
Одним из основных источников ошибок и сложностей в таблицах стилей является переопределение правил CSS. Даже используя современные средства отладки, иногда бывает сложно выяснить, где стиль был переопределен и почему. Вот почему считается хорошей практикой не переопределять стили, а добавлять дополнительные модификаторы к селекторам. Неизменяемый плагин CSS может предупредить вас, когда такие случаи переопределения стиля происходят в вашем коде.
Имеет два режима работы. По умолчанию он только предупредит вас, если вы попытаетесь переопределить стили в разных файлах. Когда несколько файлов объединены в один файл, он будет использовать исходные карты, чтобы выяснить, откуда появились стили. Это означает, что он может хорошо играть с импортом Sass или плагином postcss-import . Если вы хотите сделать еще один шаг вперед, вы можете включить строгий режим, который также предупредит вас, если вы переопределите стили в одном файле.
Вот быстрый пример, чтобы продемонстрировать все это. Как обычно, нам нужно сначала установить плагин:
npm i immutable-css --save-dev
И включите плагин со строгим режимом в gulpfile:
return gulp.src('style.css')
.pipe(postcss([
immutableCss({
strict: true
}),
reporter()
]))
Затем добавьте в него немного неприятного CSS:
.title {
color: blue;
font-weight: bold;
}
.title {
color: green;
}
.article .title {
font-size: 1.2em;
}
Плагин будет удобно сообщать, что класс .title
⚠ .title was mutated 3 times
[line 1, col 1]: /Users/pavels/Documents/projects/sandbox/postcss/style.css
[line 6, col 1]: /Users/pavels/Documents/projects/sandbox/postcss/style.css
[line 10, col 1]: /Users/pavels/Documents/projects/sandbox/postcss/style.css
Вы можете возиться с плагином на его интерактивной игровой площадке .
CSS Stats и List Selectors
Последние два плагина, которые мы рассмотрим, будут CSS-статистика и список селекторов . Они немного отличаются от плагинов, которые мы изучали до сих пор: они не направлены на выявление проблем, а предоставляют данные для пользовательского анализа.
Статистика CSS предоставляет обширную информацию о таблице стилей в целом: сколько правил, селекторов или объявлений используется, каковы они, какова средняя специфичность селектора или какие размеры шрифта встречаются в коде. Это всего лишь образец информации, которую можно найти в сгенерированном отчете. Более подробное описание можно найти на его странице GitHub . Вы также можете посетить cssstats.com с примерами отчетов, которые могут быть сгенерированы с использованием данных из плагина.
Список селекторов — это более простой плагин, который фокусируется на извлечении списка селекторов, используемых в таблицах стилей, и группировании их по категориям — селекторы классов, атрибуты, идентификаторы или теги.
Оба эти плагина могут быть использованы для всех видов анализа кода. Всего несколько примеров:
- Сохранение вашей специфики, размера и количества используемых объектов на определенном пороге.
- Убедитесь, что все ваши селекторы написаны в соответствии с вашим стилем кодирования.
- Обеспечение согласованности ваших медиа-запросов.
Это всего лишь некоторые идеи, которые пришли в голову. Более практичным подходом было бы настроить все предыдущие плагины, вернуться к этим двум и посмотреть, смогут ли они передать какую-либо более полезную информацию.
Завершение всего этого
Встраивание и анализ кода — это только один из способов использования PostCSS, но он сам по себе может принести большую пользу вашему процессу разработки, а также сэкономить время и немного поседеть среди ваших разработчиков. Несмотря на то, что это становится обычной практикой в других областях программирования, им все еще часто пренебрегают, когда дело доходит до CSS. Я считаю, что настройка PostCSS и этих нескольких плагинов — это простой шаг, который сделает вашу разработку намного проще и надежнее.