Weg met externe CSS bestanden - 07-02-2020


Inleiding

Iedereen die HTML en CSS kent, weet dat er verschillende mogelijkheden zijn om HTML op te maken.
- Style toevoegen in de HTML-objecten, via style="xxx". Inline genoemd.
- Style in de head declaren, via <style>xxx</style>. In de style kunnen objecten voorzien worden van een stijl, maar het kan ook flexibel, via classes of id's. Ook combi's zijn mogelijk. Intern genoemd.
- Style een extern bestand declareren (normaal gesproken een .css bestand). Die wordt in de head ingelezen. Feitelijk hetzelfde als de vorige, maar dan in een apart bestand getypt. Extern genoemd.

Alle drie mogelijkheden kunnen trouwens gelijktijdig worden toegepast. Als gelijke stylen voorkomen, geldt de volgende prio: inline, intern, extern.

In dit artikel wordt uitgelegd waarom is gekozen voor de 'intern' mogelijkheid en waarom er niet meer gewerkt wordt met CSS bestanden.


Voordelen externe bestanden

Op diverse sites lees je over de voordelen van externe CSS bestanden. Het voordeel zou zijn dat je maar één keer een style hoeft te schrijven voor verschillende webpagina's.
Ja, dat klopt. Maar het gaat wel uit van de ouderwetse manier van sites maken: het maken van aparte HTML bestanden.
Bij min of meer statische websites zal dit nog steeds voorkomen: daarvoor zijn HTML pagina's via tooling of handmatig gemaakt en opgeslagen op de webserver.
Bij webapplicaties wordt de HTML doorgaans dynamisch gegeneerd. Hetzij op de server (bijv. met PHP, waarna de HTML naar de browser wordt gestuurd), hetzij in de browser (met Javascript), hetzij een combi.
Bij webapplicaties die gebruik maken van Ajax-call's is er helemaal geen sprake meer van het laden van een gehele webpagina. Bij die webapplicaties wordt een bepaald deel van de webpagina ververst (bijv. een bepaalde div). Zie ook het artikel Form submit via Ajax.
Het voordeel gaat dan helemaal niet meer op: er is maar één webpagina. Je zou dan net zo goed de style intern kunnen declareren. Die hoeft dan alleen bij de eerste call geladen te worden.

Af en toe lees je over een performance voordeel van externe CSS bestanden. Bij een volgende aanroep wordt de CSS uit de cache opgehaald.
Dit is een theoretisch voordeel. Niet iedereen heeft de cache aanstaan en vanwege mogelijke veranderingen in de CSS wordt hij toch vaak opnieuw geladen.
En ook bij dit voordeel geldt wederom de ouderwetse manier van het telkens laden van de gehele webpagina.

Zie evt. Lang leve externe CSS bestanden

Nadeel externe bestanden

Wat blijft er dan als voordeel over van het hanteren van externe CSS bestanden? Niets dus.
Wel kan er een nadeel opdoemen. Dit doet zich bij grotere complexere webapplicaties voor.
CSS bestanden brengen namelijk weinig flexibiliteit met zich mee. Het is een hardcoded manier van vastleggen van de style. Alleen we webontwikkelaar kan er iets mee.
Bij grotere complexere webapplicaties, waarbij inlog mogelijk is, wil je soms een admin de mogelijkheid bieden de stijl aan te passen. Of wil je persoonlijke voorkeuren kunnen laten vastleggen. Of wil je één webplatform gebruiken voor verschillende applicaties (zoals kickerplaza.nl), waarbij de opmaak per applicatie kan verschillen.
Ai, een CSS bestand is een tekstbestand die op de server staat. En iedereen gebruikt die. Je kunt gaan knoeien met meerdere CSS bestanden, maar ideaal is dit niet.
Dit gebrek aan flexibiliteit heeft al geleid tot de ontwikkeling van Sass, Less en Scss. Hiermee kun je met variabelen werken.
Dat lost bepaalde problemen op, bijvoorbeeld het vervangen van de kleur geel op tig plekken: dat hoeft maar meer op één plek.
Maar het biedt nog geen optie tot het flexibiliseren van de CSS door gebruikers zelf of het eenvoudig applicatie specifiek maken van een stijl, zoals bij kickerplaza.nl.

Daarnaast komt het voor dat de CSS rendering niet snel genoeg plaatsvindt, waardoor de HTML eerst zonder opmaak wordt getoond, daarna opgemaakt. Dit geeft een flikkering.


De oplossing

Kortom, wat is DE oplossing voor grotere complexere webapplicaties? Hoe zorg je voor optimale flexibiliteit op het vlak van style?

De oplossing is feitelijk heel simpel. Hoe ga je om met klant data? Jawel, die sla je op in een database.
Waar sla je dus de stijl in op? Juist ja, in de database.
Bij de eerste aanroep van de applicatie haal je de info eruit en genereer je in de head een interne stijl. De head wordt immers toch alleen bij de eerste aanroep geladen, daarna nooit meer.
Let wel, het is dus niet handig om 'div{padding:10px}' in een field in een tabel te stoppen. Je moet het wel keurig normaliseren. Dus in 1 kolom 'div', in een volgende 'padding' en in een volgende '10px'.
Uiteraard zijn meer opties/kolommen mogelijk, bijv. voor aanduiding van de rol waarvoor het geldt. Net wat je wil, je bent zelf de baas over de architectuur.

Daarnaast is het inline stylen ook nog steeds mogelijk. De breedte van een kolom in een overzicht kan makkelijker inline worden aangegeven. Ook die breedte leg je natuurlijk vast in de database, want dan is het makkelijk aanpasbaar door de admin of zelfs door een user (waarbij je uiteraard per user per overzicht de breedte vastlegt).
Moeilijk, rocket science? Nee, zeker niet. Bij kickerplaza.nl is hier al jaren ervaring mee opgedaan en het bevalt uitstekend. Zeer goede performance, optimale flexibiliteit.


Opmerkingen? Ze zijn van harte welkom: email@johnnyhogenbirk.nl!