Semantiek: Tabellen vs divs

De strijd luidt dus "tabellen versus divs", maar eigenlijk is deze titel in mijn ogen onterecht, en wel om de volgende reden. Divs hebben geen waarde, als je enkel divs gebruikt, zoals iemand tabellen zou gebruiken voor elk doeleinde, kom je weinig vooruit. Het gaat bij het gebruiken van goed html in plaats van tabellen, om de semantiek. Semantiek?

Semantiek

Je hebt een website met een eenvoudige opzet, boven een bedrijfslogo met bedrijfsnaam, links daaronder een menu, rechts daarvan de eigenlijke tekst met koptekst en onderaan een zogenaamde footer met daarin een submenu of copyright-tekst. Hoe kun je dit semantisch opbouwen? Je bedrijfsnaam is uiteraard belangrijk, je wilt uiteraard ook dat men bij het zoeken op dat woord bij jouw website terecht komt. Je bedrijfsnaam is de header van je website, deze plaats je dus logischerwijs in een h1-element.
Dan krijg je het menu. Een menu is niets anders dan een opsomming of lijst van keuzemogelijkheden, voor de hand liggend is dus om hier een ordered of unordered list aan te wijden.
Bovenaan je tekst heb je vaak ook een koptekst, zoals de titel van een bericht, zoals je in de krant tegen komt. Deze is niet even belangrijk als je bedrijfsnaam, of de krantnaam. Deze is daaraan ondergeschikt. Je gebruikt dus geen h1-element, die heb je namelijk al eens gebruikt, dus kom je uit bij de h2-element. De eigenlijke tekst stop je in een paragraaf. Voor elk eventuele subkop zou je dus de h3-element kunnen gebruiken. Een submenu kun je ook weer in een lijst verwerken. Verder kun je elk website-deel in een div-element (div = division = deel) plaatsen. Dus een div voor de header, een div voor de content, een div voor de footer.
Alles heeft nu een degelijke waarde, het meest toonaangevende springt er op die manier uit, een opsomming van items is ook echt een opsomming. Daarna kan de positionering en opmaak beginnen: CSS.

De voordelen van semantische html

Uiteraard heeft het semantisch opzetten van je html-code voordelen (waarvan het tegenliggende de nadelen zijn van een opbouw met tabellen). Zo vang je meerdere spreekwoordelijke vliegen in één klap;

• minder code
  • minder lange laadtijd
  • het kost minder serverruimte
  • minder verbruik van dataverkeer
  • eventueel bezuiniging op kosten van een hostingpakket
• code is overzichtelijker, het heeft een waarde
  • het wijzigen van de code of implementeren van een systeem is minder arbeidsintensief
  • onderhouden van je website is goedkoper
• betere indexering door zoekmachines
• je website is toegankelijk(er)
  • je bereikt meer mensen, wat meer klanten of zelfs meer omzet kan betekenen
• zekerheid met betrekking tot weergave van je website in toekomstige browser(versies)

Nu ben ik ongetwijfeld nog enkele voordelen vergeten. Voordelen van het gebruik van een stylesheet heb ik niet meegenomen, want CSS kun je ook toepassen op tabellen. Echter weet ik uit ervaring dat je, wanneer je CSS toe gaat passen op tabellen, je meer met styles moet werken om alles goed te krijgen, dan wanneer je semantische html gebruikt. Daarnaast heeft semantische html in combinatie met CSS wel één groot voordeel. Opbouw is eenvoudig te wijzigen zonder dat je de html-code hoeft te wijzigen. Je hoeft dus niet tientallen pagina's langs als je het menu ineens horizontaal in plaats van verticaal wilt, of rechts in plaats van links. Iets dat met tabellen absoluut niet was gelukt door het wijzigen van één enkel bestand. Een goede demonstratie hiervan vind je op de pagina over toegankelijk­heid.

De nadelen van semantische html

Aan semantische html zijn geen directe nadelen. Wel het positioneren van je elementen kunnen nadelen met zich meebrengen tegenover het gebruik van tabellen om je contentdelen op het scherm te plaatsen.
Iedere webbrowser (zoals Internet Explorer, Netscape, FireFox, Opera) heeft een eigen interpretatie van html-code. Gelukkig zijn er webstandaarden waar je je tijdens het ontwikkelen aan kan houden. Over het algemeen houden webbrowers zich hier ook aan, waardoor je een mooi resultaat krijgt. Internet Explorer, helaas nog altijd de meest gebruikte browser, is één van de browsers die enkele webstandaarden aan zijn laars lapt, waardoor je hierin andere resultaten kunt krijgen dan verwacht. Het goed positioneren van elementen, zodat het in elke browser gelijk is, vergt dan ook wat training, kennis van gedrag van elementen, doorzettingsvermogen (de meeste mensen die CSS leren geven vaak te snel op waardoor ze terug vallen op tabellen) en kennis van de regel 'de gulden middenweg'. In sommige gevallen komt het namelijk op het laatste neer. Werken met CSS is dan ook niet iets dat je in één dag of week goed onder de knie hebt.

Echt fout

Er zijn gevallen waar gebruik wordt gemaakt van tabellen, die echt fout zijn. Deze worden veelal veroorzaakt door personen die hun lay-out slicen met behulp van een zogenaamde wysiwyg-editor of ontwerpprogramma's. Behalve dat dat soort programma's de lay-out in tabellen opzet, wordt de stijl in het document meegegeven. Op deze manier is het ondoenlijk om iets aan de opmaak te wijzigen als je website meerdere pagina's heeft. Je zult dan pagina voor pagina bij langs moeten, om bijvoorbeeld letterkleur, lettertype of lettergrootte te moeten wijzigen. Ook afstanden van de rand van een tekst-box of het scherm tot de tekst zelf worden met verouderde tabel-attributen meegegeven, zoals cellpadding of cellspacing.
Dus daarom: opmaak en content scheiden. Alle opmaak wordt vanuit een enkel bestand geregeld, namelijk de stylesheet. Aanpassingen die hierin worden doorgevoerd, worden doorgevoerd op alle pagina's die je website bevat en die gebruik maakt van die stylesheet. Of het nou 3 zijn, of 30, geen van die pagina's hoef je te beroeren.

De meningen

Elk voorstander heeft zijn eigen mening over het gebruik van tabellen of semantische html. Ikzelf denk dat de meeste argumenten om tabellen te gebruiken van diè mensen komen die nooit echt geprobeerd hebben om semantische html te gebruiken in combinatie met CSS. Zoals gezegd is het niet in één week geleerd en eist het dus wel wat doorzettingsvermogen.

Er wordt vaak gezegd dat het er uiteindelijk om gaat hoe het er uit ziet. Maar je wilt natuurlijk ook een toegankelijk­e website, of in elk geval een website die over 20 jaar nog goed getoond wordt. Door gebruik te maken van semantische html en je te houden aan de webstandaarden, speel je hier alvast op in. Die zekerheid heb je met tabellen niet.
Zonder stylesheet en dus opmaak komt de opbouw van een website met semantische html niet in de buurt van de opbouw zoals het was of zoals je het met tabellen zou hebben, zonder opmaak. Echter is dit juist wat de richtlijnen van het W3C voorstellen. Je pagina wordt dan een lange pagina met alle content onder elkaar. Als je pagina dan nog steeds te begrijpen is, dan heb je een goede pagina gebouwd. Dit is namelijk de manier waarop mensen die blind of slechtziend zijn en gebruik maken van een screenreader een site te horen krijgen. Voor dit soort browsers is een semantische opmaak dus zeer belangrijk.
Met toegankelijk bouwen kom je niet alleen de groep mensen met een "functionele beperking" tegemoet, maar ook mensen zoals ouderen, mensen met PDA’s, telefoons met trage verbindingen, et cetera.

Best interessant

Natuurlijk kun je hierin veel verder gaan. Als je bijvoorbeeld echt toegankelijk wilt bouwen, kun je je aan meerdere webstandaarden en voorschiften houden, zoals het gebruik van accesskeys op een website, het gebruik van alternatieve teksten voor afbeeldingen, die screenreaders wel opvangen.
Via internet is genoeg te vinden over toegankelijk bouwen en waarom je geen tabellen zou moeten gebruiken. Een greep uit mijn favorieten om je het zoekwerk te besparen:

Toegankelijk bouwen

• Structurering: Het draait om semantiek
• semantiek, waarom zou je?
• toegankelijk bouwen
• voordelen van toegankelijk bouwen
• klant geeft niet om toegankelijk­heid
• toegankelijk­e sites zijn lelijk

Tabellen

• welke doelgroepen sluit je uit
• voor en nadelen van tabellen
• waarom lay-outen met tabellen dom is
• div versus tabel