Het werk van een front-end developer wordt vaak gedicteerd door technologische vooruitgang. De opkomst van HTML5, het ondersteunen van CSS3-properties en het gebruik van webfonts zijn typische zaken die de geëngageerde front-end developer het afgelopen jaar hebben beziggehouden. Ongetwijfeld belangrijke elementen die de kwaliteit van een website zienbaar kunnen verhogen. Toch zijn er dwingendere problemen die aangepakt kunnen worden in ons vakgebied.

Zowel HTML als CSS zijn eenvoudige en vergevingsgezinde talen. Deze laagdrempeligheid heeft geleid tot een exponentiële groei van het internet, maar heeft er ook voor gezorgd dat vele websites gebouwd worden met onleesbare, onstabiele en onbeheerbare code. Het blijk ook erg moeilijk om ons uit deze sleur los te rukken, want zelfs sites die de modernste technieken gebruiken zijn achter de schermen vaak één grote bende.

Naast een gezonde dosis zelfdiscipline om onze HTML en CSS bestanden werkbaar te houden is er een boeiendere evolutie die elke front-end developer kan ondergaan. Nog te vaak wordt er gedacht en ontwikkeld in functie van webpagina’s in plaats van websites. Het is dan ook vaak duidelijk merkbaar dat HTML en CSS ontwikkeld zijn per pagina en niet binnen het geheel van een site. Om dit te verhelpen is een kleine maar belangrijke mentale shift nodig.

Drie pijlers: consistentie, focus en overzicht

Een website start meestal bij de homepagina. Zo ook de ontwikkeling ervan. Vroeger kreeg ik een setje wireframes op m’n bureau die ik dan van A to Z afwerkte. De HTML voor de homepage werd geschreven, de wireframe werd opzij gelegd en de volgende pagina werd onderhanden genomen. Herbruikbare elementen werden van de homepage gekopieerd, de rest werd aangevuld met nieuwe code.

Hoe groter en complexer het project, hoe problematischer deze methode bleek. Bij de 25e wireframe was het vaak even zoeken of er al iets gelijkaardigs voor de site geschreven was. Daarnaast werden dezelfde elementen binnen een verschillende context vaak gewoon opnieuw geschreven (bv. een detail van een nieuwsitem en een nieuwsitem in een shortlist). Omdat deze elementen er op wireframe en in het design vaak aardig verschillend uitzien leek er ook geen nood aan structurele consistentie tussen beide elementen. Zeker niet wanneer er later nog aanpassingen volgden.

De bovenstaande screenshot geeft een vergelijking tussen een lijst van producten (links) en een product detail (recht) op de Apple site. Hoewel iedereen ondertussen wel weet wat semantiek inhoudt, valt het op dat op de product detail pagina er geen “product” klasse te bekennen valt.

Op de A List Apart-website zien we iets gelijkaardigs. De website draait rond artikels, maar een “article” klasse vinden we niet terug. Ook structureel en semantisch lijken de artikels op een detailpagina en in de shortlist amper op elkaar. Het zijn dus duidelijk niet alleen “de kleintjes” die hiermee te kampen hebben.

Wanneer wireframes van A tot Z, pagina per pagina, gebouwd worden is de consistentie vaak zoek. Het is lastig te onthouden wat er allemaal eerder gebouwd is en welke structurele vereisten er nu net aan een element gesteld werden.

Daarom besloten wij om onze methodiek te veranderen. In plaats van pagina’s te bouwen richten we ons nu op componenten. Er wordt gekeken welke varianten van een component in een set van wireframes zitten, deze worden samen uitgewerkt, en wanneer de componenten af zijn kunnen pagina's eenvoudig gebouwd worden.

Wat zijn componenten?

Een component is heel eenvoudig te omschrijven als een op zichzelf staand elementen binnen een website. Het is een directe HTML/CSS vertaling van een “design pattern”, een term die de laatste jaren een sterke opmars heeft gemaakt binnen het webwereldje. Een component is een element met een duidelijke functionele en semantische omschrijving die doorheen meerdere pagina’s en in meerdere contexten gebruikt kan worden.

Dit klinkt waarschijnlijk heel wat complexer dan het eigenlijk is. Praktische voorbeelden van componenten zijn bijvoorbeeld de hoofdnavigatie, notificatie berichten, breadcrumbs, downloadlinks … maar ook grotere elementen zoals een nieuwsitem of kalenderitem. Met een beetje goeie wil is een hele pagina vaak volledig op te delen in componenten. Veel van deze componenten zullen ook in andere delen van de site gebruikt kunnen worden, sommigen komen zelfs op elke pagina voor.

<div class="notification"> ... </div>

Wanneer je een component naar HTML vertaalt zijn er een aantal zaken waar je op kunt letten. Belangrijk is te onthouden dat HTML een semantische en structurele waarde heeft. Praktisch wil dit zeggen dat een component eigenlijk op elke pagina dezelfde structuur moet hebben, of op zijn minst een uniforme basisstructuur moet volgen. Het doel is om de HTML van een component zo consistent mogelijk te houden. Dit maakt het eenvoudig herbruikbaar en herkenbaar doorheen een hele site.

Een andere belangrijke opmerking is dat een component bijna altijd gekenmerkt wordt door één basiselement, en dus in de HTML steeds één root element heeft. Dit element wordt voorzien van een klasse die aanduidt om welk component het gaat. Dit strookt met het idee om semantiek toe te voegen door het gebruik van klassen (vergelijk met microformats). Consistent gebruik van deze namen veroorzaakt dan een zekere semantische waarde doorheen een website.

/* component ***************** */
.component { (CSS properties) }

Naar CSS toe is het vooral interessant om alle declaraties van een bepaald component mooi bij elkaar te plaatsen en eventueel te voorzien van een header (in een CSS comment). Zo zorg je ervoor dat de styling voor een bepaald component niet doorheen het hele CSS document verspreid staat en is het duidelijk wat de code is die een bepaald component opbouwt. Je vindt in de CSS dan ook een goed overzicht terug van eventuele varianten en contexten waarin een component wordt gebruikt.

Structurele varianten

Het is perfect mogelijk dat een component een aantal structurele varianten kent. Bij een nieuwsitem is het bijvoorbeeld zo dat dit in meerdere vormen kan verschijnen binnen een site. Soms als volledig item, soms als focus element, dan weer in een overzichtslijst … Los van de manier waarop het gevisualiseerd wordt en in welke context het verschijnt blijft het wel steeds hetzelfde component – en dus blijft de HTML-structuur onveranderlijk.

Het enige wat er in dit geval verandert is dat bepaalde subelementen zoals meta data, footer data of “lees verder” links geplaatst of verwijderd worden. Op de structuur van het component zou dit geen effect mogen hebben. Het is dan ook aangewezen om met een zo volledig mogelijke variant van een component te starten (in dit voorbeeld, het volledige nieuwsartikel) en voor vereenvoudigde versies enkel de subelementen weg te laten die niet nodig zijn.

Interessant aan deze werkwijze is dat ze je dwingt om vanuit een globaal beeld aan een site te starten en zo component per component uit te werken. In plaats van pagina’s bouw je componenten, die je dan daarna op de nodige pagina’s zal toevoegen. Eventueel nadeel voor HTML-puristen is dat je soms HTML-elementen overhoudt die niet noodzakelijk zijn voor het stijlen van de componenten en naar CSS en javascript evengoed weggelaten kunnen worden. In mijn ogen weegt dit helemaal niet op tegen consistentie, herkenbaarheid en herbruikbaarheid, maar hierover zijn de meningen duidelijk verdeeld.

Functionele varianten en design varianten

/* basis component */
<div class="notification"> ... </div>
/* varianten */
<div class="notification error"> ... </div>
<div class="notification tip"> ... </div>

Een component wordt niet gekenmerd door z’n uiterlijk, maar door functionele en structurele eigenschappen. Toch is het vaak zo dat er kleine functionele variaties en designvariaties kunnen voorkomen. De code hierboven illustreert dit. We hebben eerst een notificatie component gedefinieerd, daarna hebben we door het toevoegen van een tweede klasse op het basiselement een variant van onze component gecreëerd.

In het bovenstaand geval zien we voorbeelden van een error notificatie, een tip (hints voor de gebruiker bij een bepaalde handeling) en een alert. Alle drie de varianten zijn opgebouwd met dezelfde HTML en beschikken ook over een aantal standaard CSS-declaraties. Op basis van de variantklasse worden dan de typische stijlen voor elke variant toegepast.

/* component ***************** */
.component { (CSS properties) }
/* error */
.component.error { (overwrite properties) }

Een variant hoeft niet altijd een aangepaste stijl hebben, al zal dat doorgaans wel het geval zijn. Het nut van een variant is dan ook vooral semantisch. En zelfs wanneer het design van een variant erg sterk verschilt (denk bijvoorbeeld aan een carrousel) zal er toch steeds een klasse zijn die beide varianten bindt tot één component. Structureel zal een designvariant echter nooit verschillen van de basisvariant.

Een kleine moeilijkheid is vaak het kiezen van een basisvariant. Doorgaans neem je best de meest voorkomende, maar dat is niet altijd mogelijk. Een stelregel is om de designvariant te kiezen die het makkelijkst aan te passen valt naar de andere varianten (met andere woorden, de variant waarvan de CSS zo makkelijk mogelijk om te vormen is). Is er echt een enorm verschil tussen beide designs, dan is het aangeraden om beide varianten een extra klasse te geven en helemaal geen basisvariant te kiezen.

Contextgevoelige stijlen

Niet elk verschil in design hoeft te leiden tot een nieuwe variant. Wanneer een zeker component enkel en alleen binnen een bepaalde context een ander uiterlijk moet krijgen dan is het niet nodig een extra klasse toe te voegen, maar het design af te laten hangen van de context waarin het component voorkomt.

Hierboven staan twee dezelfde componenten. Beide elementen zijn een shortlist van nieuwsberichten. De linker shortlist komt enkel op de homepage voor, de rechter shortlist komt enkel voor in de rechterkolom van de site. De HTML structuur van beide componenten is dezelfde, de visualisatie verschilt enkel op basis van de context waarin de shortlist voorkomt.

/* component ***************** */
.component { (CSS properties) }
/* op homepage */
.homepage .component { (overwrite properties) }
/* in context section */
.context .component { (overwrite properties) }

Normaal gezien is het ook aangewezen om context-afhankelijke stijlen bij het component in de CSS te plaatsen. Enkel wanneer de pagina zo sterk afwijkt van de rest kan je besluiten om een apart blokje aan te maken voor alle gerelateerde stijlen aan een bepaalde pagina of context.

Conclusie

Echte regels zijn er niet te op te stellen voor het opdelen van een website in componenten. Het verschil tussen een variant, context of basiscomponent is ook niet altijd even duidelijk en valt niet te vatten in onweerlegbare regels. Maar oefening baart kunst en sinds ik de switch gemaakt heb is de kwaliteit van zowel de HTML als de CSS die ik oplever sterk gestegen. Deze consistentie heeft trouwens niet enkel voordelen voor de front-end developer zelf, maar wordt ook geappreciëerd door de implementators van de templates die consistente HTML zeker op prijs zullen stellen.

De overstap naar een component-gebaseerde werkwijze is eenvoudig te maken en levert eigenlijk al bij het eerste project voordelen op. Het vereist enkel een beetje discipline aan het begin van een project om niet meteen in de code te springen. Daarna loopt alles veel vlotter en zal het leiden tot duidelijkere, semantischere en beter beheerbaardere code.

• Home
• Artikelen
• Colofon