Sass Guidelines

Syntaxis en opmaak

Als u het mij vraagt, is het allereerste dat een stijlgids zou moeten doen, beschrijven hoe we willen dat onze code eruitziet.

Wanneer meerdere ontwikkelaars betrokken zijn bij het schrijven van CSS op dezelfde project(en), is het slechts een kwestie van tijd voordat een van hen de dingen op zijn eigen manier gaat doen. Coderichtlijnen die consistentie bevorderen, voorkomen dit niet alleen, maar helpen ook bij het lezen en bijwerken van de code.

We willen grofweg (schaamteloos geïnspireerd door CSS Guidelines):

• twee (2) spaties inspringen, geen tabs;
• idealiter 80 tekens brede regels;
• correct geschreven CSS-regels met meerdere regels;
• zinvol gebruik van witruimte.

// Yep
.foo {
  display: block;
  overflow: hidden;
  padding: 0 1em;
}

// Nope
.foo {
    display: block; overflow: hidden;

    padding: 0 1em;
}

// Omdat Sass indented-syntax deze coderingsstandaarden afdwingt
// Is er geen verkeerde manier om verder te gaan
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Tekenreeksen

Geloof het of niet, tekenreeksen spelen een vrij grote rol in zowel CSS- als Sass-ecosystemen. De meeste CSS-waarden zijn lengtes of identifiers, dus het is eigenlijk vrij cruciaal om u aan enkele richtlijnen te houden bij het omgaan met tekenreeksen in Sass.

Codering

Om mogelijke problemen met tekencodering te voorkomen, wordt het ten zeerste aanbevolen om UTF-8 codering te forceren in het hoofd stylesheet met behulp van de @charset richtlijn. Zorg ervoor dat dit het allereerste element van de stylesheet is en dat er geen karakter voor staat.

@charset 'utf-8';

@charset 'utf-8'

Aanhalingstekens

CSS vereist geen aanhalingstekens, zelfs niet die spaties bevatten. Neem bijvoorbeeld namen van lettertypen: het maakt niet uit of u ze tussen aanhalingstekens plaatst voor de CSS-parser.

Daarom vereist Sass ook geen aanhalingstekens voor tekenreeksen. Nog beter (en gelukkig, u zult toegeven), een tekenreeks tussen aanhalingstekens is strikt gelijk aan zijn niet-aangehaalde tweeling (bijv. 'abc' is strikt gelijk aan abc).

Dat gezegd hebbende, talen waarvoor tekenreeksen geen aanhalingstekens nodig hebben, zijn beslist een minderheid en daarom moeten tekenreeksen altijd worden omwikkeld met enkele aanhalingstekens (') in Sass (enkele is gemakkelijker te typen dan dubbel op qwerty toetsenborden). Naast consistentie met andere talen, waaronder JavaScript, de neef van CSS, zijn er verschillende redenen voor deze keuze:

• kleurnamen worden als kleuren behandeld als ze niet worden vermeld, wat tot ernstige problemen kan leiden;
• de meeste syntaxisaccentueerders zullen stikken in tekenreeksen zonder aanhalingstekens;
• het bevordert de algemene leesbaarheid;
• er is geen geldige reden om geen aanhalingstekens aan tekenreeksen toe te voegen.

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Tekenreeksen als CSS-waarden

Specifieke CSS-waarden (identifiers) zoals initial of sans-serif hoeven geen aanhalingstekens. Inderdaad, de verklaring font-family: 'sans-serif' zal stilletjes mislukken omdat CSS een identifier verwacht, geen tekenreeks tussen aanhalingstekens. Daarom citeren we die waarden niet.

// Yep
$font-type: sans-serif;

// Nope
$font-type: 'sans-serif';

// Okay I guess
$font-type: unquote('sans-serif');

// Yep
$font-type: sans-serif

// Nope
$font-type: 'sans-serif'

// Okay I guess
$font-type: unquote('sans-serif')

Daarom kunnen we een onderscheid maken tussen tekenreeksen die bedoeld zijn om te worden gebruikt als CSS-waarden (CSS-identifiers) zoals in het vorige voorbeeld, en tekenreeksen wanneer we vasthouden aan het gegevenstype Sass, bijvoorbeeld _map_sleutels.

Bij het eerste zetten we geen aanhalingstekens, maar het laatste zetten we tussen enkele aanhalingstekens.

Tekenreeksen met aanhalingstekens

Als een tekenreeks een of meer enkele aanhalingstekens bevat, zou men kunnen overwegen om het in plaats daarvan te omwikkelen met dubbele aanhalingstekens ("), om te voorkomen dat tekens binnen de tekenreeks ontsnappen.

// Okay
@warn 'You can\'t do that.';

// Okay
@warn "You can't do that.";

// Okay
@warn 'You can\'t do that.'

// Okay
@warn "You can't do that."

URL’s

URL’s moeten ook worden geciteerd, om dezelfde redenen als hierboven:

// Yep
.foo {
  background-image: url('/images/kittens.jpg');
}

// Nope
.foo {
  background-image: url(/images/kittens.jpg);
}

// Yep
.foo
  background-image: url('/images/kittens.jpg')

// Nope
.foo
  background-image: url(/images/kittens.jpg)

Getallen

In Sass is getal een gegevenstype dat alles omvat, van eenheidsloze getallen tot lengtes, looptijden, frequenties, hoeken enzovoort. Hierdoor kunnen berekeningen op dergelijke maatregelen worden uitgevoerd.

Nullen

Getallen moeten voorloopnullen weergeven voor een decimale waarde kleiner dan één. Geef nooit volgnullen weer.

// Yep
.foo {
  padding: 2em;
  opacity: 0.5;
}

// Nope
.foo {
  padding: 2.0em;
  opacity: .5;
}

// Yep
.foo
  padding: 2em
  opacity: 0.5

// Nope
.foo
  padding: 2.0em
  opacity: .5

Eenheden

Als het om lengtes gaat, mag een 0 waarde nooit een eenheid hebben.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

De meest voorkomende fout die ik kan bedenken met betrekking tot getallen in Sass, is te denken dat eenheden slechts tekenreeksen zijn die veilig aan een getal kunnen worden toegevoegd. Hoewel dat waar klinkt, is het zeker niet hoe eenheden werken. Beschouw eenheden als algebraïsche symbolen. In de echte wereld levert het vermenigvuldigen van 5 meter met 5 meter u bijvoorbeeld 25 vierkante meter op. Dezelfde logica is van toepassing op Sass.

Om een eenheid bij een getal op te tellen, moet u dit getal vermenigvuldigen met 1 eenheid.

$value: 42;

// Yep
$length: $value * 1px;

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Merk op dat het toevoegen van 0-lid van die eenheid ook werkt, maar ik zou liever de bovengenoemde methode aanbevelen, aangezien het toevoegen van 0-eenheid een beetje verwarrend kan zijn. Inderdaad, als u een getal probeert om te zetten naar een andere compatibele eenheid, zal het toevoegen van 0 niet werken. Daarover meer in dit artikel.

$value: 42 + 0px;
// -> 42px

$value: 1in + 0px;
// -> 1in

$value: 0px + 1in;
// -> 96px

$value: 42 + 0px
// -> 42px

$value: 1in + 0px
// -> 1in

$value: 0px + 1in
// -> 96px

Uiteindelijk hangt het er echt van af wat u probeert te bereiken. Houd er wel rekening mee dat het toevoegen van de eenheid als een tekenreeks geen goede manier is om verder te gaan.

Om de eenheid van een waarde te verwijderen, moet u deze delen door één eenheid van zijn soort.

$length: 42px;

// Yep
$value: $length / 1px;

// Nope
$value: str-slice($length + unquote(''), 1, 2);

$length: 42px

// Yep
$value: $length / 1px

// Nope
$value: str-slice($length + unquote(''), 1, 2)

Het toevoegen van een eenheid als tekenreeks aan een getal resulteert in een tekenreeks, waardoor extra bewerkingen op de waarde worden voorkomen. Het doorsnijden van het numerieke deel van een getal met een eenheid resulteert ook in een tekenreeks. Dit is niet wat u wilt. Gebruik lengtes, geen tekenreeksen.

Berekeningen

Numerieke berekeningen op het hoogste niveau moeten altijd tussen haakjes staan. Deze vereiste verbetert niet alleen de leesbaarheid aanzienlijk, het voorkomt ook enkele edge cases door Sass te dwingen de inhoud van de haakjes te evalueren.

// Yep
.foo {
  width: (100% / 3);
}

// Nope
.foo {
  width: 100% / 3;
}

// Yep
.foo
  width: (100% / 3)

// Nope
.foo
  width: 100% / 3

Magische getallen

“Magisch getal” is een oude schoolprogrammering term voor naamloze numerieke constante. Kortom, het is gewoon een willekeurig getal dat toevallig werkt™, maar het is niet gebonden aan een logische verklaring.

Onnodig te zeggen magische getallen zijn een plaag en moeten koste wat het kost worden vermeden. Als het u niet lukt om een redelijke verklaring te vinden waarom een getal werkt, voeg dan een uitgebreide opmerking toe waarin u uitlegt hoe u daar bent gekomen en waarom u denkt dat het werkt. Toegeven dat u niet weet waarom iets werkt, is nog steeds nuttiger voor de volgende ontwikkelaar dan dat hij moet uitzoeken wat er vanaf het begin aan de hand is.

/**
 * 1. Magisch nummer. Deze waarde is de laagste die ik kon vinden om de bovenkant van
 * `.foo` uit te lijnen met de ouder. Idealiter zouden we het op de juiste manier moeten repareren.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Magisch nummer. Deze waarde is de laagste die ik kon vinden om de bovenkant van
 * `.foo` uit te lijnen met de ouder. Idealiter zouden we het op de juiste manier moeten repareren.
 */
.foo
  top: 0.327em /* 1 */

Over het onderwerp heeft CSS-Tricks een geweldig artikel over magische getallen in CSS die ik u aanmoedig om te lezen.

Kleuren

Kleuren nemen een belangrijke plaats in in de CSS-taal. Natuurlijk wordt Sass een waardevolle bondgenoot als het gaat om het manipuleren van kleuren, meestal door een handvol krachtige functies.

Sass is zo handig als het gaat om het manipuleren van kleuren dat artikelen over dit onderwerp overal op internet een grote vlucht hebben genomen. Mag ik een paar teksten aanbevelen:

• How to Programmatically Go From One Color to Another
• Using Sass to Build Color Palettes
• Dealing with Color Schemes in Sass

Kleurformaten

Om kleuren zo eenvoudig mogelijk te maken, zou mijn advies zijn om de volgende voorkeursvolgorde voor kleurformaten te respecteren:

1. HSL-notatie;
2. RGB-notatie;
3. Hexadecimale notatie (kleine letters en afgekort).

CSS-kleurzoekwoorden mogen niet worden gebruikt, tenzij voor snelle prototyping. Het zijn inderdaad Engelse woorden en sommige zijn behoorlijk slecht in het beschrijven van de kleur die ze vertegenwoordigen, vooral voor niet-moedertaalsprekers. Bovendien zijn sleutelwoorden niet perfect semantisch; bijvoorbeeld grey is eigenlijk donkerder dan darkgrey, en de verwarring tussen grey en gray kan leiden tot inconsistent gebruik van deze kleur.

De HSL-weergave is niet alleen de gemakkelijkste voor het menselijk brein om te begrijpen ^{[citation needed]}, het maakt het ook voor schrijvers van stylesheets gemakkelijk om de kleur aan te passen door de tint, verzadiging en lichtheid individueel aan te passen.

RGB heeft nog steeds het voordeel dat het meteen zichtbaar is als de kleur meer blauw, groen of rood is. Daarom is het in sommige situaties misschien beter dan de HSL, vooral als het om puur rood, groen of blauw gaat. Hoewel het niet gemakkelijk is om uit de drie delen een kleur op te bouwen.

Ten slotte, hexadecimaal is bijna niet te ontcijferen voor de menselijke brein. Gebruik het alleen als laatste redmiddel als het moet.

// Yep
.foo {
  color: hsl(0, 100%, 50%);
}

// Also yep
.foo {
  color: rgb(255, 0, 0);
}

// Meh
.foo {
  color: #f00;
}

// Nope
.foo {
  color: #FF0000;
}

// Nope
.foo {
  color: red;
}

.foo
  color: hsl(0, 100%, 50%)

// Also yep
.foo
  color: rgb(255, 0, 0)

// Nope
.foo
  color: #f00

// Nope
.foo
  color: #FF0000

// Nope
.foo
  color: red

Wanneer u HSL- of RGB-notatie gebruikt, voeg dan altijd een enkele spatie toe na een komma (,) en geen spatie tussen haakjes ((, )) en inhoud.

// Yep
.foo {
  color: rgba(0, 0, 0, 0.1);
  background: hsl(300, 100%, 100%);
}

// Nope
.foo {
  color: rgba(0,0,0,0.1);
  background: hsl( 300, 100%, 100% );
}

// Yep
.foo
  color: rgba(0, 0, 0, 0.1)
  background: hsl(300, 100%, 100%)

// Nope
.foo
  color: rgba(0,0,0,0.1)
  background: hsl( 300, 100%, 100% )

Kleuren en variabelen

Als u een kleur meer dan eens gebruikt, slaat u deze op in een variabele met een betekenisvolle naam die de kleur vertegenwoordigt.

$sass-pink: hsl(330, 50%, 60%);

$sass-pink: hsl(330, 50%, 60%)

Nu bent u vrij om deze variabele te gebruiken waar u maar wilt. Als uw gebruik echter sterk gebonden is aan een thema, raad ik af om de variabele te gebruiken zoals hij is. Sla het in plaats daarvan op in een andere variabele met een naam die uitlegt hoe het moet worden gebruikt.

$main-theme-color: $sass-pink;

$main-theme-color: $sass-pink

Als u dit doet, wordt voorkomen dat het thema verandert in zoiets als $sass-pink: blue. Dit artikel legt goed uit waarom het belangrijk is om na te denken over uw kleurvariabelen.

Kleuren lichter of donkerder maken

Zowel lighten als darken-functies manipuleren de lichtheid van een kleur in de HSL-ruimte door toe te voegen aan of af te trekken van de lichtheid in de HSL-ruimte. In wezen zijn het niets anders dan aliassen voor de $lightness-parameter van de adjust-color functie.

Het punt is dat die functies vaak niet het verwachte resultaat opleveren. Aan de andere kant is de mix functie een leuke manier om een kleur lichter of donkerder te maken door deze te mengen met white of black.

Het voordeel van het gebruik van mix in plaats van een van de twee bovengenoemde functies is dat het geleidelijk naar zwart (of wit) gaat naarmate u het aandeel van de kleur verkleint, terwijl darken en lighten snel een kleur helemaal naar zwart of wit uitblaast.

Als u niet elke keer de mix-functie wilt schrijven, kunt u twee gebruiksvriendelijke functies tint en shading maken (die ook deel uitmaken van Compass) om hetzelfde te doen:

/// Maak een kleur iets lichter
/// @access public
/// @param {Color} $color - kleur om te kleuren
/// @param {Number} $percentage - percentage van `$color` in geretourneerde kleur
/// @return {Color}
@function tint($color, $percentage) {
  @return mix(white, $color, $percentage);
}

/// Een kleur iets donkerder maken
/// @access public
/// @param {Color} $color - kleur tot schaduw
/// @param {Number} $percentage - percentage van `$color` in geretourneerde kleur
/// @return {Color}
@function shade($color, $percentage) {
  @return mix(black, $color, $percentage);
}

/// Maak een kleur iets lichter
/// @access public
/// @param {Color} $color - kleur om te kleuren
/// @param {Number} $percentage - percentage van `$color` in geretourneerde kleur
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Een kleur iets donkerder maken
/// @access public
/// @param {Color} $color - kleur tot schaduw
/// @param {Number} $percentage - percentage van `$color` in geretourneerde kleur
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Lijsten

Lijsten zijn het Sass-equivalent van arrays. Een lijst is een platte gegevensstructuur (in tegenstelling tot maps) die bedoeld is om waarden van elk type op te slaan (inclusief lijsten die naar geneste lijsten leiden).

Lijsten dienen de volgende richtlijnen te respecteren:

• ofwel inline of multiregel;
• noodzakelijkerwijs op meerdere regels als deze te lang zijn om op een regel van 80 tekens te passen;
• tenzij gebruikt zoals het is voor CSS-doeleinden, altijd gescheiden door komma’s;
• altijd tussen haakjes gewikkeld;
• achterliggende komma als er meerdere regels zijn, niet als ze inline zijn.

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif);

// Yep
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
);

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif;

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif;

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,);

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif)

// Nope (not supported)
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
)

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,)

Gebruik altijd de meegeleverde API om nieuwe items aan een lijst toe te voegen. Probeer niet handmatig nieuwe items toe te voegen.

$shadows: (0 42px 13.37px hotpink);

// Yep
$shadows: append($shadows, $shadow, comma);

// Nope
$shadows: $shadows, $shadow;

$shadows: (0 42px 13.37px hotpink)

// Yep
$shadows: append($shadows, $shadow, comma)

// Nope
$shadows: $shadows, $shadow

In dit artikel, ga ik door een heleboel trucs en tips om lijsten correct te behandelen en te manipuleren in Sass.

Maps

Met Sass kunnen stylesheet-auteurs maps definiëren - de Sass-term voor associatieve arrays, hashes of zelfs JavaScript-objecten. Een map is een gegevensstructuur die sleutels aan waarden koppelt. Zowel sleutels als waarden kunnen van elk gegevenstype zijn, inclusief maps, hoewel ik het gebruik van complexe gegevenstypen als mapsleutels niet zou aanraden, al was het maar om gezond verstand te hebben.

Maps moeten als volgt worden geschreven:

• spatie na de dubbele punt (:);
• accolade openen (() op dezelfde regel als de dubbele punt (:);
• geciteerde sleutels als het tekenreeksen zijn (wat 99% van de gevallen vertegenwoordigt);
• elk sleutel/waarde-paar op zijn eigen nieuwe regel;
• komma (,) aan het einde van elke sleutel/waarde;
• achterliggende komma (,) op het laatste item om het gemakkelijker te maken om items toe te voegen, te verwijderen of opnieuw te ordenen;
• sluitende accolade ()) op zijn eigen nieuwe regel;
• geen spatie of nieuwe regel tussen accolade ()) en puntkomma (;).

Illustratie:

// Yep
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
);

// Nope
$breakpoints: ( small: 767px, medium: 992px, large: 1200px );

// Yep
$breakpoints: ('small': 767px, 'medium': 992px, 'large': 1200px,)

// Nope
$breakpoints: ( 'small': 767px, 'medium': 992px, 'large': 1200px )

// Nope
$breakpoints: (small: 767px, medium: 992px, large: 1200px,)

// Nope (since it is not supported)
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
)

Er zijn veel verhalen over Sass-maps, gezien hoe lang naar deze functie was verlangd. Hier zijn er 3 die ik aanbeveel: Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

CSS-regelset

Op dit punt is dit voornamelijk het herzien van wat iedereen weet, maar hier is hoe een CSS-regelset moet worden geschreven (tenminste, volgens de meeste richtlijnen, inclusief CSS Guidelines):

• gerelateerde selectors op dezelfde lijn; niet-gerelateerde selectors op nieuwe regels;
• de openingsaccolade ({) met een enkele spatie tussen de laatste selector;
• elke verklaring op zijn eigen nieuwe regel;
• een spatie na de dubbele punt (:);
• een puntkomma (;) aan het einde van alle verklaringen;
• de sluitende accolade (}) op zijn eigen nieuwe regel;
• een nieuwe regel na de sluitaccolade }.

Illustratie:

// Yep
.foo, .foo-bar,
.baz {
  display: block;
  overflow: hidden;
  margin: 0 auto;
}

// Nope
.foo,
.foo-bar, .baz {
    display: block;
    overflow: hidden;
    margin: 0 auto }

// Yep
.foo, .foo-bar,
.baz
  display: block
  overflow: hidden
  margin: 0 auto

// Nope
.foo,
.foo-bar, .baz
    display: block
    overflow: hidden
    margin: 0 auto

Naast die CSS-gerelateerde richtlijnen willen we letten op:

• lokale variabelen die worden verklaard vóór alle verklaringen, en vervolgens worden gescheiden van verklaringen door een nieuwe regel;
• mixin-aanroepen zonder @content die vóór een verklaring komen;
• geneste selectors komen altijd na een nieuwe regel;
• geneste selectors komen altijd na een nieuwe regel;
• geen nieuwe regel voor een sluitende accolade (}).

Illustratie:

.foo, .foo-bar,
.baz {
  $length: 42em;

  @include ellipsis;
  @include size($length);
  display: block;
  overflow: hidden;
  margin: 0 auto;

  &:hover {
    color: red;
  }

  @include respond-to('small') {
    overflow: visible;
  }
}

.foo, .foo-bar,
.baz
  $length: 42em

  +ellipsis
  +size($length)
  display: block
  overflow: hidden
  margin: 0 auto

  &:hover
    color: red

  +respond-to('small')
    overflow: visible

Verklaringsortering

Ik kan niet veel onderwerpen bedenken waar de meningen zo verdeeld zijn als ze zijn over het sorteren van declaraties in CSS. Concreet zijn er hier twee facties:

• vasthouden aan de alfabetische volgorde;
• verklaringen ordenen op type (positie, display, kleuren, lettertype, diversen…).

Er zijn voor- en nadelen voor beide manieren. Aan de ene kant is alfabetische volgorde universeel (althans voor talen die het Latijnse alfabet gebruiken), dus er is geen argument om de ene eigenschap voor de andere te sorteren. Het lijkt me echter buitengewoon raar om eigenschappen als bottom en top niet direct naast elkaar te zien. Waarom moeten animaties vóór het weergavetype verschijnen? Er zijn veel eigenaardigheden met alfabetische volgorde.

.foo {
  background: black;
  bottom: 0;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
  height: 100px;
  overflow: hidden;
  position: absolute;
  right: 0;
  width: 100px;
}

.foo
  background: black
  bottom: 0
  color: white
  font-weight: bold
  font-size: 1.5em
  height: 100px
  overflow: hidden
  position: absolute
  right: 0
  width: 100px

Aan de andere kant is het sorteren van eigenschappen op type volkomen logisch. Alle lettertypegerelateerde verklaringen worden verzameld, top en bottom worden herenigd en het lezen van een regelset voelt als het lezen van een kort verhaal. Maar tenzij u aan een aantal conventies houdt, zoals Idiomatic CSS, is er veel ruimte voor interpretatie op deze manier van doen. Waar zou white-space naartoe gaan: lettertype of weergave? Waar hoort overflow precies thuis? Wat is de eigendomsvolgorde binnen een groep (het kan alfabetisch zijn, oh de ironie)?

.foo {
  height: 100px;
  width: 100px;
  overflow: hidden;
  position: absolute;
  bottom: 0;
  right: 0;
  background: black;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  height: 100px
  width: 100px
  overflow: hidden
  position: absolute
  bottom: 0
  right: 0
  background: black
  color: white
  font-weight: bold
  font-size: 1.5em

Er is ook een andere interessante subboom van type-ordening genaamd Concentric CSS, die ook behoorlijk populair lijkt. Kortom, Concentric CSS vertrouwt op het box-model om een volgorde te definiëren: begint buiten, beweegt naar binnen.

.foo {
  width: 100px;
  height: 100px;
  position: absolute;
  right: 0;
  bottom: 0;
  background: black;
  overflow: hidden;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  width: 100px
  height: 100px
  position: absolute
  right: 0
  bottom: 0
  background: black
  overflow: hidden
  color: white
  font-weight: bold
  font-size: 1.5em

Ik moet zeggen dat ik zelf niet kan beslissen. Een recente peiling op CSS-Tricks heeft vastgesteld dat meer dan 45% van de ontwikkelaars hun verklaringen sorteert op type tegen 14% alfabetisch. Er zijn ook 39% die volledig willekeurig gaan, inclusief ikzelf.

Daarom zal ik in deze stijlgids geen keuze opleggen. Kies degene die u verkiest, zolang u maar consistent bent in al uw stylesheets (dus niet de willekeurige optie).

Selector nesten

Een specifieke functie die Sass biedt en die door veel ontwikkelaars overdreven wordt misbruikt, is selector nesten. Het nesten van selectors biedt een manier voor auteurs van stylesheets om lange selectors te berekenen door kortere selectors in elkaar te nestelen.

Algemene regel

Bijvoorbeeld de volgende Sass-nesten:

.foo {
  .bar {
    &:hover {
      color: red;
    }
  }
}

.foo
  .bar
    &:hover
      color: red

… zal deze CSS genereren:

.foo .bar:hover {
  color: red;
}

In dezelfde lijn is het sinds Sass 3.3 mogelijk om de huidige selectorreferentie (&) te gebruiken om geavanceerde selectors te genereren. Bijvoorbeeld:

.foo {
  &-bar {
    color: red;
  }
}

.foo
  &-bar
    color: red

… zal deze CSS genereren:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Deze methode wordt vaak gebruikt in combinatie met BEM-naamgevingsconventies om .block__element en .block--modifier selectors gebaseerd op de originele selector te genereren (dwz .block in dit geval).

Het probleem met het nesten van selectors is dat het de code uiteindelijk moeilijker maakt om te lezen. Men moet mentaal de resulterende selector berekenen uit de inspringingsniveaus; het is niet altijd even duidelijk wat de CSS zal worden.

Deze verklaring wordt meer waar naarmate selectors langer worden en verwijzingen naar de huidige selector (&) frequenter. Op een gegeven moment is het risico om het overzicht te verliezen en niet meer te kunnen begrijpen wat er aan de hand is zo groot dat het het niet waard is.

Om dergelijke situaties te voorkomen, hebben we een paar jaar geleden veel gesproken over de Inception-regel. Het raadde af om meer dan 3 niveaus diep te nesten, als verwijzing naar de film Inception van Christopher Nolan. Ik zou drastischer zijn en aanbevelen om * selector-nesten zoveel mogelijk te vermijden**.

Hoewel er duidelijk een paar uitzonderingen op deze regel zijn, zoals we in de volgende sectie zullen zien, lijkt deze mening behoorlijk populair te zijn. U kunt er meer in detail over lezen in Beware of Selector Nesting en Avoid nested selectors for more modular CSS.

Uitzonderingen

Om te beginnen is het toegestaan en zelfs aanbevolen om pseudo-klassen en pseudo-elementen in de initiële selector te nestelen.

.foo {
  color: red;

  &:hover {
    color: green;
  }

  &::before {
    content: 'pseudo-element';
  }
}

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

Het gebruik van selector-nesten voor pseudo-klassen en pseudo-elementen is niet alleen logisch (omdat het zich bezighoudt met nauw verwante selectors), het helpt ook om alles over een component op dezelfde plaats te houden.

Ook bij het gebruik van component-agnostische statusklassen zoals .is-active, is het prima om deze onder de componentselector te nesten om de zaken netjes te houden.

.foo {
  // …

  &.is-active {
    font-weight: bold;
  }
}

.foo
  // …

  &.is-active
    font-weight: bold

Last but not least, wanneer een element wordt gestileerd omdat het toevallig in een ander specifiek element zit, is het ook prima om nesten te gebruiken om alles over het component op dezelfde plaats te houden.

.foo {
  // …

  .no-opacity & {
    display: none;
  }
}

.foo
  // …

  .no-opacity &
    display: none

Zoals met alles, zijn de details enigszins irrelevant, consistentie is de sleutel. Als u zich volledig zeker voelt bij het nesten van selectors, gebruik dan selector nesten. Zorg er gewoon voor dat uw hele team het daar goed mee eens is.