Писането на последователен и четим CSS, който ще се мащабира добре, е труден процес. Особено когато таблиците със стилове стават по-големи, по-сложни и по-трудни за поддържане. Един от инструментите, с които разработчиците могат да пишат по-добре CSS, са препроцесорите. Препроцесорът е програма, която приема един тип данни и ги преобразува в друг тип данни, а в нашия случай CSS препроцесорите са езици за предварителна обработка, които се компилират в CSS. Има много CSS препроцесори, които предни разработчици препоръчват и използват, но в тази статия ще се спрем на Sass. Нека да видим какво Сас може да предложи , защо е предпочитан избор пред други CSS препроцесори и как да започнете да го използвате по най-добрия начин.
Какво е Sass и защо трябва да го използвате?
За тези от вас, които не знаят какво е Sass, най-добрата отправна точка е да посетите официална уеб страница на Sass . Sass е съкращение от Syntactically Awesome StyleSheets и е разширение на CSS, което добавя сила и елегантност към основния език.
С Sass (Syntactically Awesome StyleSheets) вашият CSS код също ще бъде страхотен. Tweet
Sass е CSS препроцесор с много мощни функции. Най-забележителните характеристики са променливи , удължава , и миксини .
Променливите съхраняват информация, която може да бъде използвана повторно по-късно, като цветове или други често използвани стойности. Extends ви помага да създавате „класове“, които позволяват наследяване на правилата. Mixins, можете да си представите като „функция“. Sass също има някои други невероятни функции в сравнение с други препроцесори, като използването на логически изрази (условни и цикли), потребителски функции, интеграция с други библиотеки като Компас , и много други. Само тези функции могат да помогнат на вас и вашия екип да бъдете по-продуктивни и в крайна сметка да напишете по-добър CSS.
Защо се нуждаете от CSS Ръководство за стил
За съжаление дори препроцесорите не могат да поправят всичко и да ви помогнат да напишете добър CSS код. Проблемът, пред който е изправен всеки разработчик, е, че настоящите уеб приложения стават все по-големи и по-големи. Ето защо кодът трябва да бъде мащабируем и четим и трябва да се избягва код за спагети и неизползвани редове от него. За да избегнете споменатите проблеми, е необходим някакъв стандарт за вашия екип в ежедневната работа. Какво е спагети код и как се случва? Кодът за спагети е име за лош, бавен, повтарящ се и нечетлив код. Когато екип пише големи приложения, без да са налице определени насоки или стандарти, всеки разработчик пише какво има нужда и как иска. Също така, когато разработчиците пишат много корекции на грешки, актуални корекции и кръпки, те са склонни да пишат код, който ще реши проблема, но нямат време да напишат кода по най-добрия начин. В тези ситуации е много обичайно да се стигне до много редове CSS, които вече не се използват в нито един сектор на приложението. Разработчиците нямат достатъчно време за почистване на кода и са принудени да публикуват корекцията възможно най-бързо. Друга повтаряща се ситуация е, че за да поправят бързо счупените неща, разработчиците използват много !important, което води до много хакерски код, който е труден за поддържане, води до много неочаквано поведение и трябва да бъде рефакториран по-късно. Както вече споменахме, с нарастването на кода ситуацията става само по-лоша.
Идеята на тази статия е да сподели правила, съвети и най-добри практики за писане на по-добър Sass. Групирането на тези съвети и най-добри практики на Sass може да се използва като ръководство за стил на Sass. Това ръководство за стил трябва да помогне на разработчиците да избягват гореспоменатите ситуации. Правилата са групирани в логически сегменти за по-лесно препращане, но в крайна сметка трябва да ги приемете и следвате всички. Или поне повечето от тях.
Ръководство за стил
Наборът от правила и най-добри практики в това ръководство за стил са възприети въз основа на опит в работата с много екипи. Някои от тях идват от опит чрез грешка, а други са вдъхновени от някои популярни подходи като BEM. За някои правила няма конкретна причина защо и как са били определени. Понякога е достатъчно да имаш миналия опит като единствена причина. Например, за да сте сигурни, че кодът е четим, е важно всички разработчици да пишат кода по един и същи начин, следователно има правило да не се включват интервали между скобите. Можем да спорим дали е по-добре да включим интервала между скобите или не. Ако смятате, че изглежда по-добре, когато между скобите има интервали, коригирайте това ръководство за стил и правила според вашите предпочитания. В крайна сметка основната цел на ръководството за стил е да дефинира правила и да направи процеса на разработване по-стандартен.
Общи правила за CSS
Винаги трябва да се спазват общите правила. Те са фокусирани най-вече върху това как трябва да бъде форматиран кодът на Sass, за да се осигури последователност и четливост на кода:
- За отстъп използвайте интервали вместо раздели. Най-добрата практика е да използвате 2 интервала. С тази опция можете да водите своя собствена свещена война и можете да дефинирате собственото си правило и да използвате или раздели, или интервали, или каквото ви е най-подходящо. Важно е само да дефинирате правило и да го следвате, като същевременно сте последователни.
- Включете празен ред между всеки израз. Това прави кода по-разбираем за хората и кодът се пише от хората, нали?
- Използвайте един селектор на ред, по следния начин:
selector1, selector2 { } - Не включвайте интервал между скобите.
selector { @include mixin1($size: 4, $color: red); } - Използвайте единични кавички, за да приложите низове и URL адреси:
selector { font-family: ‘Roboto’, serif; } - Завършете всички правила с точка и запетая без интервали преди:
selector { margin: 10px; } Правила за селектори
След това следваме набор от правила, които да използваме при работа със селектори:
- Избягвайте използването на селектори за идентификация. Идентификаторите са твърде специфични и се използват най-вече за JavaScript действия.
- Избягвайте
!important. Ако трябва да използвате това правило, това означава, че нещо не е наред с вашите CSS правила като цяло и че вашият CSS не е добре структуриран. CSS с много!importantправилата могат лесно да се злоупотребяват и завършват с разхвърлян и трудно поддържан CSS код. - Не използвайте селектор за деца. Това правило споделя същите разсъждения като това на ID. Детските селектори са твърде специфични и са тясно свързани с вашата HTML структура.
Ако използвате! Важно много във вашия CSS, правите го погрешно. Tweet
Поддържайте правилата на Sass в ред
Важно е да запазите последователност в кода. Едно от правилата е, че трябва да спазвате реда на правилата. По този начин други разработчици могат да четат кода с много повече разбиране и ще отделят по-малко време за намиране на пътя. Ето предложената поръчка:
- Използвайте
@extendпърво. Това ви уведомява отначало, че този клас наследява правила от другаде. - Използвайте
@includeследващия. Включването на вашите миксини и функции отгоре е приятно да имате, а също така ви позволява да знаете какво ще презапишете (ако е необходимо). - Сега можете да напишете вашите редовни правила за CSS клас или елемент.
- Поставете вложени псевдо класове и псевдо елементи преди всеки друг елемент.
- И накрая, напишете други вложени селектори, както в следния пример:
.homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ‘’; } a { } ul { } } Някои конвенции за именуване
Конвенциите за именуване част от стиловата книга се основава на двете съществуващи ДОБРЕ и SMACSS конвенции за именуване, станали популярни сред разработчиците. BEM означава блок, елемент, модификатор. Той е разработен от екипа на YANDEX и идеята зад BEM е да помогне на разработчиците да разберат връзката между HTML и CSS в проекта. SMACSS от друга страна означава Scalable и Modular Architecture за CSS. Това е ръководство за структуриране на CSS, за да се осигури поддържаемост.
Вдъхновени от тях, нашите правила за конвенции за именуване са както следва:
- Използвайте префикс за всеки тип елемент. Префиксирайте блоковете си, като: оформления (
l-), модули (m-) и състояния (is-). - Използвайте две долни черти за дъщерни елементи за всеки блок:
.m-tab__icon {} - Използвайте две тирета за модификатори за всеки блок:
.m-tab--borderless {} Променливи
Използвайте променливи. Започнете с по-общите и глобални променливи като цветове и създайте отделен файл за тях _colors.scss Ако забележите, че повтаряте някаква стойност над таблицата със стилове няколко пъти, отидете и създайте нова променлива за тази стойност. Моля те СУХА . Ще сте благодарни, когато искате да промените тази стойност и когато ще трябва да я промените само на едно място.
Също така използвайте тире, за да назовете променливите си:
$red : #f44336; $secondary-red :#ebccd1; Заявки за медии
С Sass можете да пишете медийните си заявки като заявки за елементи. Повечето от разработчиците пишат медийни заявки в отделен файл или в долната част на нашите правила, но това не се препоръчва. С Sass можете да пишете неща като следния пример, като влагате медийни заявки:
// ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } } Това генерира CSS като този:
ролята на граничните корекции в международното данъчно облагане
// Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } } Тези вложени правила за медийни заявки ви позволяват да знаете много ясно какви правила презаписвате, както можете да видите във фрагмента на Sass, където се използват именосани медийни заявки.
За да създадете медийни заявки с име, създайте своя миксин по следния начин:
@mixin breakpoint($point) { @if $point == tablet { @media (min-width: 768px) and (max-width: 1024px) { @content; } } @else if $point == phone { @media (max-width: 767px) { @content; } } @else if $point == desktop { @media (min-width: 1025px) { @content; } } } Можете да прочетете повече за именуването на медийни заявки в следните статии: Именуване на медийни заявки и Пишете по-добри медийни заявки със Sass .
Други съображения
В крайна сметка, ето някои други съображения, които също трябва да имате предвид и да следвате:
- Никога не пишете префикси на доставчици. Използвайте автопрефиксър вместо.
- Използвайте максимум три нива на дълбоко вложени правила. С повече от три вложени нива кодът ще бъде труден за четене и може би пишете глупав селектор. В крайна сметка пишете CSS код, за да се свържете с вашия HTML.
.class1 { .class2 { li { //last rules } } } - Не пишете повече от 50 реда вложен код: Или по-добре, не пишете повече от X реда вложен код. Настройте вашия собствен X, но 50 изглежда като добър лимит. Ако преминете тази граница, може би блокът с код няма да се побере в прозореца на вашия текстов редактор.
- Напишете основен файл, в който ще импортирате всичките си блокове, частици и конфигурации.
- Импортирайте първо доставчици и глобални зависимости, след това авторски зависимости, след това оформления, модели и накрая частите и блоковете. Това е важно, за да се избегне смесен внос и презаписване на правила, тъй като доставчикът и глобалните правила не могат да бъдат управлявани от нас.
- Не се притеснявайте и разбивайте кода си във възможно най-много файлове.
Заключение
Идеята зад това ръководство за стил е да ви даде съвет как да подобрите начина, по който пишете кода си Sass. Моля, имайте предвид, че дори и да не използвате Sass, предоставените съвети и правила в това ръководство за стил също са приложими и препоръчително да се следват, ако използвате Vanilla CSS или друг препроцесор. Отново, ако не сте съгласни с някое от правилата, променете правилото, за да отговаря на начина ви на мислене. В крайна сметка от вас и вашия екип зависи или да адаптирате това ръководство за стил, да използвате някакво друго ръководство за стил или да създадете изцяло ново. Просто дефинирайте ръководството и започнете да пишете страхотен код.
Свързани: * Изследване на SMACSS: Мащабируема и модулна архитектура за CSS *
