Оригинальная статья: Annie Liao — 8 SCSS Best Practices to Keep in Mind
На прошлой неделе у меня была возможность просмотреть руководящие принципы кодирования в компании где я работаю, некоторые из которых я нашла очень полезными не только для совместной работы, но и для разработки личных проектов.
Спонсор поста
Прогнозы на все случаи жизни
Спец-прогноз на спорт бесплатно от экспертов
Автор сайта пишет прогнозы на спортивные события, в которых разбирется.
В основном, это футбол и хоккей. Футболом занимается профессионально.
Хоккей знает и любит еще со времен Харламова, Якушева и Мальцева.
На сайте вы найдете:
— Новости спорта
— Точные прогнозы на футбол сегодня бесплатно
— Прогноз на Лигу Европы
— Прогноз на Лигу Чемпионов
— VIP-Матч
— Прогонозы на Снукер
Вот восемь лучших рекомендаций SCSS из руководства, которые заставили меня переосмыслить то, как я структурирую свой код CSS:
Примечание. Следующие советы предназначены для SCSS, поэтому некоторые из них могут не относиться к чистому CSS. Большое спасибо @yzoja и @ 8detect за отличное напоминание!
Когда речь идет о адаптивном дизайне, принято расставлять приоритеты таким образом что настольная версия идет первым, что может сделать настройку для мобильных устройств болезненным процессом. Вместо этого мы должны разрабатывать дизайн расширяя его, а не втискивать вещи, чтобы соответствовать требованиям мобильного дизайна
Не делайте так:
.bad { // Desktop code @media (max-width: 768px) { // Mobile code } }
Лучше так:
.good { // Mobile code @media (min-width: 768px) { // Desktop code } }
Определение в CSS переменных и миксинов должно быть частью первоначальной настройки, и это может сделать проект более удобным для сопровождения.
Согласно руководству, вот некоторые общие свойства, которые выиграют от использования для них отдельных переменных:
border-radius
color
font-family
font-weight
margin
(gutters, grid gutters)transition
(duration, easing) – consider a mixin#id
и
Оба и #id считаются слишком конкретными спецификаторами и могут нарушать порядок рендеринга CSS, особенно при совместной разработке.
Не делайте так:
#bad { #worse { background-color: #000; } }
Лучше так:
.good { .better { background-color: rgb(0, 0, 0); } }
Старайтесь не устанавливать произвольные числа, потому что они «просто работают»; другие разработчики могут не понимать, почему для свойство выбрано такое конкретное число. Вместо этого используйте относительные значения, когда это возможно.
Если вам интересно, у CSS Tricks есть четкое объяснение того, почему магические числа плохие.
Не делайте так:
.bad { left: 20px; }
Лучше так:
.good { // 20px из-за высоты шрифта left: ($GUTTER - 20px - ($NAV_HEIGHT / 2)); }
Легко определить CSS-селекторы в соответствии с внешним видом дизайна но лучше описать иерархию.
Не делайте так:
.huge-font { font-family: 'Impact', sans-serif; } .blue { color: $COLOR_BLUE; }
Лучше так:
.brand__title { font-family: 'Impact', serif; } .u-highlight { color: $COLOR_BLUE; }
Это может зависеть от личных предпочтений или от конкретного руководства по стилю проекта, но соблюдения единого стиля очень важно. Приведенное ниже правило ожидает, чтобы вы указывали единицы измерения для нулевого значения, но не для значений нулевой длины (margin: 0;). Кроме того, добавляйте ноль в начало для десятичных знаков, и не переусердствуйте на десятичных знаках.
Не делайте тае:
.not-so-good { animation-delay: 0; margin: 0px; opacity: .4567; }
Лучше так:
.better { animation-delay: 0s; margin: 0; opacity: 0.4; }
Лучшая практика здесь — комментировать свойства, которые вы описываете. Кроме того, используйте встроенные комментарии (//) вместо комментариев на уровне блоков (/ * * /), которые сложнее раскомментировать.
Не делайте так:
.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%; }
Чтобы легко находить медиа-запросы, рекомендуется хранить медиа-запросы в корне объявления, а не вкладывать их в каждый селектор.
Не делайте так:
.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, которому вы следуете как своей северной звезде? Дай мне знать в комментариях (Блог автора статьи)!
Краткий перевод: https://vuejs.org/guide/components/v-model.html Основное использование v-model используется для реализации двусторонней привязки в компоненте. Начиная с Vue…
Сегодня мы рады объявить о выпуске Vue 3.4 «🏀 Slam Dunk»! Этот выпуск включает в…
Vue.js — это универсальный и адаптируемый фреймворк. Благодаря своей отличительной архитектуре и системе реактивности Vue…
Недавно, у меня истек сертификат и пришлось заказывать новый и затем устанавливать на хостинг с…
Каким бы ни было ваше мнение о JavaScript, но всем известно, что работа с датами…
Все, кто следит за последними событиями в мире адаптивного дизайна, согласятся, что введение контейнерных запросов…
View Comments
Про медиа запросы - спорно
Определенно. Лучше все стили блока держать в одном месте, чем искать их в мадиазапроспх, разбросанных по всему файлу.
8-ой пункт мимо
6 пункт тоже, писать везде 0 перед точкой, любой не кастомный линтер это подчеркнет как ошибку. И по поводу mobile first, нет ни одного довода почему он лучше, чем desktop first. На страницу загрузится весь css файл целиком в любом случае, тогда какая выгода делать именно mobile first?
Насколько я понимаю, при mobile first, браузер не будет применять стили для блока (элемента) несколько раз, как бы перезаписывая их.