8 рекомендаций SCSS, о которых следует помнить
Оригинальная статья: Annie Liao — 8 SCSS Best Practices to Keep in Mind
На прошлой неделе у меня была возможность просмотреть руководящие принципы кодирования в компании где я работаю, некоторые из которых я нашла очень полезными не только для совместной работы, но и для разработки личных проектов.
Спонсор поста
Прогнозы на все случаи жизни
Спец-прогноз на спорт бесплатно от экспертов
Автор сайта пишет прогнозы на спортивные события, в которых разбирется.
В основном, это футбол и хоккей. Футболом занимается профессионально.
Хоккей знает и любит еще со времен Харламова, Якушева и Мальцева.
На сайте вы найдете:
— Новости спорта
— Точные прогнозы на футбол сегодня бесплатно
— Прогноз на Лигу Европы
— Прогноз на Лигу Чемпионов
— VIP-Матч
— Прогонозы на Снукер
Вот восемь лучших рекомендаций SCSS из руководства, которые заставили меня переосмыслить то, как я структурирую свой код CSS:
Примечание. Следующие советы предназначены для SCSS, поэтому некоторые из них могут не относиться к чистому CSS. Большое спасибо @yzoja и @ 8detect за отличное напоминание!
1. Mobile First
Когда речь идет о адаптивном дизайне, принято расставлять приоритеты таким образом что настольная версия идет первым, что может сделать настройку для мобильных устройств болезненным процессом. Вместо этого мы должны разрабатывать дизайн расширяя его, а не втискивать вещи, чтобы соответствовать требованиям мобильного дизайна
Не делайте так:
.bad { // Desktop code @media (max-width: 768px) { // Mobile code } }
Лучше так:
.good { // Mobile code @media (min-width: 768px) { // Desktop code } }
2. Установить переменные
Определение в CSS переменных и миксинов должно быть частью первоначальной настройки, и это может сделать проект более удобным для сопровождения.
Согласно руководству, вот некоторые общие свойства, которые выиграют от использования для них отдельных переменных:
border-radius
color
font-family
font-weight
margin
(gutters, grid gutters)transition
(duration, easing) – consider a mixin
3. Избегайте #id
и !important
Оба !important и #id считаются слишком конкретными спецификаторами и могут нарушать порядок рендеринга CSS, особенно при совместной разработке.
Не делайте так:
#bad { #worse { background-color: #000; } }
Лучше так:
.good { .better { background-color: rgb(0, 0, 0); } }
4. Избегайте магических чисел
Старайтесь не устанавливать произвольные числа, потому что они «просто работают»; другие разработчики могут не понимать, почему для свойство выбрано такое конкретное число. Вместо этого используйте относительные значения, когда это возможно.
Если вам интересно, у CSS Tricks есть четкое объяснение того, почему магические числа плохие.
Не делайте так:
.bad { left: 20px; }
Лучше так:
.good { // 20px из-за высоты шрифта left: ($GUTTER - 20px - ($NAV_HEIGHT / 2)); }
5. Описательное именование
Легко определить CSS-селекторы в соответствии с внешним видом дизайна но лучше описать иерархию.
Не делайте так:
.huge-font { font-family: 'Impact', sans-serif; } .blue { color: $COLOR_BLUE; }
Лучше так:
.brand__title { font-family: 'Impact', serif; } .u-highlight { color: $COLOR_BLUE; }
6. Нулевые значения и единицы измерения
Это может зависеть от личных предпочтений или от конкретного руководства по стилю проекта, но соблюдения единого стиля очень важно. Приведенное ниже правило ожидает, чтобы вы указывали единицы измерения для нулевого значения, но не для значений нулевой длины (margin: 0;). Кроме того, добавляйте ноль в начало для десятичных знаков, и не переусердствуйте на десятичных знаках.
Не делайте тае:
.not-so-good { animation-delay: 0; margin: 0px; opacity: .4567; }
Лучше так:
.better { animation-delay: 0s; margin: 0; opacity: 0.4; }
7. Встроенное комментирование
Лучшая практика здесь — комментировать свойства, которые вы описываете. Кроме того, используйте встроенные комментарии (//) вместо комментариев на уровне блоков (/ * * /), которые сложнее раскомментировать.
Не делайте так:
.bad { background-color: red; // Not commenting on top of property /* padding-top: 30px; width: 100% */ }
Лучше так:
.good { // Commenting on top of property background-color: red; // padding-top: 30px; // width: 100%; }
8. Вложенные медиа-запросы
Чтобы легко находить медиа-запросы, рекомендуется хранить медиа-запросы в корне объявления, а не вкладывать их в каждый селектор.
Не делайте так:
.bad { &__area { // Code @media (min-width: 568px) { // Code } } &__section { // Code @media (min-width: 568px) { // Code } } }
Лучше так:
.good { &__area { // Code } &__section { // Code } @media (min-width: 568px) { &__area { // Code } &__section { // Code } } }
Это ни в коем случае не исчерпывающий список лучших практик кодирования, но они, безусловно, играют жизненно важную роль в разработке удобочитаемых, масштабируемых веб-приложений. Есть ли какое-нибудь руководство по CSS, которому вы следуете как своей северной звезде? Дай мне знать в комментариях (Блог автора статьи)!
Про медиа запросы — спорно
Определенно. Лучше все стили блока держать в одном месте, чем искать их в мадиазапроспх, разбросанных по всему файлу.
8-ой пункт мимо
6 пункт тоже, писать везде 0 перед точкой, любой не кастомный линтер это подчеркнет как ошибку. И по поводу mobile first, нет ни одного довода почему он лучше, чем desktop first. На страницу загрузится весь css файл целиком в любом случае, тогда какая выгода делать именно mobile first?
Насколько я понимаю, при mobile first, браузер не будет применять стили для блока (элемента) несколько раз, как бы перезаписывая их.