Å skrive konsistent og lesbar CSS som skaleres godt er en utfordrende prosess. Spesielt når stilarkene blir større, mer komplekse og vanskeligere å vedlikeholde. Et av verktøyene som er tilgjengelige for utviklere for å skrive bedre CSS, er forprosessorer. En forprosessor er et program som tar en type data og konverterer den til en annen type data, og i vårt tilfelle er CSS-forprosessorer forhåndsbehandlingsspråk som er kompilert til CSS. Det er mange CSS forprosessorer det front-end utviklere anbefaler og bruker, men i denne artikkelen vil vi fokusere på Sass. La oss se hva Sass har å tilby , hvorfor det er et foretrukket valg fremfor andre CSS-forprosessorer, og hvordan du begynner å bruke den på den beste måten.

Hva er Sass, og hvorfor bør du bruke det?

For de av dere som ikke vet hva som er Sass, er det beste utgangspunktet å besøke offisielle Sass-nettside . Sass er en forkortelse for Syntactically Awesome StyleSheets, og er en utvidelse av CSS som gir kraft og eleganse til grunnspråket.

Med Sass (Syntactically Awesome StyleSheets) vil CSS-koden din også være fantastisk. kvitring

Sass er en CSS-prosessor med mange kraftige funksjoner. De mest bemerkelsesverdige funksjonene er variabler , strekker , og mixins .

Variabler lagrer informasjon som kan brukes på nytt senere, som farger eller andre verdier som ofte brukes. Extends hjelper deg med å lage 'klasser' som tillater arv for reglene. Mixins, du kan tenke på som 'funksjon'. Sass har også noen andre fantastiske funksjoner i sammenligning med andre forprosessorer, som bruk av logiske utsagn (betingede og sløyfer), egendefinerte funksjoner, integrering med andre biblioteker som Kompass , og mange flere. Disse funksjonene alene kan hjelpe deg og teamet ditt til å bli mer produktive og til å skrive bedre CSS til slutt.

Hvorfor trenger du en CSS Style Guide

Dessverre, selv forprosessorer kan ikke fikse alt og hjelpe deg med å skrive god CSS-kode. Problemet hver utvikler står overfor er at nåværende webapplikasjoner blir større og større. Derfor må koden være skalerbar og lesbar, og må unngås spaghetti-kode og ubrukte linjer av den. For å unngå nevnte problemer er det nødvendig med en slags standard for teamet ditt i det daglige arbeidet. Hva er spaghettikode, og hvordan skjer det? Spaghetti-kode er et navn på dårlig, langsom, repeterende og uleselig kode. Når et team skriver store applikasjoner uten definerte retningslinjer eller standarder, skriver hver utvikler hva han trenger og hvordan han vil. Også når utviklere skriver mange feilrettinger, hurtigreparasjoner og oppdateringer, har de en tendens til å skrive kode som vil løse problemet, men ikke har tid til å skrive koden på den beste måten. I disse situasjonene er det veldig vanlig å ende opp med mange linjer med CSS som ikke brukes i noen sektor av applikasjonen lenger. Utviklere har ikke nok tid til å rense koden, og de blir tvunget til å publisere løsningen så raskt som mulig. En annen situasjon som er tilbakevendende er at for å fikse ødelagte ting raskt, bruker utviklere mye !important, noe som resulterer med veldig hacky kode som er vanskelig å vedlikeholde, det resulterer i mye uventet oppførsel, og må omformuleres senere. Som allerede nevnt blir situasjonen bare verre etter hvert som koden vokser.

Ideen med denne artikkelen er å dele regler, tips og beste fremgangsmåter for å skrive en bedre Sass. Å gruppere disse Sass-tipsene og beste praksis kan brukes som en Sass-stilveiledning. Denne stilveiledningen skal hjelpe utviklere med å unngå situasjoner som er nevnt ovenfor. Regler er gruppert i logiske segmenter for enklere referanse, men til slutt bør du vedta og følge dem alle. Eller i det minste de fleste av dem.

Stilguide

Regelsettet og beste praksis i denne stilveiledningen er vedtatt basert på erfaring med å jobbe med mange lag. Noen av dem kommer fra prøve ved en feiltakelse, og andre er inspirert av noen populære tilnærminger som BEM. For noen regler er det ingen spesifikk grunn til hvorfor og hvordan de ble satt. Noen ganger er det nok å ha tidligere erfaring som den eneste grunnen. For eksempel, for å sikre at koden er lesbar, er det viktig at alle utviklere skriver koden på samme måte. Dermed er det regelen å ikke inkludere mellomrom mellom parenteser. Vi kan argumentere for om det er bedre å inkludere mellomrommet mellom parentes eller ikke. Hvis du tror at det ser bedre ut når det er mellomrom mellom parentes, kan du justere denne stilguiden og reglene etter dine preferanser. Til slutt er hovedmålet med stilguiden å definere regler, og å gjøre utviklingsprosessen mer standard.

Hovedmålet med stilguiden er å definere regler, og å gjøre utviklingsprosessen mer standard. kvitring

Generelle CSS-regler

Generelle regler bør alltid følges. De er mest fokusert på hvordan Sass-koden skal formateres for å gi konsistens og lesbarhet av koden:

• For innrykk, bruk mellomrom i stedet for faner. Den beste fremgangsmåten er å bruke to mellomrom. Du kan kjøre din egen hellige krig med dette alternativet, og du kan definere din egen regel og bruke enten faner eller mellomrom, eller hva som helst som passer deg best. Det er bare viktig å definere en regel og følge den regelen mens du er konsistent.
• Inkluder en tom linje mellom hver uttalelse. Dette gjør koden mer menneskelig lesbar, og koden er skrevet av mennesker, ikke sant?
• Bruk en velger per linje, slik:

selector1, selector2 { }

• Ikke ta mellomrom mellom parenteser.

selector { @include mixin1($size: 4, $color: red); }

• Bruk enkle anførselstegn for å legge ved strenger og nettadresser:

selector { font-family: ‘Roboto’, serif; }

• Avslutt alle regler med semikolon uten mellomrom før:

selector { margin: 10px; }

Regler for velgere

Deretter følger vi med et sett med regler som skal brukes når vi arbeider med velgere:

• Unngå bruk av ID-velgere. ID-er er for spesifikke og brukes hovedsakelig til JavaScript-handlinger.
• Unngå !important. Hvis du trenger å bruke denne regelen, betyr det at noe er galt med CSS-reglene dine generelt, og at CSS ikke er godt strukturert. CSS med mange !important regler kan lett misbrukes og ender opp med rotete og vanskelig å vedlikeholde CSS-kode.
• Ikke bruk barnevalg. Denne regelen deler samme resonnement som ID-en. Barnevalg er for spesifikt og er tett kombinert med HTML-strukturen din.

Hvis du bruker! Viktig mye i CSS, gjør du det galt. kvitring

Hold Sass-reglene i orden

Det er viktig å holde konsistensen i koden. En av reglene er at du må holde rekkefølgen på reglene. På denne måten kan andre utviklere lese koden med mye mer forståelse, og vil bruke mindre tid på å finne veien rundt. Her er den foreslåtte rekkefølgen:

1. Bruk @extend først. Dette forteller deg først at denne klassen arver regler fra andre steder.
2. Bruk @include neste. Å ha mixins og funksjoner inkludert øverst er hyggelig å ha, og lar deg også vite hva du vil overskrive (om nødvendig).
3. Nå kan du skrive dine vanlige CSS-klasse- eller elementregler.
4. Plasser nestede pseudoklasser og pseudoelementer før andre element.
5. Til slutt, skriv andre nestede velgere som i følgende eksempel:

.homepage { @extend page; @include border-radius(5px); margin-left: 5px; &:after{ content: ‘’; } a { } ul { } }

Noen navnekonvensjoner

Å navngi konvensjoner som er en del av stilboka, er basert på de to eksisterende GOD og SMACSS navnekonvensjoner som ble populære blant utviklere. BEM står for Block, Element, Modifier. Den ble utviklet av YANDEX-teamet, og ideen bak BEM var å hjelpe utviklere med å forstå forholdet mellom HTML og CSS i prosjektet. SMACSS derimot står for Scalable and Modular Architecture for CSS. Det er en guide for å strukturere CSS for å tillate vedlikehold.

Våre navnekonvensjonsregler er inspirert av dem:

• Bruk prefiks for hver type element. Forhånds blokkene dine, som: layouts (l-), moduler (m-), og stater (is-).
• Bruk to understreker for underordnede elementer for hver blokk:

.m-tab__icon {}

• Bruk to bindestreker for modifikatorer for hver blokk:

.m-tab--borderless {}

Variabler

Bruk variabler. Start med de mer generelle og globale variablene som farger, og lag en egen fil for dem _colors.scss. Hvis du merker at du gjentar noen verdier over stilarket flere ganger, kan du lage en ny variabel for den verdien. Vær så snill TØRKE . Du vil være takknemlig når du vil endre den verdien, og når du bare trenger å endre den på ett sted.

Bruk også bindestrek for å nevne variablene dine:

$red : #f44336; $secondary-red :#ebccd1;

Mediespørsmål

Med Sass kan du skrive mediespørsmålene dine som elementspørsmål. De fleste av utviklerne skriver mediespørsmål i en egen fil eller nederst i reglene våre, men det anbefales ikke. Med Sass kan du skrive ting som følgende eksempel ved å hekke mediespørsmål:

// ScSS .m-block { &:after { @include breakpoint(tablet){ content: ''; width: 100%; } } }

Dette genererer en CSS som dette:

// Generated CSS @media screen and (min-width: 767px) { .m-block:after { content: ''; width: 100%; } }

Disse nestede mediespørringsreglene lar deg vite veldig tydelig hvilke regler du overskriver, slik du kan se i Sass-kodebiten der navngitte mediespørsmål brukes.

Hvis du vil opprette navngitte mediespørsmål, lager du mixin slik:

@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; } } }

Du kan lese mer om navngivning av mediespørsmål i følgende artikler: Navngi mediespørringer og Skriv bedre mediespørsmål med Sass .

Andre hensyn

Til slutt er det noen andre hensyn du også bør huske på og følge:

• Skriv aldri forhandlerprefikser. Bruk autofrefixer i stedet.
• Bruk maksimalt tre nivåer av dype i nestede regler. Med mer enn tre nestede nivåer vil koden være vanskelig å lese, og kanskje du skriver en skitten velger. Til slutt skriver du CSS-kode for å koble til HTML-en.

.class1 { .class2 { li { //last rules } } }

• Ikke skriv mer enn 50 linjer med nestet kode: Eller bedre, ikke skriv mer enn X linjer med nestet kode. Sett opp din egen X, men 50 ser ut som en god grense. Hvis du overskrider den grensen, vil kanskje ikke kodeblokken passe inn i tekstredigeringsvinduet.
• Skriv en hovedfil der du vil importere alle blokkene, delene og konfigurasjonene dine.
• Importer leverandør- og globale avhengigheter først, deretter forfatteravhengigheter, deretter oppsett, mønstre og til slutt delene og blokkene. Dette er viktig for å unngå blandet import og overskriving av regler, fordi leverandøren og de globale reglene ikke kan administreres av oss.
• Ikke vær sjenert og del koden din i så mange filer som mulig.

Konklusjon

Ideen bak denne stilguiden er å gi deg noen råd om hvordan du kan forbedre måten du skriver din Sass-kode på. Vær oppmerksom på at selv om du ikke bruker Sass, er tipsene og reglene i denne stilveiledningen også gjeldende og anbefalt å følge hvis du bruker Vanilla CSS eller en annen prosessor. Igjen, hvis du ikke er enig i noen av reglene, kan du endre regelen slik at den passer til din tankegang. Til slutt er det opp til deg og teamet ditt å enten tilpasse denne stilguiden, bruke en annen stilguide eller lage en helt ny. Bare definer guiden, og begynn å skrive en fantastisk kode.

I slekt: * Utforske SMACSS: Skalerbar og modulær arkitektur for CSS *