Hyvän mittakaavan yhtenäisen ja luettavan CSS: n kirjoittaminen on haastava prosessi. Varsinkin kun tyylitaulukot ovat suurempia, monimutkaisempia ja vaikeampia ylläpitää. Yksi kehittäjien käytettävissä olevista työkaluista paremman CSS: n kirjoittamiseen ovat esiprosessorit. Esiprosessori on ohjelma, joka ottaa yhden tyyppisen datan ja muuntaa sen toisen tyyppiseksi dataksi, ja tapauksessamme CSS-esiprosessorit ovat esikäsittelykieliä, jotka käännetään CSS: ksi. CSS-esiprosessoreita on monia etupään kehittäjät suosittelemme ja käytämme, mutta tässä artikkelissa keskitymme Sassiin. Katsotaanpa mitä Sassilla on tarjottavanaan , miksi se on edullinen valinta muihin CSS-esiprosessoreihin verrattuna, ja miten aloittaa sen käyttö parhaalla mahdollisella tavalla.

Mikä on Sass ja miksi sinun pitäisi käyttää sitä?

Niille teistä, jotka eivät tiedä mikä on Sass, paras lähtökohta on käydä virallinen Sass-verkkosivusto . Sass on lyhenne sanoista Syntactically Awesome StyleSheets, ja se on CSS: n laajennus, joka lisää voimaa ja eleganssia peruskielelle.

Sassin (Syntactically Awesome StyleSheets) avulla CSS-koodisi on myös mahtava. Tweet

Sass on CSS-esiprosessori, jolla on paljon tehokkaita ominaisuuksia. Merkittävimmät ominaisuudet ovat muuttujat , ulottuu ja sekoituksia .

Muuttujat tallentavat tietoja, joita voidaan käyttää myöhemmin uudelleen, kuten värejä tai muita yleisesti käytettyjä arvoja. Laajennusten avulla voit luoda luokkia, jotka sallivat sääntöjen perimisen. Mixins, voit ajatella kuin 'toiminto'. Sassilla on myös muita hämmästyttäviä ominaisuuksia verrattuna muihin esiprosessoreihin, kuten logiikkalausekkeiden (ehdolliset ja silmukat) käyttö, mukautetut toiminnot, integrointi muiden kirjastojen kanssa, kuten Kompassi , ja paljon muuta. Pelkästään nämä ominaisuudet voivat auttaa sinua ja tiimiäsi olemaan tuottavampia ja kirjoittamaan lopulta paremman CSS: n.

Miksi tarvitset CSS-tyylioppaan

Valitettavasti edes esiprosessorit eivät pysty korjaamaan kaikkea ja auttamaan sinua kirjoittamaan hyvää CSS-koodia. Jokaisen kehittäjän kohtaama ongelma on, että nykyisistä verkkosovelluksista tulee yhä suurempia. Siksi koodin on oltava skaalautuva ja luettavissa, ja sitä on vältettävä spagettikoodi ja käyttämättömät linjat. Mainittujen ongelmien välttämiseksi tarvitaan jonkinlainen standardi tiimillesi päivittäisessä työssä. Mikä on spagettikoodi ja miten se tapahtuu? Spagettikoodi on nimi huonolle, hitaalle, toistuvalle ja lukukelvottomalle koodille. Kun tiimi kirjoittaa isoja sovelluksia ilman määriteltyjä ohjeita tai standardeja, jokainen kehittäjä kirjoittaa mitä tarvitsee ja miten haluaa. Myös kehittäjät kirjoittavat paljon virhekorjauksia, hotfix-korjauksia ja korjauksia, ja he kirjoittavat yleensä koodia, joka ratkaisee ongelman, mutta ei ole aikaa kirjoittaa koodi parhaalla mahdollisella tavalla. Näissä tilanteissa on hyvin tavallista päätyä moniin CSS-riveihin, joita ei enää käytetä missään sovelluksen sektorissa. Kehittäjillä ei ole tarpeeksi aikaa koodin puhdistamiseen, ja heidän on julkaistava korjaus mahdollisimman nopeasti. Toinen toistuva tilanne on, että korjata rikkoutuneet asiat nopeasti, kehittäjät käyttävät paljon !important -tuloksia, mikä johtaa erittäin hakkeroivaan koodiin, jota on vaikea ylläpitää, se johtaa paljon odottamattomiin käyttäytymismalleihin, ja se on korjattava myöhemmin. Kuten jo mainittiin, koodin kasvaessa tilanne vain pahenee.

Tämän artikkelin idea on jakaa sääntöjä, vinkkejä ja parhaita käytäntöjä paremman Sassin kirjoittamiseksi. Näiden Sass-vinkkien ja parhaiden käytäntöjen ryhmittelemistä voidaan käyttää Sass-tyylioppaana. Tämän tyylioppaan pitäisi auttaa kehittäjiä välttämään edellä mainittuja tilanteita. Säännöt on ryhmitelty loogisiin segmentteihin viittaamisen helpottamiseksi, mutta lopulta sinun on hyväksyttävä ja noudatettava niitä kaikkia. Tai ainakin suurin osa niistä.

Tyyliopas

Tämän tyylioppaan säännöt ja parhaat käytännöt hyväksytään kokemuksen perusteella, joka on tehty työskennellessä monien joukkueiden kanssa. Jotkut heistä tulevat kokeilusta vahingossa, ja toiset ovat innoittamana joitain suosittuja lähestymistapoja, kuten BEM. Joissakin säännöissä ei ole mitään erityistä syytä miksi ja miten ne asetettiin. Joskus menneen kokemuksen ainoa syy riittää. Esimerkiksi koodin luettavuuden varmistamiseksi on tärkeää, että kaikki kehittäjät kirjoittavat koodin samalla tavalla, joten on sääntö, että sulkeiden väliin ei sisälly välilyöntejä. Voimme väittää, onko parempi sisällyttää sulkeiden välinen tila vai ei. Jos luulet, että se näyttää paremmalta, kun sulkeissa on välilyöntejä, säädä tämä tyyliopas ja säännöt mieltymystesi mukaan. Loppujen lopuksi tyylioppaan päätavoitteena on määritellä säännöt ja tehdä kehittämisprosessista vakiomaisempi.

Tyylioppaan päätavoitteena on määritellä säännöt ja tehdä kehittämisprosessista vakiomaisempi. Tweet

Yleiset CSS-säännöt

Yleisiä sääntöjä tulisi aina noudattaa. Ne keskittyvät enimmäkseen siihen, miten Sass-koodi tulisi muotoilla, jotta koodi olisi johdonmukainen ja luettavissa:

• Käytä sisennykseen välilyöntejä sarkainten sijaan. Paras käytäntö on käyttää kahta välilyöntiä. Voit käydä oman pyhän sodan tällä vaihtoehdolla, ja voit määrittää oman sääntösi ja käyttää joko sarkaimia tai välilyöntejä tai mitä sinulle parhaiten sopii. On vain tärkeää määritellä sääntö ja noudattaa sitä samalla kun se on johdonmukaista.
• Lisää tyhjä rivi jokaisen lauseen väliin. Tämä tekee koodista ihmisen luettavamman, ja koodin kirjoittavat ihmiset, eikö?
• Käytä yhtä valitsinta riviä kohden:

selector1, selector2 { }

• Älä lisää välilyöntiä sulkeiden väliin.

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

• Käytä merkkijonoja ja URL-osoitteita yksittäisillä lainausmerkeillä:

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

• Lopeta kaikki säännöt puolipisteellä ilman välilyöntejä ennen:

selector { margin: 10px; }

Valitsijoita koskevat säännöt

Seuraavaksi noudatamme joukkoa sääntöjä, joita on käytettävä käsitellessäsi valitsimia:

• Vältä ID-valitsimien käyttöä. Tunnukset ovat liian tarkkoja ja niitä käytetään lähinnä JavaScript-toimintoihin.
• Vältä !important. Jos sinun on käytettävä tätä sääntöä, se tarkoittaa, että jokin on vialla CSS-säännöissäsi yleensä ja että CSS: lläsi ei ole rakenteita hyvin. CSS monilla !important Sääntöjä voidaan helposti käyttää väärin, ja ne voivat olla sotkuisia ja vaikeasti ylläpidettäviä CSS-koodeja.
• Älä käytä lapsen valitsinta. Tällä säännöllä on sama perustelu kuin henkilötunnuksella. Lapsivalitsimet ovat liian tarkkoja ja liittyvät tiiviisti HTML-rakenteeseen.

Jos käytät! Tärkeää paljon CSS: ssäsi, teet sen väärin. Tweet

Pidä Sass-säännöt järjestyksessä

On tärkeää, että koodi on johdonmukainen. Yksi sääntöistä on, että sinun on pidettävä sääntöjen järjestys. Tällä tavoin muut kehittäjät voivat lukea koodia ymmärtäväisemmin ja kuluttavat vähemmän aikaa tiensä löytämiseen. Tässä on ehdotettu järjestys:

1. Käytä @extend ensimmäinen. Tämä kertoi sinulle aluksi, että tämä luokka perii säännöt muualta.
2. Käytä @include Seuraava. Sekoitusten ja toimintojen sisällyttäminen ylhäältä on mukava saada ja antaa sinun myös tietää, mitä korvaat (tarvittaessa).
3. Nyt voit kirjoittaa tavallisen CSS-luokan tai elementin säännöt.
4. Sijoita sisäkkäiset pseudoluokat ja näennäiselementit ennen muita elementtejä.
5. Kirjoita lopuksi muut sisäkkäiset valitsimet, kuten seuraavassa esimerkissä:

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

Joitakin nimeämiskäytäntöjä

Tyylikirjan nimeämiskäytännöt perustuvat kahteen olemassa olevaan HYVÄ ja SMACSS kehittäjien suosittua nimeämiskäytäntöä. BEM on lyhenne sanoista Block, Element, Modifier. Sen on kehittänyt YANDEX-tiimi, ja BEM: n ideana oli auttaa kehittäjiä ymmärtämään HTML: n ja CSS: n suhdetta projektissa. SMACSS puolestaan ​​tarkoittaa CSS: n skaalautuvaa ja modulaarista arkkitehtuuria. Se on opas CSS: n rakentamiseen ylläpidettävyyden mahdollistamiseksi.

Niiden innoittamana nimeämiskäytäntömme ovat seuraavat:

• Käytä etuliitettä jokaiselle elementtityypille. Esi lisää lohkosi, kuten: asettelut (l-), moduulit (m-) ja tilat (is-).
• Käytä kahta alaviivaa alielementeille jokaisessa lohkossa:

.m-tab__icon {}

• Käytä kahta viivaa muokkaajille jokaiselle lohkolle:

.m-tab--borderless {}

Muuttujat

Käytä muuttujia. Aloita yleisemmillä ja globaaleilla muuttujilla, kuten väreillä, ja luo niille erillinen tiedosto _colors.scss. Jos huomaat toistavan jonkin arvon tyylitaulukon yli useita kertoja, siirry ja luo uusi muuttuja tälle arvolle. Ole kiltti KUIVA . Olet kiitollinen, kun haluat muuttaa arvoa ja kun sinun on muutettava sitä vain yhdessä paikassa.

Nimeä muuttujat myös yhdysmerkillä:

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

Mediakyselyt

Sassin avulla voit kirjoittaa mediakyselysi elementtikyselyiksi. Suurin osa kehittäjistä kirjoittaa mediakyselyt erilliseen tiedostoon tai sääntöjemme alareunaan, mutta sitä ei suositella. Sassin avulla voit kirjoittaa esimerkiksi seuraavan esimerkin asioita pesemällä mediahakuja:

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

Tämä luo tällaisen CSS: n:

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

Tämän sisäkkäisen mediakyselysäännön avulla voit tietää hyvin selvästi, mitä sääntöjä korvataan, kuten näet Sass-katkelmasta, jossa käytetään nimettyjä mediakyselyjä.

Jos haluat luoda nimettyjä mediakyselyjä, luo sekoitus näin:

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

Voit lukea lisää mediakyselyjen nimeämisestä seuraavista artikkeleista: Mediakyselyjen nimeäminen ja Kirjoita parempia mediakyselyjä Sassin avulla .

Muut näkökohdat

Lopuksi tässä on joitain muita näkökohtia, jotka sinun tulisi myös pitää mielessä ja noudattaa:

• Älä koskaan kirjoita toimittajan etuliitteitä. Käyttää automaattinen korjaus sen sijaan.
• Käytä enintään kolmea syvälle sisäkkäisten sääntöjen tasoa. Yli kolmella sisäkkäisellä tasolla koodia on vaikea lukea, ja ehkä kirjoitat huono valitsin. Loppujen lopuksi kirjoitat CSS-koodia pariksi HTML-koodisi kanssa.

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

• Älä kirjoita yli 50 riviä sisäkkäistä koodia: Tai parempi, älä kirjoita enemmän kuin X riviä sisäkkäistä koodia. Asenna oma X, mutta 50 näyttää hyvältä rajalta. Jos ylität tämän rajan, koodilohko ei ehkä sovi tekstieditori-ikkunaan.
• Kirjoita päätiedosto, johon tuot kaikki lohkot, osiot ja kokoonpanot.
• Tuo ensin toimittajan ja globaalit riippuvuudet, sitten kirjoitetut riippuvuudet, sitten ulkoasut, mallit ja lopuksi osat ja lohkot. Tämä on tärkeää, jotta vältetään seka tuonti ja sääntöjen korvaaminen, koska me emme voi hallita myyjä- ja globaaleja sääntöjä.
• Älä ole ujo ja hajota koodisi mahdollisimman monessa tiedostossa.

Johtopäätös

Tämän tyylioppaan idea on antaa sinulle neuvoja Sass-koodisi kirjoittamistavan parantamiseksi. Muista, että vaikka et käyttäisikään Sassia, tämän tyylioppaan antamat vinkit ja säännöt ovat myös voimassa ja suositeltavia noudattamaan, jos käytät Vanilla CSS: ää tai muuta esiprosessoria. Jälleen kerran, jos et hyväksy mitään sääntöjä, muuta sääntö vastaamaan ajattelutapaa. Loppujen lopuksi sinun ja tiimisi on joko mukauttaa tämä tyyliopas, käyttää jotain muuta tyyliopasta tai luoda kokonaan uusi. Määritä vain opas ja aloita mahtavan koodin kirjoittaminen.

Liittyvät: * SMACSS: n tutkiminen: skaalautuva ja modulaarinen arkkitehtuuri CSS: lle *