Sass Guidelines

Syntaks & formatering

Hvis du spørger mig, så er noget af det allerførste en styleguide bør gøre, er at beskrive måden hvordan vi vil have vores kode til at se ud.

Når flere udviklere er involveret i at skrive CSS på de(t) samme projekt(er), så er det kun et spørgsmål om tid før en af dem begynder at gøre tingene på deres egen måde. Retningslinjer for kode, der fremmer konsistens, er ikke blot med til at undgå dette, men hjælper også når det kommer til at læse og opdatere koden.

Groft sagt, så ønsker vi (skamløst inspireret af CSS Guidelines):

• indentering á to (2) mellemrum, ingen tabs;
• 80-karakterer brede linjer, ideelt set;
• ordentligt skrevede, multi-linje CSS-regler;
• meningsfuld brug af whitespace.

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

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

    padding: 0 1em;
}

// Since Sass indented-syntax forces those coding standards
// There is no wrong way of proceeding
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Vi vil ikke tackle spørgsmålet omkring filorganisering i denne sektion. Det er formålet for en anden sektion.

Strenge

Tro det eller ej, så spiller strenge en ret stor rolle i økosystemerne for både CSS og Sass. De fleste CSS-værdier er enten længder eller strenge (ofte uciterede), så det er faktisk ret vigtigt at holde sig til nogle retningslinjer når man arbejder med strenge i Sass.

Encoding

For at undgå potentielle problemer med karakter-encoding, så anbefales det kraftigt at tvinge UTF-8 encoding i hoved-stylesheetet ved at anvende @charset direktivet. Vær sikker på at det er det allerførste element i stylesheetet, og at der ikke er nogen form for karakterer før det.

@charset 'utf-8';

@charset 'utf-8'

Citationstegn

CSS kræver ikke at strenge bliver citerede, ikke engang dem der indeholder mellemrum. Tag font-family navne som eksempel: for CSS parseren gør det ingen forskel hvorvidt du pakker dem ind i citationstegn.

På grund af det, så kræver Sass heller ikke at strenge citeres. Endnu bedre er (og heldigvis, vil du nok indrømme), at en citeret streng er fuldstændig den samme som dens uciterede tvilling (f. eks. er 'abc' fuldstændig det samme som abc).

Med det sagt, så er sprog der ikke kræver at strenge bliver citeret klart en minoritet, og derfor bør strenge altid indpakkes i enkelte citationstegn (') i Sass (enkelte citationstegn er nemmere at taste end dobbelte på qwerty tastaturer). Foruden konsistens med andre sprog, inklusiv CSS’ kusine JavaScript, er der flere grunde bag dette valg:

• farvenavne behandles på samme måde som uciterede farver, hvilket kan lede til alvorlige problemer;
• de fleste syntax highlighters får sure opstød af uciterede strenge;
• det hjælper med generel læsbarhed;
• der er ingen god grund til ikke at citere strenge.

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Strenge som CSS værdier

Specifikke CSS værdier, såsom initial eller sans-serif kræver ikke at blive citeret. Det er klart, at font-family: 'sans-serif' vil fejle i stilhed fordi CSS forventer en identifier og ikke en citeret streng. På grund af dette, så citerer vi ikke disse værdier.

// 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')

Dermed kan vi lave en distinktion mellem strenge der har til hensigt at blive brugt som CSS værdier (CSS identifiers), som i det forrige eksempel, og strenge der holder sig til Sass’ datatype, som for eksempel map-nøgler.

Vi citerer ikke den førstnævnte, men vi indpakker den sidstnævnte i enkelte citationstegn.

Strenge der indeholder citationstegn

Hvis en streng indeholder en eller flere citationstegn, så kan man overveje at indpakke strengen i dobbelte citationstegn (") i stedet, for at undgå at escape for mange karakterer inden i strengen.

// 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’er

URL’er bør også blive citeret af de samme grunde som ovenfor:

// 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)

Videre læsning:

• All You Ever Need to Know About Sass Interpolation
• SassyStrings

Tal

I Sass er tal en datatype der inkluderer alt lige fra enhedsløse numre til længder, varigheder, frekvenser, vinkler og så videre. Dette tillader udførelse af udregninger på sådanne målinger.

Nuller

Tal bør vise foranstillede nuller før en decimalværdi, der er mindre end et. Vis aldrig efterstillede nuller.

// 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

Enheder

Når du arbejder med længder, så bør en værdi af 0 aldrig have en enhed.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

Den mest typiske fejl jeg kan komme i tanke om, i relation til tal i Sass, er at tænke på enheder som kun værende strenge der trygt kan tilføjes til et tal. Selvom det lyder sandt, så er det absolut ikke sådan enheder virker. Tænk på enheder som algebraiske symboler. For eksempel, som i den virkelig verden, hvis du ganger 5 tommer med 5 tommer så får du 25 kvadrattommer. Den samme logik gælder ved Sass.

For at tilføje en enhed til et tal, så er du nødt til at gange dette tal med 1 enhed.

$value: 42;

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

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Bemærk at tilføjelse af 0 medlem af samme enhed også virker, men jeg vil hellere anbefale den førnævnte metode, siden 0 enhed kan være en anelse forvirrende. Det er klart, at når man forsøger at konvertere et tal til en anden kompatibel enhed, så vil tilføjelse af 0 ikke være nok.

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

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

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

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

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

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

Når alt kommer til alt, så afhænger det af hvad du forsøger at opnå. Bare hold det i tankerne, at tilføjelse af en enhed til en streng ikke altid er en god fremgangsmåde.

For at fjerne en værdis enhed, så er du nødt til at dividere den med en enhed af dets slags.

$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)

Tilføjelse af en enhed som en streng til et tal resulterer i en streng, hvilket forhindrer enhver yderligere operation på værdien. At opdele den numeriske del af et tal med en enhed resulterer også i en streng. Dette er ikke hvad du ønsker.

Kalkulationer

Numeriske kalkulationer på top-niveau bør altid indpakkes i paranteser. Ikke alene forbedrer dette krav læsbarheden dramatisk, det forhindrer også særtilfælde ved at tvinge Sass til at evaluere indholdet af paranteserne.

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

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

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

// Nope
.foo
  width: 100% / 3

Magiske tal

“Magiske tal” er et old school programmeringsterm for unavngivne numeriske konstanter. Basalt set, så er det et tilfældigt tal der bare virker™, dog uden at være forbundet til nogen logisk forklaring.

Selvfølgelig er magiske tal en plage og bør undgås for enhver pris. Når du ikke kan finde en fornuftig forklaring for hvorfor et tal virker, så tilføj en uddybende kommentar der forklarer hvordan du er nået hertil, og hvorfor du tror det virker. At indrømme at du ikke ved hvorfor noget virker er stadig mere hjælpsomt for den næste udvikler, end at få dem til regne ud hvad det er der sker fra bunden af.

/**
 * 1. Magic number. This value is the lowest I could find to align the top of
 * `.foo` with its parent. Ideally, we should fix it properly.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Magic number. This value is the lowest I could find to align the top of
 * `.foo` with its parent. Ideally, we should fix it properly.
 */
.foo
  top: 0.327em /* 1 */

Videre læsning:

• Use Lengths, Not Strings
• Correctly Adding Unit to Number
• Magic Numbers in CSS
• Sassy-Math

Farver

Farver har en vigtig plads i CSS-sproget. Sass bliver derfor naturligt en værdifuld allieret når det kommer til manipulation af farver, mest fordi det giver os en håndfuld kraftfulde funktioner.

Farveformater

For at holde farver så simple som muligt, så vil mit råd være at respektere den følgende rækkefølge for farveformater:

1. CSS farve-nøgleord;
2. HSL notation;
3. RGB notation;
4. Hexadecimal notation. Små bogstaver og forkortet, hvis muligt, er at foretrække.

Som udgangspunkt, så taler nøgleord ofte for sig selv. HSL-repræsentationen er ikke kun den nemmeste for den menneskelige hjerne at forstå ^{[citation mangler]}, den er også nemmere for forfattere af stylesheets når det kommer til at fintune farven ved at justere nuance, mætning og lyshed hver for sig. RGB har stadig en fordel ved med det samme at vise om farven er mere en blå, en grøn eller en rød, men den gør det ikke nemmere at bygge en farve ud af de tre dele. Til sidst, så er hexidecimaler tættest på at være uforståeligt for det menneskelige sind.

// 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

Når man anvender HSL eller RGB, så tilføj altid et enkelt mellemrum efter et komma (,) og ingen mellemrum mellem paranteser ((, )) og indhold.

// 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% )

Farver og variabler

Når en farve anvendes mere end én gang, så gem den i en variabel med et meningsfuldt navn, der repræsenterer farven.

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

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

Du står dig nu frit for at anvende denne variabel hvorend du vil. Dog, hvis din brug er tæt koblet til et tema, så vil jeg fraråde at anvende variablen som den er. Gem den i stedet i en anden variabel med et navn der forklarer hvordan den bør bruges.

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

$main-theme-color: $sass-pink

Ved at gøre det på denne måde, forhindrer du at tema-ændringer fører til ting som $sass-pink: blue.

Lysning og mørkning af farver

Både lighten og darken er funktioner til manipulation af lysstyrken af en farve i HSL-rum ved at tilføje eller fratrække lysstyrken i HSL-rummet. Basalt set er de intet andet end aliaser for $lightness parametret af adjust-color funktionen.

Sagen er den, at disse funktioner ofte ikke giver det forventede resultat. På den anden side, så er mix funktionen en god måde at lysne eller mørkne en farve på, ved at mikse den med enten white eller black.

Fordelen ved at anvende mix i stedet for at en af de to førnævnte funktioner er, at det den vil progressivt gå mod sort (eller hvid) efterhånden som du reducerer farvens proportion, hvoraf darken og lighten hurtigt vil kaste en farve helt mod sort eller hvid.

Hvis du ikke ønsker at skrive mix funktionen hver gang, så kan du skabe to letanvendelige funktioner kaldet tint og shade (der også er en del af Compass), til at udføre den samme ting:

/// Slightly lighten a color
/// @access public
/// @param {Color} $color - color to tint
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function tint($color, $percentage) {
  @return mix(white, $color, $percentage);
}

/// Slightly darken a color
/// @access public
/// @param {Color} $color - color to shade
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function shade($color, $percentage) {
  @return mix(black, $color, $percentage);
}

/// Slightly lighten a color
/// @access public
/// @param {Color} $color - color to tint
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Slightly darken a color
/// @access public
/// @param {Color} $color - color to shade
/// @param {Number} $percentage - percentage of `$color` in returned color
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Videre læsning:

• A Visual Guide to Sass & Compass Color Functions
• How to Programmatically Go From One Color to Another
• Sass Color Variables That Don’t Suck
• Using Sass to Build Color Palettes
• Dealing with Color Schemes in Sass

Lister

Lister er Sass’ svar på arrays. En liste er en flad datastruktur (modsat maps), der har til hensigt at gemme værdier af enhver type (inklusiv lister, hvilket leder til indlejrede lister).

Lister bør respektere de følgende retningslinjer:

• enten indlejrede eller i flere linjer;
• nødvendigvis i flere linjer, hvis for lang til at passe ind i linje på 80-karakterer;
• medmindre brugt som den er til CSS formål, skal det altid være komma-separeret;
• altid indpakked i paranteser;
• efterstillede kommaer hvis flere linjer, ikke hvis indlejret.

// 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,)

Når du tilføjer nye artikler til en liste, så brug altid den medfølgende API. Forsøg ikke at tilføje nye artikler manuelt.

$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

Videre læsning:

• Understanding Sass lists
• SassyLists

Maps

Siden Sass 3.3 kan stylesheet forfattere definere maps — Sass-termet for et associativ array, hashes eller endda JavaScript objekter. Et map er en datastruktur til forbinde nøgler (der kan være af enhver datatype, inklusiv maps, selvom jeg ikke anbefaler det) til værdier af enhver type.

Maps bør altid blive skrevet som følgende:

• mellemrum efter kolon (:);
• åbnende klamme (() på samme linje som kolonet (:);
• citerede nøgler, hvis de er strenge (hvilket repræsenterer 99% af situationerne);
• hver nøgle/værdi par er på dets egen, nye linje;
• efterstillet komma (,) på den sidste artikel gør det lettere at tilføje, fjerne eller omarrangere artikler;
• afsluttende klamme ()) på hver sin, nye linje;
• intet mellemrum eller ny linje mellem en afsluttende klamme ()) og semikolon (;).

Illustration:

// 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,
)

Debugging af et Sass map

Hvis du nogensinde har følt dig fortabt, og tænkt hvilken skør magi der foregår i et Sass map, så fortvivl ikke, der stadig er en måde at blive reddet på.

@mixin debug-map($map) {
  @at-root {
    @debug-map {
      __toString__: inspect($map);
      __length__: length($map);
      __depth__: if(function-exists('map-depth'), map-depth($map), null);
      __keys__: map-keys($map);
      __properties__ {
        @each $key, $value in $map {
          #{'(' + type-of($value) + ') ' + $key}: inspect($value);
        }
      }
    }
  }
}

=debug-map($map)
  @at-root
    @debug-map
      __toString__: inspect($map)
      __length__: length($map)
      __depth__: if(function-exists('map-depth'), map-depth($map), null)
      __keys__: map-keys($map)
      __properties__
        @each $key, $value in $map
          #{'(' + type-of($value) + ') ' + $key}: inspect($value)

Hvis du er interesseret i at vide dybden af map’et, så tilføj følgende funktion. Mixin’en vil vise det automatisk.

/// Compute the maximum depth of a map
/// @param {Map} $map
/// @return {Number} max depth of `$map`
@function map-depth($map) {
  $level: 1;

  @each $key, $value in $map {
    @if type-of($value) == 'map' {
      $level: max(map-depth($value) + 1, $level);
    }
  }

  @return $level;
}

/// Compute the maximum depth of a map
/// @param {Map} $map
/// @return {Number} max depth of `$map`
@function map-depth($map)
  $level: 1

  @each $key, $value in $map
    @if type-of($value) == 'map'
      $level: max(map-depth($value) + 1, $level)

  @return $level;

Videre læsning:

• Using Sass Maps
• Debugging Sass Maps
• Extra Map functions in Sass
• Real Sass, Real Maps
• Sass Maps are Awesome
• Sass list-maps
• Sass Maps Plus
• Sassy-Maps
• Introduction to Sass Maps Usage and Examples

CSS Regelsæt

På dette tidspunkt, hvilket mest er en opsummering af hvad alle ved, men her er måden hvordan et CSS regelsæt bør blive skrevet (i det mindste ifølge de fleste retningslinjer, inklusiv CSS Guidelines):

• relaterede selektorer på samme linje; urelaterede selektorer på nye linjer;
• den åbnende klamme ({) har afstand fra den sidste selektor med et enkelt mellemrum;
• hver deklaration på dets egen, nye linje;
• et mellemrum efter kolonet (:);
• et efterstillet semikolon (;) ved enden af alle deklarationer;
• den afsluttende klamme (}) på sin egen, nye linje;
• en ny linje efter den afsluttende klamme }.

Illustration:

// 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

Ifølge disse CSS-relaterede retningslinjer, så ønsker vi at være opmærksomme på:

• at lokale variabler bliver deklareret før alle andre deklarationer, for derefter at have afstand til deklarationer via en ny linje;
• at mixin-kald uden nogen @content kommer efter enhver deklaration;
• at indlejrede selektorer altid kommer efter en ny linje;
• at mixin-kald med @content kommer efter enhver indlejret selektor;
• at der ikke er nogen ny linje før en afsluttende klamme (}).

Illustration:

.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

Videre læsning:

• Anatomy of a Ruleset

Sortering af Deklarationer

Jeg kan ikke komme på mange emner, hvor meninger er så splittede som de er når det kommer til sortering af deklarationer i CSS. Helt konkret, så er to fraktioner på spil her:

• at holde sig til den alfabetiske rækkefølge;
• at arrangere deklarationerne efter type (position, display, farver, skrifttype, diverse…).

Der er fordele og ulemper ved begge tilgange. På den ene side, så er alfabetisk sortering universelt (i det mindste for sprog, der anvender det latinske alfabet), så der er ikke noget argument om at sortere en egenskab efter en anden. Dog finder jeg det ekstremt mærkeligt ikke at se værdier som bottom og top lige ved siden af hinanden. Hvorfor skulle animationer komme før display-typen? Der er mange særheder ved en alfabetisk arrangering.

.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

På den anden side, giver arrangering af egenskaber efter type perfekt mening. Enhver skrifttype-relateret deklaration bliver samlet, top og bottom er genforenet, og at læse et regelsæt føles lidt ligesom at læse en kort historie. Men medmindre du holder til konventioner såsom Idiomatic CSS, så opstår der en masse plads til fortolkning ved denne måde. Hvor bør white-space være: font eller display? Hvor hører overflow til helt præcist? Hvad er rækkefølgen for egenskaber i en gruppe (det kunne være alfabetisk, ironisk nok)?

.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

Der findes også en helt anden, interessant underart af type-sortering kaldet Concentric CSS, der virker til også at være ret populær. Grundlæggende, så læner Concentric CSS sig op ad box-modellen for at definere en rækkefølge: den starter udefra og bevæger sig indad.

.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

For at tale for mig selv, så kan jeg ikke beslutte mig. En nylig afstemning på recent poll on CSS-Tricks konkluderede, at over 45% af udviklerne arrangerer deres deklarationer efter type imod 14%, der gør det alfabetisk. Dertil, så går 39% fuldstændig tilfældig til værks, inklusiv mig selv.

På grund af det, så vil jeg ikke pålægge dig et valg i denne styleguide. Vælg den tilgang du foretrækker, så længe du er konsistent gennem dine stylesheets (ikke den tilfældige tilgang, for eksempel).

Videre læsning:

• CSS Comb
• Concentric CSS
• Idiomatic CSS
• On Declaration Sorting
• Reduce File Size With CSS Sorting
• Poll Results: How Do You Order Your CSS Properties?

Indlejring af selektorer

En særlig funktionalitet som Sass giver, der bliver misbrugt alt for meget af mange udviklere er indlejring af selektorer. Indlejring af selektorer giver stylesheet forfattere en måde at beregne lange selektorer ved at indlejre kortere selektorer inde i hinanden.

Generel regel

For eksempel, så vil den følgende Sass indlejring:

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

.foo
  .bar
    &:hover
      color: red

… generere denne CSS:

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

På samme måde er det siden Sass 3.3 muligt at anvende den nuværende selektor-reference (&) til at generere avancerede selektorer. For eksempel:

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

.foo
  &-bar
    color: red

… vil generere denne CSS:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Denne metode anvendes ofte sammen med navnekonventionerne for BEM ti at generere .block__element og .block--modifier selektorer, baseret på den oprindelige selektor (f. eks. .block i dette tilfælde).

Problemet med indlejring af selektorer er at det i sidste ende gør koden sværere at læse. Man skal mentalt beregne den endelige selektor ud fra indenteringsniveauer; det er derfor ikke altid særlig åbenlyst hvad CSS’en vil ende ud som.

Dette udsagn bliver mere sandt efterhånden som selektorer og referencer til den nuværende selektor (&) bliver hyppigere. På dette tidspunkt bliver risikoen for at miste overblikket, og at være ude af stand til at forstå hvad der sker, så høj at det ikke er dét værd.

For at undgå en sådan situation, så undgår vi indlejring af selektorer så meget som muligt. Dog er der åbenlyst nogle få undtagelser til denne regel.

Undtagelser

Til at starte med, så er det tilladt og endda anbefalet at indlejre pseudo-klasser og pseudo-elementer inden i den indledende selektor.

.foo {
  color: red;

  &:hover {
    color: green;
  }

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

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

At anvende selektor-indlejring til pseudo-klasser og pseudo-elementer giver ikke alene mening (fordi det håndterer tæt relaterede selektorer), det hjælper også med at holde alt omkring et komponent på det samme sted.

Dertil, så når komponent-agnostiske tilstandsklasser såsom .is-active anvendes, så er det helt i orden at indlejre det under komponentets selektor for at holde tingene pæne.

.foo {
  // …

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

.foo
  // …

  &.is-active
    font-weight: bold

Sidst, men ikke mindst, så når et element styles fordi det eksisterer inden i et andet specifikt element, så er det også fint at bruge indlejring til at holde alt omkring komponentet på det samme sted.

.foo {
  // …

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

.foo
  // …

  .no-opacity &
    display: none

Når der arbejdes med uerfarne udviklere, så kan en selektor såsom .no-opacity & virke en anelse underlig. For at undgå enhver forvirring, så kan du bygge en meget kortfattet mixin, der transformerer denne underlige syntaks om til en eksplicit API.

/// Helper mixin to provide simple API to selector nesting
/// @param {String} $selector - Selector
@mixin when-inside($selector) {
  #{$selector} & {
    @content;
  }
}

/// Helper mixin to provide simple API to selector nesting
/// @param {String} $selector - Selector
=when-inside($selector) {
  #{$selector} &
    @content
}

Ved at genskrive vores tidligere eksempel, så vil det se ud som dette:

.foo {
  // …

  @include when-inside('.no-opacity') {
    display: none;
  }
}

.foo
  // …

  +when-inside('.no-opacity')
    display: none

Som med alting, så er det specifikke rimelig irrelevant, da det er konsistens der er det vigtige. Hvis du føler dig fuldstændig sikker på selektor-indlejring, så brug selektor-indlejring. Bare sikr dig, at hele dit team er med på det.

Videre læsning:

• Beware of Selector Nesting
• The Inception Rule
• Avoid nested selectors for more modular CSS