Страхотен CSS подход към стиловите таблици на Sass като програма - CSS-LIVE
Страхотен CSS: Подход към Sass Style Sheets като програма
Страхотен CSS, моля
В гореспоменатата статия („Atomic OOBEMITSCSS“) обясних как маркирам компоненти (като използвам Pinterest като пример) и ги стилизирам по съответния начин. Продължавам да използвам тази публикация като удобно ръководство за всеки, който се интересува от нашата предна архитектура, която оттогава е преминала през пълномащабно тестване спрямо голяма библиотека от модели.
Един пример от статия на SitepointВ резултат на това бях изправен пред необходимостта да обясня тази система (и самия Sass) на хора с традиционно програмистско образование. Това ме накара да осъзная доколко системата за CSS архитектура, която описах, е програмна и базирана на класове. Затова искам да отделя малко време, за да му дам заслужено заглавие, от което не бих се срамувал, „Страхотен CSS “, и да го обясня по начин, който е малко по-близък до традиционните програмисти.
Тази публикация има три цели:
- Защитете @extend
- Представяме виГотин CSS (много по-лесен за произнасяне от " Atomic OOBEMITSCSS ")
- Говорете за мащабируем, модулен и базиран на клас подход към CSS
готин бутон
Е, нека да разгледаме как работи, използвайки примера на бутон (в края на краищата бутонът е CSS „здравей свят“):
Нека започнем с премахване на селектор с основен код за всеки бутон, използвайки леко променен синтаксис, подобен на BEM. Първата част от името му ще бъде обектът, към който се отнасяме (бутон или btn), а след двойното тире ще има модификатор (в този случай база, т.е. основа).Забележка : променливите се именуват по същия начин - типът на променливата в ролята на база (в примера по-долу това е цвят).
Това основнобутон е нашият клас бутон. Към това ще добавим всичко останало за всеки бутон, защотовсеки бутон е екземпляр на този клас. Всеки бутонен елемент е от тип "бутон", така че всички те имат общи характеристики (плътна линия, прозрачен фон и т.н.). Всеки бутон приема същите общи свойства и надгражда върху тях. Те не презаписват тези свойства, а добавят нови към тях. Всички те са бутони++, които наследяват свойствата на основния бутон. (Необходимо ли е да повторим същата идея по някакъв начин?)
А ето и тяхното използване:
Илюстрация на прототипно наследяване от You Don't Know JS: Тази ключова дума и прототипи на обектАко ги напишете по "готин" начин, всекикомпонент (hero, sidebar, global-nav) ще има свой собствен частичен .scss файл, където се създават екземпляри на клас за реална употреба. Може да изглежда така:
И така, какво ще кажете за миксините?
Може би се чудите защо вместо това не използвате @mixin? Нашият начин за разделяне на класове във файлове е по-близо до това, за което е проектиран и предназначен @extend. Можем да създадем миксини в класове мъничета, върху които стилизираме, и след това да използваме @extend, за да инстанцираме класове с тези стилове.
В защита на @extend
Използването на @extend ни позволява да намалим получения CSS файл и да направим кода по-чист, ако разбираме какво се случва (ние добавяме стилове, а не ги дублираме). Можете да спорите, че това не е проблем, има gzip - но не винаги можете да разчитате на gzip, защото може да нямате достъп до настройките на сървъра.
За да разберете и използвате @extends във ваша полза, трябва да разберете точно какво се случва и какви са основните разлики между @mixin и @extend. Ето един добър пример:
@mixin е катоstamping : създава дублиран блок със свойства, с незадължително допълнение под формата на предадени аргументи. @extendдобавя елемента, който разширявате, към блока със свойства. Все едно да кажеш „Да, и ___ “.
Това означава, че нашият окончателен CSS файл ще бъде по-малък, защото не повтаряме блока от код всеки път, когато се използва. С @extend можем просто да препращаме към свойства. @extend директивите са идеални за това! Тяхното логично предназначение е съвсем разумно.#teamExtend
Недостатъкът тук е, че не знаем къде е блокът със свойства, тъй като не правим ново копие на кодовия блок в директивата, а просто го наричаме източник на стил (поради което не можете да използвате @extend в медийни изрази). Но това няма значение, стига да следваме принципите на Cool CSS. Вие разширявате класовете мъничета в реално използваеми класове и работите с екземпляри на тези класове, докато директивите @mixin са запазени за друга цел. С тяхна помощ изграждаме кода в класовете мъничета, които след това разширяваме.
В случая на Cool CSS,миксините са подобни на конструкторите и се използват само в предварително изработени селектори.
Например, нека създадем миксин за бутони, за да улесним завършването на основните и допълнителни бутони въз основа на него:
И полученият CSS файл изглежда така:
Предимства
Разбира се, тази система има свой собствен характер и може да изглежда сложна за непосветените, но след като започнете да работите с нея, ще бъде страхотно да измисляте имена и да решавате архитектурни проблеми.
Сред предимствата:
- Гарантира, че кодът е организиран по такъв начин, че няма да има конфликти на специфичност и нищо няма да бъде предефинирано(вижте ITCSS) - което означава, че CSS става по-прост, по-ефективен и размерът на крайния CSS файл е по-малък.
- Системата за последователно именуване (BEM) поддържа екипа последователен и намалява объркването чрез общи правила.
- Системата е организирана, лесно поддържана и мащабируема
Напишете страхотен код и оставете Sass да ви помогне да реализирате най-смелите си идеи! 💁