Blog

CSS frameworks + CSS reset : Gebruiken of afblijven?

Op het eerste zicht lijken CSS frameworks fantastisch voor webontwikkelaars. Sneller websites bouwen, IE-bugs automatisch elimineren en betere code schrijven. Sign me up please! Jammer genoeg blijken de beschikbare frameworks deze verwachtingen niet altijd in te lossen.

Wat zijn CSS frameworks?

CSS frameworks zijn eigenlijk niets meer dan stylesheets die je kan gebruiken als basis voor je nieuwe projecten. Iedereen die regelmatig websites bouwt heeft al wel eens gedacht dat hij op bepaalde momenten soortgelijke opmaak aan het schrijven was als in een vorig project. CSS frameworks trachten dit dubbel werk te vermijden door veel voorkomende opmaak in een basisstylesheet te stoppen.

Veel frameworks volgen onderstaande of soortgelijke opdeling:

  • typography.css voor tekstopmaak,
  • grid.css voor grid-based layouts of layouts met x-aantal kolommen
  • layout.css voor algemene opmaak
  • forms.css om formulieren een basisopmaak mee te geven

Ookal is deze indeling op zich fantastisch, je kan al meteen aanvoelen dat een framework waarvoor je vijf stylesheets moet includen vooraleer je werkelijk kan starten niet echt een lichtgewicht is. Wat mij vooral stoort aan het gebruik van een CSS framework is het feit dat er veel code aanwezig is die je misschien nooit zal gebruiken.

Wil je de opmaak van een website volledig onder controle hebben, dan is het bovendien noodzakelijk om de code van het gebruikte framework door en door te kennen. Dan spendeer ik persoonlijk liever mijn tijd aan het uitwerken van een eigen basistemplate die volledig aan mijn eigen wensen en gewoonten voldoet, maar meer daarover later.

Een van de bekendste frameworks voor CSS is Blueprint, maar ook YAML (Yet Another Multicolumn Layout) en Yahoo! UI Library CSS Foundation kennen veel volgelingen.

Blueprint CSS framework

Voordelen van CSS frameworks

De meeste CSS frameworks beloven dezelfde voordelen:

1. Sneller ontwikkelen (minder CSS en xHTML schrijven)

Wanneer iemand een framework door en door kent (zoals de makers ervan) dan zal de snelheidswinst inderdaad goed voelbaar zijn. Maar wanneer je moet instappen in een nieuw framework en gewend moet raken aan de conventies en gewoonten die iemand anders in de CSS-code stopt, dan is snelheidswinst nog veraf.

Wanneer ik een geavanceerd webontwerp omzet naar valide xHTML en CSS, dan heb ik hier gemiddeld zo’n acht uur werk aan. De meest routineuze taken (wat een framework dus zou opvangen) zoals het opdelen van de layout in verschillende kolommen en het voorzien van tekstopmaak duurt meestal niet veel langer dan een of twee uur. Daar zal ik dus al niet veel snelheidswinst op halen, zelfs al ken ik een framework door en door.

De meeste tijd kruipt nog steeds in het testen van een ontwerp in meerdere browsers en het uitzoeken waarom enfant terrible Internet Explorer 6 weer eens een padding dubbel telt of waarom een bepaalde div zelfs helemaal niet getoond wordt.

2. Normaliseren van code

Wanneer verschillende mensen in een groter team dankzij een framework op dezelfde manier CSS gaan schrijven, dan vormt dit inderdaad een groot voordeel. Het wordt makkelijker om voort te werken aan de code van een teamgenoot. Echter, dit kan ook zonder gebruik van een CSS framework opgelost worden door een interne stijlgids te gebruiken waarin de eigen conventies worden uitgeschreven. Zo beschikt een team eveneens over duidelijke CSS richtlijnen.

3. Optimale browsercompatibiliteit

Het is belangrijk dat een website er op elke browser en op elk systeem hetzelfde uitziet. Standaard passen verschillende browsers jammer genoeg hun eigen opmaakregels toe waardoor inconsistenties kunnen ontstaan. Bekijk zelf maar eens volgende pagina op Sixrevisions.com. Internet Explorer toont standaard geen ruimte aan de bovenkant van de paragraaf, terwijl Firefox dit wel doet. Resultaat: verschillen in de pagina’s. Het maakt niet uit welke van de twee browsers hier nu gelijk heeft, wat telt is dat de pagina’s verschillen en dat we hier een oplossing voor moeten vinden.

Browser inconsistentie

Frameworks kunnen hier een hulp bieden omdat ze vaak over een CSS-reset beschikken. Zo’n reset bestaat uit een aantal regels CSS-code waarin bijvoorbeeld padding en margin voor elk element worden gelijkgesteld, zodat hier geen verschillen meer in bestaan over browsers heen. Zelf ben ik een groot voorstander voor het gebruik van een goede CSS-reset, maar ook dit kan weer gebruikt worden zonder de overtollige balast van een CSS framework mee te trekken. Verderop in dit artikel bespreken we CSS resets in meer detail.

Nadelen van CSS frameworks

Voor mij zijn volgende nadelen de doorslaggevende factoren om zelf geen gebruik te maken van een CSS framework. Let op, frameworks kunnen nuttig zijn en zijn zonder twijfel goed onderbouwd. De mening die ik zelf hierover heb wil in geen geval zeggen dat frameworks slecht zijn. Ik tracht hier enkel duidelijk te maken waarom ik er zelf geen gebruik van maak. 

1. Je kent je code niet

Wanneer we jQuery gaan implementeren in een webontwerp om het interactiever te maken, dan is het erg belangrijk om bijvoorbeeld te weten hoe uw navigatie werd opgebouwd en hoe ze werd opgemaakt met CSS. Willen we de navigatie animeren, dan weten we perfect hoe we de menu-items moeten aanspreken of welke opmaak we moeten aanpassen, we hebben de xHTML én CSS-code namelijk zelf geschreven.

Niets is erger dan een framework te gebruiken om tijd te besparen, om dan te moeten ontdekken dat je tien keer langer bezig bent met uit te zoeken hoe het framework een bepaald element heeft opgemaakt.

2. Bugs from hell

Een ontwerp is nooit helemaal perfect en het is best mogelijk dat hier en daar een foutje opduikt. Ook CSS frameworks kunnen mogelijk bugs bevatten of zodanig geschreven zijn dat ze conflicteren met je eigen opmaak. Hoe tijdrovend en frusterend het soms kan zijn om eigen bugs te moeten oplossen, het is alleszins vele malen makkelijker en leuker dan bugs uit het werk van iemand anders te moeten vissen.

3. Je negeert het unieke van elk project

Elk project is uniek, althans dat vinden wij. Elke klant heeft unieke wensen waarvoor een even unieke oplossing moet geboden worden. In plaats van steeds dezelfde standaard templates of structuren te gebruiken uit een framework, gaan wij uit van de inhoud die een klant ons aanlevert. Op basis van die inhoud gaan wij op zoek naar het beste ontwerp om die inhoud zo goed mogelijk tot zijn recht te laten komen.

CSS resets

Internet Explorer die meer padding aan een element toekent dan Firefox, wat een soep. Daarom dienen we ervoor te zorgen dat deze verschillen verdwenen zijn voordat we onze pagina’s uitwerken. Hoe? Door gebruik te maken van een CSS-reset.

Een vaak toegepaste - maar eigenlijk te vermijden - universele CSS-selector is de volgende:

*

margin
0;
padding0

Dit stukje CSS code zal ervoor zorgen dat alle elementen dezelfde padding en marge krijgen op mee te beginnen. Jammer genoeg kent deze universele selector ook nadelen. Knoppen die er standaard netjes zouden uitzien, worden door deze stijlregel ook gereset waardoor ze er vaak op verschillende browsers niet consistent uitzien. Het gaat eigenlijk om een one-size-fits-all aanpak, terwijl bepaalde elementen op hun eigen manier gereset zouden moeten worden.

Een degelijke CSS-reset gebruiken is wat we willen doen. Mijn voorkeur gaat uit naar volgende CSS-reset van Eric Meyer, omdat hij zorgt voor basiscompatibiliteit over verschillende browsers heen, zonder daarbij onnoemelijk veel code te gaan toevoegen die ik niet nodig heb. Een goede CSS-reset gaat elementen individueel resetten, zoals op onderstaande schermafdruk te zien is. Een unordered list zal bijvoorbeeld list-style:none; toegekend krijgen om dit element gelijk te stellen over verschillende browsers heen. Zulke specifieke instellingen zijn niet mogelijk met de universele CSS-selector die hierboven vermeld stond.

Schermafdruk van dit project

Starten met de CSS-reset doe je heel eenvoudig door deze stylesheet als eerste in je webtemplate toe te voegen. Vanaf dat moment worden alle of de meeste verschillen tussen verschillende browsers weggewerkt en kan je zelf je opmaak gaan schrijven voor je pagina’s. Een uitgebreid artikel over CSS-resets kan je hier terugvinden.

Conclusie

Of je gebruik wenst te maken van een CSS-framework of niet hangt volledig van je eigen voorkeuren af. Zelf verkies ik om mijn eigen codebase te gebruiken en om hiermee een eigen basisframework te ontwikkelen. Zo ben ik er zeker van dat ik steeds snel gestart raak met een nieuw project én dat ik alle code zelf onder controle heb. Voor mij is het sop de kool niet waard. CSS-frameworks kunnen zeker nuttig zijn, maar enkel binnen bepaalde situaties en voor bepaalde projecten.

Om niet altijd hetzelfde werk te moeten overdoen en toch flexibel en snel te kunnen werken hergebruiken wij wel degelijk eenzelfde code base. Zo hebben we ondertussen een eigen workflow ontwikkeld met een eigen “framework”. Framework is hier een groot woord, aangezien we starten vanuit een redelijk kale xHTML strict template met hieraan een gekoppelde CSS-stylesheet en een CSS-reset. Ook staan telkens de terugkerende mappen (images, css, js) al klaar wanneer we aan een nieuw project beginnen werken.

Ons eigen framework
Een eenvoudige basistemplate

Wat is jullie ervaring met CSS-frameworks? Laat het hieronder weten, ik ben benieuwd!

About the author

Hi there! I'm a freelancer who can help you build a great application or website - yes, also for mobile devices. If you speak Dutch, check out my eBooks.

Hire me, whether it's to help you build your next project or to organize a workshop. I teach about web design + development in college and I'd be happy to put a workshop together for you.