CSS, BEM, SASS en een gootsteen

15-06-2017
Leestijd: 8 min.

Bij AlienTrick zijn we altijd op zoek naar manieren om efficiënter te werken: de koffie- en theeautomaat is precies zo afgesteld dat hij de juiste hoeveelheid heet water geeft, wat ervoor zorgt dat ik minder lang bezig ben om een kopje thee te pakken en meer tijd kan besteden aan het maken van awesome websites.

Zo zijn we ook op zoek gegaan naar technieken om het stylen van websites beter te laten verlopen en kwamen we terecht bij BEM en SASS. Weten hoe dit werkt? Ik geef je een voorbeeld van een slechte implementatie, gevolgd door een verbetering hiervan door er BEM en SASS op los te laten.

CSS

CSS-bestanden zorgen voor het uiterlijk van de website, oftewel de styling. Hoe ziet elk element eruit? En hoe zijn deze gepositioneerd ten opzichte van de andere elementen? Als voorbeeld nemen we twee knoppen onderaan zo’n uitklapbaar winkelwagentje. Dit is wat de bezoeker op de site ziet als hij in de winkelwagen kijkt:

Zonder al te veel in te gaan op wat de specifieke code doet, hebben we hier de HTML- (linker afbeelding) en CSS-codes (rechter afbeelding) voor deze twee knoppen:

 

Zoals je ziet is de code aardig lang en staat hij er twee keer in. Dit is een mooi voorbeeld van hoe je het niet moet doen en uiteraard deed ik het jaren geleden zelf ook zo.

BEM

Bij BEM gaat het er om dat je goed nadenkt over de benaming van je classes en dat deze logisch zijn opgevolgd. BEM staat voor Block Element Modifier en dit is het idee erachter:

- Een Block is een gedeelte of element op de site dat op zichzelf staat. Dit houdt in dat, ongeacht de plaatsing hiervan, de styling en functionaliteit hetzelfde is. Denk hierbij aan een header, een menu, een inputveld of een knop.

- Een Element is een onderdeel van een Block en heeft buiten dit Block niks te zoeken. Zo heb je bij een menu bijvoorbeeld verschillende menu items. Deze mogen niet op een willekeurige plaats op de site gezet worden als ze niet in een Block zitten.

- Een Modifier wijzigt de eigenschappen van een Element, zoals de grootte, het font of de kleuren. Een button zal bijvoorbeeld een standaard achtergrondkleur hebben die overeenkomt met de huisstijl van de website. Maar je moet uiteraard ook andere kleuren kunnen gebruiken. Hier kun je dan een Modifier voor schrijven die niks anders doet dan de achtergrondkleur van de knop veranderen.

We gaan de knoppen in ons winkelwagentje wat meer implementeren volgens BEM:

Qua hoeveelheid code lijkt dit nog niet echt een verbetering, maar het onderhoud is nu al een stuk makkelijker geworden. Beide buttons gebruiken nu de basisclass “button”. Als het dus om een of andere reden nodig is dat alle knoppen ineens een ander font moeten krijgen, dan is dit nu op één plaats aan te passen. Wanneer je BEM niet gebruikt dan zal je alle plekken in de styling op moeten zoeken om te kijken waar de styling van de button staat en zal je dit op al deze plekken moeten wijzigen.

We zien hier ook het gebruik van een Modifier, namelijk “button--red”. Wederom is het dankzij BEM makkelijk om nu bijvoorbeeld de rode kleur aan te passen. Je kan nu gewoon de kleur aanpassen die bij de Modifier staat ingesteld in plaats van dat je weer elke knop op moet zoeken die een rode kleur heeft.

SASS

In de basis schrijf je SASS-bestanden hetzelfde als een CSS-bestand. De SASS-bestanden worden daarna gecompileerd naar een CSS-bestand zodat deze door de website gebruikt kan worden voor de styling. Waarom zou je dan SASS gebruiken als er uiteindelijk toch een CSS-bestand uitkomt? Nou, omdat je met SASS namelijk nét iets meer kan. Enkele voordelen van SASS:

In CSS moet je elke selector apart schrijven. Zoals je kan zien in het BEM-voorbeeld hebben we voor de buttons de volgende selectors uitgeschreven: .button, .button:hover, .button__text, .button--red en .button--red:hover. Met SASS kun je “nesten”. Dit houdt in dat je binnen een selector een andere selector kunt schrijven en deze wordt dan tijdens het compilen omgezet naar twee losse selectors. In het SASS-bestand ziet het er dan zo uit, met daarnaast de gecompilede CSS:

Zoals je ziet heeft de compiler automatisch alle selectors voor ons geschreven.

De oplettende lezers onder ons zullen waarschijnlijk hebben gezien dat de CSS-regels van de .button niet één op één overeenkomen met de SASS-regels, maar dat er bij de regels display, justify-content en align-items meer regels in het CSS-bestand staan. Dit komt omdat de meeste SASS-compilers automatisch vendor prefixes toevoegen om te zorgen dat een bepaalde CSS-eigenschap in alle browsers werkt, mocht dit nodig zijn.

In SASS kun je ook gebruiken maken van variabelen. We kunnen dit bijvoorbeeld gebruiken bij de achtergrondkleuren voor de buttons. We zetten deze variabelen aan het begin van het bestand zodat ze makkelijk terug te vinden zijn, mochten ze aangepast moeten worden.

Deze variabelen ($primary-color en $secondary-color) bevatten nu dezelfde kleurcodes die we eerder aan de achtergrondkleur van onze buttons hebben gegeven. Als we dit nu in onze knoppen willen gebruiken schrijven we dat op deze manier:

Zoals ik eerder al had uitgelegd is het dankzij BEM heel makkelijk geworden om nu de rode kleur van de buttons aan te passen, omdat ze allemaal de Modifier “.button--red” gebruiken. Maar wat nu als we deze rode kleur ook in andere elementen gebruiken, zoals in een menu item? We kunnen deze niet de Modifier “.button--red” geven, omdat het geen knop is en je volgens BEM dan dus niet deze class mag gebruiken. Dus, deze kleur rood staat nu alsnog op meerdere plekken in de styling en als deze toch net iets anders moet worden dan moet je al die plekken afgaan. Door in plaats daarvan een variabele te gebruiken kun je nu op één plek deze kleur veranderen voor alle elementen die hem gebruiken. Dit is ook de reden dat we de variabele “secondary-color” hebben genoemd en niet bijvoorbeeld “red-color”. Het kan weleens gebeuren dat de kleur rood toch niet helemaal past binnen het ontwerp en het dus een compleet andere kleur moet worden. Dan klopt de naam van de variabele niet meer en als je dit dan weer wilt veranderen moet je weer al die plekken langs. Door dus een neutrale naam te gebruiken, maar eentje die wel aangeeft wat het idee achter de variabele is, kun je met één wijziging de hele styling van een site aanpassen.

Nog een van de leuke dingen is het feit dat je min of meer kan programmeren in SASS. Je kan functies aanroepen, berekeningen maken en nog veel meer. Een voorbeeld hiervan kun je al zien in het vorige screenshot. De achtergrondkleur van de hover selector voor de Modifier is gedefinieerd als “darken($secondary-color, 15)”. “Darken” is een speciale functie in SASS en is niet standaard te gebruiken in CSS. Deze functie neemt twee parameters aan, namelijk een kleur en een hoeveelheid waarmee deze kleur donkerder gemaakt moet worden. In dit geval dus de kleur die we in de variabele $secondary-color hebben opgeslagen en deze willen we dan vijftien procent donkerder hebben.

SASS heeft uiteraard nog veel meer handige functies en extra’s die je met standaard CSS niet hebt, maar om te zorgen dat dit geen handleiding voor SASS wordt, houd ik het hierbij.

Kitchen sink

Als laatste hebben we dan nog de kitchen sink of styleguide, zoals het ook weleens genoemd wordt (en natuurlijk gootsteen, maar dat is alleen voor mensen die denken dat ze een over ontwikkeld gevoel voor humor hebben). Het idee hierachter is dat er een pagina wordt gemaakt met alle standaardelementen voor de website erop. Dus bijvoorbeeld een tekstparagraaf, tussenkopjes, links, knoppen, formulierelementen, paginatie, lijstjes, tabellen, etc. Hieronder zie je een voorbeeld van een kitchen sink:

De bedoeling is dat de kitchen sink wordt opgezet voordat er aan de implementatie van de site wordt begonnen. Deze kan dan namelijk gebruikt worden om de implementatie te versnellen, vooral als je met meerdere developers aan het werk bent. Heb je namelijk een element nodig, zoals bijvoorbeeld paginatie (onderaan te zien op de afbeelding), dan kun je de HTML uit het kitchen sink bestand pakken en deze op de juiste plek in de site zetten. Aangezien de styling hiervoor gewoon in de algemene bestanden staat, ziet het er meteen uit zoals het ontworpen is. Uiteraard kom je tijdens het implementeren weleens elementen tegen die nog niet in de kitchen sink staan, maar deze mogen dan gewoon toegevoegd worden zodat je deze hier later weer makkelijk vandaan kunt pakken.

Conclusie

Ons vakgebied verandert continu. Er worden steeds nieuwe technieken ontwikkeld en iets dat vorige maand ‘cutting edge technology’ was, kan nu alweer achterhaald zijn. Daarom is het belangrijk om methodes en technieken te vinden die relevant blijven en zo ons werk makkelijker maken, wat weer resulteert in een beter product voor een blije klant. Ik ben zelf van mening dat BEM, SASS en het gebruik van een kitchen sink lang relevant zullen blijven, dus we gaan er graag mee door. En het klinkt ook gewoon leuk om tegen een collega te zeggen dat hij voor een bepaald element maar even in de gootsteen moet kijken 😉



 
< Terug naar overzicht Actueel

 

AlienTrick
Oosterveldsingel 51
7558 PJ Hengelo (O)
Nederland

[T] +31 74 76 20 200

[E] info@alientrick.com