Cascading Style Sheets - een intermezzo
waarmee Kees Grinwis een voorzet geeft

In aflevering één van deze cursus is ingegaan op de achtergrond van CSS, de syntaxis en de relatie tot HTML. Wat er echter niet behandeld is, dat zijn de voordelen van de scheiding van de opmaak en de structuur (of-te-wel de inhoud) van een website. In deel twee hoop ik volgende keer de diverse CSS mogelijkheden die door Oregano ondersteund worden te behandelen, maar nu eerst een klein intermezzo.

De meeste leden van de Big Ben Club die wel eens een website gebouwd hebben of er nog steeds één of meerdere onderhouden zullen dit wel als hobby doen en zich niet bezig houden met professioneel webdesign. Deze website-makers zullen hun kennis van HTML (en evt. CSS) vooral opgedaan hebben door te kijken naar de sites van anderen, hier kunnen zowel goede als slechte ontwerpen tussen zitten. De kans dat de technisch minder goed ontworpen sites in de meerderheid zijn is heel erg groot, anders gezegd: De kans dat men naar goed ontworpen sites gekeken heeft is erg klein.

Nu zijn er meerdere manieren om een website te beoordelen, de site moet semantisch correct zijn, hij moet aan de standaarden voldoen, de pagina's moeten er goed uit zien, hij moet werken in Netscape en IE, of hij moet werken op de browser van de ontwerper of opdrachtgever. De volgorde van mogelijkheden is niet toevallig gekozen, ik ben namelijk begonnen met de beste opties vooraan te zetten en heb de slechte opties achteraan gezet.

Bovenstaande criteria zijn echter nogal academisch van aard, een bouwer zal er niets van merken als zijn of haar site niet aan de standaarden voldoet of in het geheel niet semantisch is, toch is er wel degelijk voordeel uit te halen als de site over een langere tijd moet bestaan en door verschillende mensen moet worden onderhouden (hoewel er wel degelijk óók voordeel is als je alleen aan je site werkt).

Een site die ontworpen is met tabellen (en dan bedoel ik het gebruik van tabellen voor alle layout zaken) hoeft niet lelijker te zijn dan een site die gebruik maakt van CSS. Alleen is er tegenwoordig met CSS veel meer mogelijk dan vroeger met tabellen bereikt kon worden. Toch is een ontwerp met tabellen minder flexibel, een klein voorbeeldje:

Ik heb een site ontworpen die gegenereerd wordt door de computer, ik heb hier gebruik gemaakt van tabellen. Waarom heb ik gebruik gemaakt van tabellen? Simpel, ik begrijp de techniek achter de style sheets niet. Ik lever de software af en de klant is tevreden.

Enige maanden later komt de klant echter terug en hij geeft aan dat hij voor zijn oplossing nog een klant heeft, deze klant moet echter een compleet andere look hebben. Het gaat hierbij vooral om het vervangen van plaatjes, dus ik breid mijn programma uit waardoor het mogelijk wordt om per site (die allemaal uiteraard een ander adres hebben) andere plaatjes te gebruiken, overal waar er plaatjes gebruikt worden moet ik een aanpassing maken. De software wordt opgeleverd en de klant is opnieuw tevreden. Ik heb echter wel moeten programmeren om de uitbreiding mogelijk te maken, als ik direct CSS gebruikt had dan had ik veel minder moeten programmeren. In de CSS is namelijk alles wat te maken heeft met layout opgenomen. Ik had dus kunnen volstaan met een kleine uitbreiding van de software, waarbij er een ander stijlblad gekozen wordt - afhankelijk van de URL (het adres van de site) waarmee mijn programma wordt opgeroepen.

Één jaar later komt dezelfde klant weer bij ons, ook deze keer moet de site hetzelfde blijven werken. De look and feel moet echter volledig anders. De knopjes moeten op een andere plaats komen en de layout moet ook nog eens drastisch worden aangepast. In dit geval kan ik niet volstaan met het toevoegen van code om de plaatjes op een andere plaats op te halen, alle code moet nagekeken worden en afhankelijk van de site moet er een compleet andere tabel-structuur opgezet worden. Eerder schreef ik: "Ik heb echter wel moeten programmeren om de uitbreiding mogelijk te maken, als ik direct CSS gebruikt had dan had ik veel minder moeten programmeren.", dat geldt nu in dubbele mate.

Als de klant jaren later nog eens terugkomt en weer een grote wijziging vraagt, dan moeten we een groot deel van de code herschrijven (deze code is dus zowel de HTML als de gebruikte programmeertaal voor de toepassing - deze programmeertaal kan van alles zijn: C, Delphi (Pascal), Java, Perl, [...]) Zeker als men later in een programma moet terugkijken is zo'n mix niet bevorderlijk voor de duidelijkheid van de broncode.

Als we nu direct gebruik gemaakt zouden hebben van grotendeels semantisch gecodeerde HTML dan hadden we alleen aanpassingen hoeven te doen aan het stijlblad en hadden nooit de code hoeven te wijzigen.



Over het onderwerp "Semantiek en webstandaarden" hoop ik op donderdag 9 december 2004 een voordacht te houden in de regio Den Haag. Hierin ga ik ondermeer in op het nut van webstandaarden (in de breedste zin van het woord, dus hierbij moet men denken aan HTML, CSS, JavaScript en de DOM) en het semantisch ontwerpen van een website.