Uitleg venstervullende lay-out met vaste header, vaste footer en twee kolommen

Korte omschrijving

Tweekoloms lay-out met vaste header en footer. Deze lay-out vult altijd het hele venster van de browser, zowel in de hoogte als in de breedte. In de breedte tot een makkelijk aan te passen maximumbreedte. Bij voldoende inhoud kan de de rechterkolom worden gescrold.

Header (geel)

Staat altijd bovenaan het venster, scrolt niet mee. Hoogte afhankelijk van lettergrootte. Automatisch even breed als het venster, maar niet breder dan een makkelijk aan te passen maximumbreedte.

Linkerkolom (groen)

Staat altijd aan de linkerkant van het venster, scrolt niet mee. Breedte past zich aan lettergrootte aan. De hoogte past zich automatisch aan het venster aan: de kolom vult altijd de ruimte tussen header en footer. Geschikt voor bijvoorbeeld links, knoppen of 'n menu.

Rechterkolom (oranje)

Staat altijd op dezelfde positie aan de rechterkant van het venster. De hoogte past zich automatisch aan het venster aan: de kolom vult altijd de ruimte tussen header en footer. Bij voldoende inhoud verschijnt een verticale scrollbar, waarmee de inhoud van de rechterkolom gescrold kan worden.

De breedte past zich automatisch aan het venster aan, de ruimte tussen linkerkolom en rechterkant van het venster wordt volledig gevuld. Linker- en rechterkolom worden echter, om te lange regels te voorkomen, samen nooit meer dan een makkelijk aan te passen maximumbreedte.

Deze kolom is bedoeld voor de echte inhoud van de pagina.

Footer (blauw)

Staat altijd onderaan het venster. Hoogte afhankelijk van lettergrootte. Automatisch even breed als het venster, maar niet breder dan een makkelijk aan te passen maximumbreedte.

Opmerkingen

• Om te lange regels in de linkerkolom te voorkomen, wordt de pagina nooit breder dan 1280 px (wat eigenlijk al veel te lange regels oplevert). Deze maximumbreedte is makkelijk aan te passen.

  Je zou met behulp van css3 media queries op de breedte van het venster van de browser kunnen testen, en dan boven een bepaalde breedte de tekst in één of meer kolommen neer kunnen zetten. Dan zou je een grotere breedte kunnen gebruiken, zonder dat de regels te lang worden. De css3-eigenschap columns is hier geschikt voor. Bij gebruik van deze eigenschap loopt de tekst, net als in een krant, automatisch door in de volgende kolom, als het niet meer in de kolom past.

  Ik ben hier bepaald geen voorstander van, en ik ben niet de enige. Als je weinig tekst hebt, gaat dit prima en kan het er ook heel leuk uitzien. Maar bij iets meer tekst betekent dit dat je voortdurend verticaal aan het scrollen bent: van de onderkant van de zojuist gelezen kolom terug naar de bovenkant van de volgende kolom. Maar bij weinig tekst of bij bijvoorbeeld afbeeldingen, die je ook van links naar rechts kunt bekijken, is het een mogelijkheid.

• De linkerkolom zit hier in een element <nav>. Dat is een html5-element, bedoeld voor een serie links zoals je die in een menu vindt. Als er in de linkerkolom geen menu komt, kan de <nav> beter worden vervangen door <section> of een ander passend element. Meer over <nav>, <section>, enz. bij Semantische elementen en outline.
• Deze lay-out is niet geschikt voor teksten waarin veel wordt gelinkt binnen dezelfde pagina (ankers). Zie verder bij Bekende problemen.
• Als je als achtergrond een afbeelding wilt hebben, zal dat in de linkerkolom, de header en de footer geen problemen opleveren. In de rechterkolom kan het wat lastiger zijn. Bij background: orange; staat, hoe je dit toch voor elkaar kunt krijgen.

Links in deze uitleg, vooral links naar andere sites, kunnen verouderd zijn. Op de pagina met links vind je steeds de meest recente links.

Alles op deze site is gemaakt op een systeem met Linux. Daarbij is vooral gebruik gemaakt van Quanta Plus, GIMP en Firefox met extensies. De pdf-bestanden zijn gemaakt met LibreOffice.

Vragen of opmerkingen? Fout gevonden? Ga naar het forum.

Iets gevonden waar je wat aan hebt? Mooi. Als je je waardering wilt uiten, maak dan een donatie over aan War Child Nederland, een organisatie die kinderen uit oorlogsgebieden helpt hun trauma's te verwerken. Of - nog beter - wordt donateur:

Achterliggend idee

Ogenschijnlijk lijkt dit een samenhangend geheel: header, linker- en rechterkolom en footer vullen samen het venster van de browser. In werkelijkheid gaat het om vier totaal van elkaar losstaande vlakken, die toevallig enigszins samenhangend op het scherm worden gezet.

Toevallig? Nou ja, de plaats waar ze staan is natuurlijk niet toevallig. Maar ze hebben verder niets met elkaar te maken. Zonder al te veel moeite had de header links kunnen staan, en de footer bovenaan. En als je één of meer delen weg zou laten, blijven de resterende delen er exact hetzelfde uitzien. Wat voor het oog een samenhangend geheel is, bestaat in werkelijkheid uit vier losse blokken.

Header, footer en linkerkolom even doorzichtig gemaakt.

Eerst de rechterkolom. Niet verder vertellen, maar eigenlijk is er helemaal geen rechterkolom. Op de afbeelding hiernaast zijn header, linkerkolom en footer even doorzichtig gemaakt. Je kunt dan goed zien dat die zogenaamde rechterkolom in werkelijkheid even breed is als het venster van de browser: de oranje achtergrondkleur loopt over de volle breedte door.

De rechterkolom bestaat uit twee geneste blok-elementen. De buitenste hiervan is div#content, die op de afbeelding te zien is als het oranje gekleurde blok. Deze div is absoluut gepositioneerd op 8,5 em vanaf de bovenkant, wat ook de hoogte van de header is. Aan de onderkant loopt hij tot 5 em vanaf de onderkant van het venster van de browser, wat even hoog is als de footer. div#content vult dus de ruimte tussen header en footer volledig op.

Aan div#content wordt een maximumbreedte van 1280 px gegeven, om te lange regels in de rechterkolom te voorkomen.

Binnen div#content staat een tweede blok-element: <article>. <article> is eigenlijk een doodgewone div met een speciale semantische betekenis. In dit geval staat de eigenlijke inhoud van de pagina erin. <article> geef ik een hoogte van 100%, waardoor <article> even hoog wordt als z'n ouder div#content. Omdat <article> een blok-element is, wordt het automatisch even breed als z'n ouder. <article> is dus ook even breed als het oranje blok op de afbeelding.

Bij <article> wordt overflow op auto gezet. Als er meer inhoud is dan er in <article> past, verschijnt hierdoor een verticale scrollbalk. Deze scrollbalk hoort dus niet bij de hele pagina, maar alleen bij <article>. En omdat <article> binnen de absoluut gepositioneerde div#content staat, scrolt alleen de inhoud van <article>, en niet de hele pagina.

Door de lege ruimte boven en onder div#content heeft deze div en alles wat erin staat geen enkele invloed op de erboven staande header en de eronder staande footer. Ze hebben niets met elkaar te maken. De header en de footer blijven dan ook altijd op hun plaats staan, ongeacht hoeveel inhoud er in de rechterkolom zit.

<article> krijgt links een padding van 13,5 em. Dat levert ruimte op voor de linkerkolom, die 12 em breed is. Door het verschil van 1,5 em is er gelijk ruimte tussen de buitenkant van <article> en de inhoud ervan.

In de html komt de linkerkolom voor div#content. Wat er binnen div#content gebeurt, heeft dan ook geen enkele invloed op de linkerkolom, omdat deze niet binnen div#content zit.

De linkerkolom zit in een blok-element <nav>. <nav> is eigenlijk een doodgewone div met een speciale semantische betekenis: er zit een menu met links in. <nav> staat absoluut gepositioneerd op 8,5 em vanaf de bovenkant en 5 em vanaf de onderkant. Ook <nav> laat dus ruimte voor de header en de footer vrij, maar vult wel de ruimte tussen header en footer volledig.

<nav> staat op dezelfde plaats als div#content. Omdat het in de html voor div#content staat, zou het daardoor onder div#content verdwijnen. Want normaal genomen komt latere html over eerdere heen te staan. Een hogere z-index voor <nav> lost dat op. <nav> wordt dus eigenlijk van bovenaf gewoon een eind omlaag gezet, waardoor het over div#content en <article> komt te staan, precies op de lege plek die is ontstaan door de padding van 13,5 em aan de linkerkant van <article>. En met behulp van een z-index wordt <nav> toch boven div#content en <article> gezet, en is dus toch zichtbaar.

Helemaal bovenaan in de html staat <header>. <header> is eigenlijk een doodgewone div met een speciale semantische betekenis: de header zit erin. Omdat de pagina verder niet scrolt of zo (dat gebeurt alleen binnen <article>), hoeft <header> niet gepositioneerd te worden: er is niets wat <header> van z'n plaats zou kunnen duwen.

<header> krijgt een hoogte van 8,5 em, waardoor hij precies de lege ruimte boven div#content vult. Omdat het 'n blok-element is, vult hij automatisch de breedte van z'n ouder, dat is hier <body>, waardoor <header> precies even breed wordt als de pagina.

<header> krijgt dezelfde maximumbreedte als div#content, anders zou <header> in brede browservensters breder worden dan de middelste twee kolommen.

Blijft nog over de footer. De footer staat in een blok-element <footer>. Ook <footer> is eigenlijk weer 'n doodgewone div met een speciale semantische betekenis.

<footer> wordt absoluut gepositioneerd aan de onderkant van het venster van de browser en krijgt een hoogte van 5 em. Daarmee vult <footer> precies de lege ruimte onder div#content en <nav>.

Normaal genomen wordt een blok-element als <footer> automatisch even breed als z'n ouder. Dat is hier <body>. Maar omdat <footer> absoluut gepositioneerd is, is dat hier niet het geval. Daarom moet <footer> een breedte van 100% krijgen, dan wordt hij wel even breed als <body> en dus de pagina.

Ook <footer> krijgt een maximum-breedte van 1280 px, zodat ook <footer> op in brede browservensters niet breder wordt dan de twee middelste kolommen.

Semantische elementen en outline

Ik heb deze drie onderwerpen samengevoegd, omdat ze veel met elkaar te maken hebben.

Semantische elementen

De meeste elementen die in html worden gebruikt, hebben een semantische betekenis. Dat wil zeggen dat je aan de gebruikte tag al (enigszins) kunt zien, wat voor soort inhoud er in het element staat. In een <h1> staat een belangrijke kop. In een <h2> staat een iets minder belangrijke kop. In een <p> staat een alinea. In een <table> staat een tabel (en geen lay-out, als het goed is!). Enz.

Door het op de goede manier gebruiken van semantische elementen, kunnen zoekmachines, screenreaders, enz. de structuur van een pagina begrijpen. De spider van een zoekmachine is redelijk te vergelijken met een blinde. Het is dus ook in je eigen belang om semantische elementen zo goed mogelijk te gebruiken. Een site die toegankelijk is voor mensen met een handicap, is in de regel ook goed te verwerken voor een zoekmachine en maakt dus een grotere kans gevonden en bezocht te worden.

Als het goed is, wordt het uiterlijk van de pagina bepaald met behulp van css. Het uiterlijk staat hierdoor (vrijwel) los van de semantische inhoud van de pagina. Met behulp van css kun je een <h1> heel klein weergeven en een <h6> heel groot, terwijl screenreaders, zoekmachines, en dergelijke nog steeds weten dat de <h1> een belangrijke kop is.

Slechts enkele elementen, zoals <div> en <span>, hebben geen semantische betekenis. Daardoor zijn deze elementen uitstekend geschikt om met behulp van css het uiterlijk van de pagina aan te passen: de semantische betekenis verandert niet, maar het uiterlijk wel. Voor een screenreader of zoekmachine verandert er (vrijwel) niets, voor de gemiddelde bezoeker krijgt het door de css een heel ander uiterlijk.

(De derde laag, naast html voor de inhoud en css voor het uiterlijk, is JavaScript. Die zorgt voor de interactie tussen site en bezoeker. De min of meer strikte scheiding tussen css en html aan de ene kant en JavaScript aan de andere kant is met de komst van css3 en html5 veel vager geworden. Je kunt nu bijvoorbeeld ook met css dingen langzaam verplaatsen en met html deels de invoer in formulieren controleren. Maar op JavaScript ga ik op deze site verder niet echt in.)

Html5 heeft een aantal nieuwe elementen, die speciaal zijn bedoeld om de opbouw van een pagina aan te geven. In dit voorbeeld worden hiervan <header>, <nav>, <article>, <section> en <footer> gebruikt. Alle vijf gedragen zich als een gewone <div>, maar dan een <div> met een semantische betekenis. Hierdoor kunnen screenreaders, zoekmachines, en dergelijke beter zien hoe de pagina is samengesteld.

<header>: bedoeld om een header in te zetten.

<nav>: bedoeld om een serie links voor navigeren in te zetten.

<article>: tekst die als een zelfstandig geheel kan worden gezien. In dit voorbeeld is de rechterkolom een <article>.

<section>: deel van een tekst. In dit voorbeeld is <article> in de rechterkolom onderverdeeld in een aantal <section>'s.

<article>'s en <section>'s kunnen worden genest. Het gaat er alleen om dat een <article> een afgerond geheel is, en ook een deel van een <article> of <section> kan dat zijn.

Een pagina van een krant kan binnen een <article> staan. Binnen dat <article> kan een <section> Sport staan. Binnen die <section> Sport kan weer een <article> met een wedstrijdverslag staan. Binnen een <article>, want zo'n verslag is een afgerond geheel. En binnen dat verslag zouden weer <section>'s kunnen staan voor het deel voor de rust, het deel na de rust, enz.:

<footer>: bedoeld om de footer in te zetten.

Ook <header> en <footer> mogen vaker op één pagina worden gebruikt. Een <article> zou bijvoorbeeld een eigen <header> en <footer> kunnen hebben, naast de <header> en <footer> voor de hele pagina.

Het is nog niet helemaal duidelijk of dit wel op grote schaal gaat gebeuren, want er zitten fors wat haken en ogen aan, bijvoorbeeld voor zoekmachines. Daar ga ik hier dus verder niet op in. Persoonlijk denk ik vooralsnog dat één <header> en <footer> per pagina het beste is.

Met behulp van dit soort nieuwe semantische elementen kan bijvoorbeeld een screenreader in één keer een hele <header> of <nav> passeren. Alleen hebben deze nieuwe elementen één probleem: ze hebben in de praktijk nog weinig nut, omdat screenreaders en dergelijke ze nog niet herkennen. En voordat alle screenreaders en dergelijke ze herkennen, zijn we jaren verder, want screenreaders zijn peperduur.

Maar er is niets op tegen om ze nu vast te gaan gebruiken. Op het moment dat screenreaders, zoekmachines, enz. ze gaan herkennen, is de pagina dan al hierop voorbereid. Extra werk is het eigenlijk niet. Het intypen van <nav> gaat even snel als het intypen van <div>, en het intypen van <header> gaat zelfs nog sneller dan <div id="header">, zoals nu vaak gebeurt.

Outline

Een aantal van de hierboven genoemde elementen wordt ook gebruikt voor het maken van een outline van de pagina. Een outline is een soort automatisch aangemaakte inhoudsopgave, met behulp waarvan screenreaders, zoekmachines, en dergelijke de logische opbouw van een pagina kunnen begrijpen.

Van de hierboven genoemde semantische elementen worden <article>, <section> en <nav> gebruikt voor de opbouw van een outline. Er zijn nog enkele soortgelijke elementen, maar die worden in dit voorbeeld niet gebruikt.

Ook in html4 werd al een een outline gemaakt, maar daarvoor werden alleen <h>'s gebruikt, en dat werkte niet altijd even goed. Daarom is dit in html5 verbeterd. Of althans: dat is de bedoeling. (<h>'s worden in html5 trouwens nog steeds gebruikt voor het maken van de outline, later meer daarover.)

De outline wordt aangemaakt volgens specifieke regels. Het begin van de outline van de pagina is altijd <body>.

Voor elke <nav>, <article> en <section> wordt vervolgens een soort hoofdstuk aangemaakt. Dit hoofdstuk wordt een sectie genoemd. Als een van deze elementen binnen een andere is genest, wordt een sub-sectie aangemaakt.

Als we niet op de <h>'s letten, die ook een rol spelen, levert dit in dit voorbeeld de volgende indeling op:

1 body(begin van de pagina) 1.1 <nav>(linkerkolom) 1.2 <article>(rechterkolom) 1.2.1 <section>(beschrijving rechterkolom) 1.2.2 <section>(opmerkingen) 1.2.3 <section>(opvultekst)

Zonder dat je veel extra moeite hoeft te doen, levert het gebruik van de nieuwe elementen al een ruwe indeling van de pagina op. Waarbij bijvoorbeeld gelijk duidelijk is dat Beschrijving rechterkolom, Opmerkingen en Opvultekst onderdelen van Rechterkolom zijn.

Dit zijn secties die je zelf maakt. Los daarvan kan een nieuwe sectie ook worden gemaakt door een <h>, net zoals dat het geval was in html4. Alleen is de manier waarop dat gebeurt wat veranderd, omdat het in html4 soms een verkeerde outline opleverde. Dat kan trouwens nog steeds, als je niet oplet, maar html5 geeft in ieder geval de mogelijkheid om het goed te doen.

De hierboven getoonde outline is eigenlijk onjuist. In werkelijkheid levert de pagina uit het voorbeeld de volgende outline op:

1 body
1.1 Linkerkolom
1.2 Rechterkolom
1.2.1 Beschrijving rechterkolom
1.2.2 Opmerkingen
1.2.3 Begin van de opvultekst

Niet geheel toevallig zijn de namen van de elementen, behalve <body>, hier vervangen door voor mensen beter te begrijpen teksten, die - ook niet geheel toevallig - hetzelfde zijn als de in het voorbeeld gebruikte <h>'s.

Om dit te verklaren moeten we naar de gebruikte <h>'s kijken.

Binnen een <nav>, <article> of <section> wordt de eerste <h> binnen die <nav>, <article> of <section> gebruikt voor de titel ervan.

Dit geldt ook, als die <h> niet gelijk helemaal bovenaan staat. Als ik in de <nav> waarbinnen de linkerkolom staat de <h2> met 'Linkerkolom' onder de tekst zet, wordt toch deze <h2> als kopje voor de <nav> gebruikt, omdat het de eerste <h> binnen de <nav>. is. Als je <h>'s op de juiste manier gebruikt, zal dit ook vrijwel altijd de bedoeling zijn.

Ik moet iets opbiechten: ook deze tweede outline is niet wat je in werkelijkheid krijgt bij deze pagina. De volledige outline van deze pagina, en nu jok ik eerlijk waar niet meer, is:

1 Tweekoloms lay-out
1.1 Header
1.2 Linkerkolom
1.3 Rechterkolom
1.3.1 Beschrijving rechterkolom
1.3.2 Opmerkingen
1.3.3 Begin van de opvultekst
1.4 Footer

Nieuw verschenen zijn Tweekoloms lay-out in plaats van body, Header onder 1.1 en Footer onder 1.4. Terwijl <header> en <footer> niet mee doen in de outline, geen eigen sectie maken. Dit komt omdat naar álle <h>'s wordt gekeken, ook die buiten <nav>, <header> en <footer> staan.

<body> is ook 'n sectievormend element. 'n Hele grote sectie, want de hele pagina zit erin. Binnen <body> is de eerste <h> die wordt ontmoet de <h1> met 'Tweekoloms lay-out'. Omdat dit de eerste <h> is (en hij niet in een <nav>, <article> of <section> staat), wordt die in de outline gebruikt als naam voor de body. Wat natuurlijk veel duidelijker is voor mensen dan het vage 'body'.

De volgende <h> die wordt ontmoet, is de <h2> met 'Header'. Als binnen een sectie, zoals body, een <h> wordt ontmoet met een lagere waarde, wordt automatisch een subsectie aangemaakt. Ook zonder dat ik dat expliciet aangeef. De <h2> met 'Header' volgt op de <h1> met 'Tweekoloms lay-out, en maakt dus automatisch de subsectie 1.1, met als naam de inhoud van de <h2>: 'Header'.

Dat die <h2> met 'Header' binnen <header> staat, maakt niet uit, want <header> maakt zelf geen nieuwe sectie aan.

De secties onder 1.2 en 1.3 worden nog steeds op dezelfde manier gemaakt als hierboven is beschreven.

Dan blijft nog over 1.4 met Footer. Binnen <footer> staat een <h2> met 'Footer'. Ook <footer> maakt zelf geen sectie aan.

<h1>Tweekoloms lay-out</h1> <h2>Header</h2>(staat binnen <header>) <h2>Rechterkolom</h2>(staat binnen <article>) <h3>Beschrijving rechterkolom</h3>(staat binnen <section>) <h3>Opmerkingen</h3>(staat binnen <section>) <h>>Begin van de opvultekst(staat binnen <section>) <h2>Footer</h2>(staat binnen <footer>)

Hoewel <footer> zelf geen sectie aanmaakt, doet de <h2> binnen <footer> met 'Footer' dat wel. En levert dus de sectie '1.4 Footer' op. De <h3>'s binnen <article> hebben hier verder geen invloed op, want een <h> binnen een <article>, een <nav> of een <section> heeft alleen maar invloed binnen dat element zelf.

Dit laatste levert de mogelijkheid op om binnen elke <nav>, <article> en <section> te beginnen met een eigen <h1>. En inderdaad: dat mag. Alleen werkt dat op dit moment nog niet goed, omdat screenreaders en dergelijke ervan in de war raken. Beter is om gewoon de volgorde van html4 aan te houden: één <h1>, gevolgd door één of meer <h2>'s, <h3>, enz.

Los van dat meerdere <h1>'s gewoon nog niet werkt, is het maar de vraag of het gebruik van meerdere <h1>'s op één pagina wel zo slim is. Daar wordt nogal verschillend over gedacht. Hoe moet bijvoorbeeld een zoekmachine weten welke <h1> het belangrijkste is als er meerdere <h1>'s zijn?

De specificatie staat het gebruik van meerdere <h1>'s toe, maar het mag ook op de manier zoals hier is gebruikt: gewoon één <h1> en dan afdalen naar <h2>, <h3>, enz.

Persoonlijk denk ik dat het gebruik van meerdere <h1>'s absoluut niet slim is, en ik ben niet de enige die dat denkt. Hoe dan ook: op dit moment is er nog geen programma dat met meerdere <h1>'s uit de voeten kan, dus op dit moment moet je zeker niet meerdere <h1>'s gebruiken.

De outline van een pagina is een een tamelijk ingewikkelde materie. Op de pagina met links vind je onder Gereedschap → Outliner online-programma's om de outline zichtbaar te maken. Onder het kopje HTML → Outline vind je links naar meer info over outline, semantische elementen, en dergelijke.

Beschrijving van code en css

	div#header-buiten
	{
	    position: absolute;
	    right: 16px;
	    width: 100%;
	    height: 120px;
	    background: yellow;
	}

	div#header-binnen
	{
	    margin-left: 16px;
	    height: 120px;
	    text-align: center;
	}

body

Het element waarbinnen de hele pagina staat. Veel instellingen die hier worden opgegeven, worden geërfd door de kinderen van <body>. Ze gelden voor de hele pagina, tenzij ze later worden gewijzigd. Dit geldt bijvoorbeeld voor de lettersoort, de lettergrootte en de voorgrondkleur.

margin: 0; padding: 0;

Slim om te doen, is soms wat afwijkend in verschillende browsers.

In dit geval voorkomt margin: 0; ook nog een overbodige horizontale scrollbalk.

<footer> en div#content zijn beide absoluut gepositioneerd én 100% breed. Ze hebben beide geen ouder die relatief, fixed of absoluut is gepositioneerd. Dat betekent dat in dit geval de 100% breedte wordt genomen ten opzichte van het venster van de browser. <footer> en div#content vullen dus beide al de volledige breedte van het venster van de browser.

Als de <body> een marge heeft, komt die daar nog bij. En wordt het geheel dus breder dan 100%, oftewel: te breed voor het venster van de browser, waardoor een overbodige horizontale scrollbalk ontstaat.

Op de afbeelding staat een screenshot van een breder venster. De marge bij body is even 100 px breed gemaakt, zodat het beter is te zien. Bij de kleinere standaardmarge die browsers automatisch aan <body> geven, gebeurt in principe precies hetzelfde, alleen op kleinere schaal.

De gele header op de afbeelding is relatief gepositioneerd. De breedte past zich netjes aan de breedte van de <body> aan: links en rechts zit een marge van 100 px en de header blijft daar netjes binnen.

De footer en de rechterkolom zijn absoluut gepositioneerd en hebben een breedte van 100%, met daarbij nog een maximumbreedte van 1280 px. Duidelijk is te zien dat beide doorlopen binnen de rechtermarge van de body. Zonder de maximumbreedte van 1280 px zouden ze helemaal tot aan de rechterkant doorlopen, en zou er ook in dit brede venster een horizontale scrollbalk verschijnen.

font-family: Arial, Helvetica, sans-serif;

Lettersoort. Als er geen Arial is, wordt gezocht naar Helvetica. Als dat er ook niet is in ieder geval 'n lettersoort zonder schreef (dwarsstreepjes).

font-size: 110%;

Iets groter dan standaard. 't Zal de leeftijd zijn, maar ik vind de standaardgrootte wat te klein.

Ik gebruik hier % als eenheid, en voor alle andere lettergroottes gebruik ik em. Dat komt door Internet Explorer. Als ik als maateenheid iets als px neem, kunnen gebruikers van Internet Explorer de lettergrootte niet veranderen.

Maar als ik overal em neem als maateenheid, wat dan voor de hand zou liggen, kom ik in de problemen met versies van Internet Explorer ouder dan versie 8. De stappen van de verkleining of vergroting zijn in die browsers zo groot, dat 't gelijk onleesbaar klein of absurd groot is.

Als je nou echter bij body geen em gebruikt (font-size: 1.1em; zou hetzelfde moeten zijn als font-size: 110%;), dan is de lettergrootte in Internet Explorer te veranderen, en in oudere versies dan versie 8 zijn de tussenstappen teruggebracht tot normale grootte.

Dit werkt ook als je als lettergrootte 100% invult. Dat heeft geen enkele invloed op de lettergrootte, behalve dus dat de tussenstappen in oudere versies nu normaal werken.

In Internet Explorer 8 is deze bug eindelijk gerepareerd. Aangezien we waarschijnlijk nog vele jaren met oudere versies dan Internet Explorer 8 zitten opgescheept, zal deze truc ook nog jaren moeten worden toegepast.

header

De elementen <header>. Dat is er op deze pagina maar een: het element waar, o verrassing, de header in staat. Het is het deel met de gele achtergrond.

<header> is een van de nieuwe semantische elementen uit html5, waarover je meer kunt lezen bij Semantische elementen en outline. Eigenlijk is <header> niets anders dan een gewone <div>, die speciaal voor een header is bedoeld.

display: block;

<header> is een blok-element, maar oudere browsers herkennen dit html5-element niet.

Fatsoenlijke oudere browsers verwerken een onbekend element gewoon, maar geven het mogelijk als een inline-element weer. Dit voorkomt dat.

Onfatsoenlijke oudere browsers (Internet Explorer 7 en 8) negeren een onbekend element gewoon volledig. Je moet het eerst met behulp van JavaScript aanmaken, zoals elders gebeurt. Ook dan moet nog worden opgegeven dat <header> een blok-element is.

Maar in de (verre) toekomst zou dit niet meer nodig moeten zijn.

position: relative;

<header> moet een z-index krijgen. Dat kan alleen bij een element dat absoluut, fixed of relatief is gepositioneerd. Verder heeft de relatieve positie hier geen enkele betekenis.

z-index: 100;

Een z-index kan alleen worden gegeven aan een element dat relatief, absoluut of fixed is gepositioneerd. Dat is gelijk hierboven gedaan.

De header is 8,5 em hoog. De linker- en rechterkolom komen gelijk daaronder te staan, zodat alles goed op elkaar aansluit. Door als eenheid em te nemen, blijft alles ook goed op elkaar aansluiten bij zoomen of andere lettergroottes.

Er is alleen één probleempje: aan de onderkant van <header> staat een zwarte border van 1 px hoog. Die px komt nog bovenop de 8,5 em. Maar omdat de linker- en rechterkolom precies op 8,5 em beginnen, verdwijnt die border aan de onderkant onder de linker- en rechterkolom. Omdat die kolommen in de html na <header> komen, worden ze over <header> heen gezet.

Daarom verhoog ik de z-index van <header>. Nu wordt <header> en dus ook de border aan de onderkant boven de kolommen gezet. En is de border dus zichtbaar.

De z-index lijkt wat hoog. Maar ook de linkerkolom krijgt verderop een z-index, en die z-index moet hoger zijn dan die van de linkerkolom.

(Ook speelt hier een niet-verwerkt trauma uit het verleden mee. Ooit, diep in de vorige eeuw, heb ik ergens een serie van honderden z-indexen moeten aanbrengen. Die liet ik, onbedorven als ik nog was, met opeenvolgende getallen netjes op elkaar aansluiten. En toen moest er, helemaal aan het begin, eentje worden tussengevoegd... Sinds die tijd ben ik bedorven en laat ik ruimte vrij om later nog heel veel z-indexen tussen te kunnen voegen.)

max-width: 1280px;

Op brede schermen met een mogelijk breed venster van de browser kan de rechterkolom heel breed worden. Dat zou dan heel lange regels opleveren, die daardoor lastig leesbaar zouden zijn. Om dat te voorkomen wordt bij #content een maximumbreedte opgegeven.

Maar dan moet ik ook aan <footer> en <header> een maximumbreedte opgeven, omdat in brede vensters de header en footer anders breder worden dan de middelste twee kolommen, zoals op de afbeelding is te zien.

Als je deze maximumbreedte wilt aanpassen, moet je die hier veranderen en bij footer en #content.

height: 8.5em;

Hoogte. Als eenheid neem ik em, zodat de hoogte mee verandert met een eventuele andere lettergrootte.

Een blok-element krijgt normaal genomen automatisch precies genoeg hoogte om de inhoud ervan weer te kunnen geven. Dat is meestal prima, maar hier niet.

De linker- en rechterkolom zijn beide absoluut gepositioneerd en staan op een hoogte van 8,5 em vanaf de bovenkant van het venster van de browser. Daarom moet in dit geval de header ook altijd 8,5 em hoog zijn, ongeacht hoeveel of hoe weinig er in zit, omdat header en linker- en rechterkolom anders niet op elkaar aansluiten.

border-bottom: black solid 1px;

Zwart randje aan de onderkant.

color: black;

Voorgrondkleur zwart. Dit is onder andere de kleur van de tekst.

Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hieronder geef ik een achtergrondkleur op. Sommige mensen hebben zelf de voorgrond- en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

Door beide op te geven, weet ik redelijk zeker dat achtergrond- en tekstkleur genoeg van elkaar blijven verschillen. Als de gebruiker !important heeft gebruikt, is er nog niets aan de hand, want dan veranderen achtergrond- en voorgrondkleur geen van beide.

background: yellow;

Achtergrondkleur. Ik geef direct toe dat 'n Picasso zich zou schamen voor deze kleur, maar je kunt de header nu wel lekker duidelijk zien. Bovendien ben ik, in alle bescheidenheid, gewoon beter dan Picasso in het bedenken van schitterende kleurcombinaties.

text-align: center;

Tekst horizontaal centreren. Deze eigenschap wordt door de kinderen geërfd, dus ook de tekst binnen de <h>'s in <header> wordt nu horizontaal gecentreerd.

nav

De elementen <nav>. Dat is er hier maar eentje: de linkerkolom staat erin. Te herkennen aan de groene achtergrond.

<nav> is een van de nieuwe semantische elementen uit html5, waarover je meer kunt lezen bij Semantische elementen en outline. Eigenlijk is <nav> niets anders dan een gewone <div>, die speciaal voor een serie navigatie-links is bedoeld.

display: block;

<nav> is een blok-element, maar oudere browsers herkennen dit html5-element niet.

Fatsoenlijke oudere browsers oudere browsers verwerken een onbekend element gewoon, maar geven het mogelijk als een inline-element weer. Dit voorkomt dat.

Onfatsoenlijke oudere browsers (Internet Explorer 7 en 8) negeren een onbekend element gewoon volledig. Je moet het eerst met behulp van JavaScript aanmaken, zoals elders gebeurt. Ook dan moet nog worden opgegeven dat <nav> een blok-element is.

Maar in de (verre) toekomst zou dit niet meer nodig moeten zijn.

(Eigenlijk hoeft dit hier ook niet opgegeven te worden, omdat <nav> hieronder absoluut wordt gepositioneerd. En een absoluut gepositioneerd element verandert automatisch in een blok-element. Maar omdat het vaak wel nodig zal zijn, is het op dit moment beter om je aan te wennen áltijd een blok-element van <nav> te maken.)

position: absolute;

<nav> is een blok-element. Een blok-element krijgt normaal genomen automatisch precies genoeg hoogte om de inhoud ervan weer te kunnen geven. Dat is precies wat er op de afbeelding te zien is. Aan de groene achtergrond is te zien dat <nav> inderdaad niet hoger dan nodig is. Ook de border rechts is niet hoger dan nodig is.

Als ik niets doe, gaat dit dus niet goed.

Met behulp van een absolute positie kan ik de boven- en onderkant van <nav> op een vaste plaats zetten, waardoor het tussenliggende deel altijd gevuld is. De bovenkant zet ik gelijk onder <header>, de onderkant gelijk boven <footer>. Nu vult <nav> en dus de linkerkolom de ruimte tussen header en footer volledig.

Er wordt gepositioneerd ten opzichte van de eerste ouder die zelf een absolute, relatieve of fixed positie heeft. Als die er niet is, zoals hier het geval is, wordt gepositioneerd ten opzichte van het venster van de browser.

Normaal genomen zou de linkerkolom meescrollen met de rest van de pagina. In dit geval gebeurt dat niet, omdat de rest van de pagina helemaal niet gescrold kan worden. Alleen de rechterkolom kan worden gescrold, maar dat gebeurt binnen die kolom, niet binnen de pagina.

Bijkomend voordeel van een absolute positie is dat ik een z-index aan <nav> kan geven. Dat kan alleen bij een element dat absoluut, fixed of relatief is gepositioneerd.

Het absoluut positioneren van <nav> brengt wel een ander probleem met zich mee. Als er te veel in <nav> staat, of als de letters (sterk) worden vergroot of er wordt (sterk) ingezoomd, verschijnt een verticale scrollbalk, zodat de hele inhoud van <nav> toch bekeken kan worden. De meeste mensen scrollen met het wieltje van de muis of door in de scrollbalk te klikken of te slepen.

Je kunt echter ook scrollen met behulp van PgUp of Spatiebalk (scherm omlaag), PgUp of Shift+ Spatiebalk (scherm omhoog), ↑ (regel omhoog) en ↓ (regel omlaag). Dit werkt echter niet in Internet Explorer 7, 8 en zelfs 9 omdat <nav> absoluut is gepositioneerd. Zelfs niet na klikken in <nav>.

Door aan <nav> in de html een tabindex te geven, werken deze toetsen wel nadat je in <nav> hebt geklikt. Het werkt dan, zoals het in alle fatsoenlijke browsers spontaan al werkt.

De tabindex bepaalt de volgorde waarin links, invoervelden binnen een formulier, en dergelijke worden afgelopen als je de Tab-toets gebruikt om van plek naar plek te gaan. De Tab-toets loopt de tabindex gewoon af in de volgorde van de getallen die bij tabindex zijn ingevuld. Met twee uitzonderingen: een tabindex met een negatief getal wordt volledig genegeerd, en een tabindex met een 0 komt pas als laatste aan de beurt.

Om de normale volgorde van de tabindex niet te verstoren, heb ik daarom bij <nav> aan de tabindex een waarde van 0 gegeven.

Het is net de tafel met vier poten, waarvan er eentje te lang is: die tabindex levert ook weer 'n probleem op. Als je met de Tab-toets, of op een soortgelijke manier, een element hebt bereikt, heeft dat element focus. Bij een link bijvoorbeeld houdt dat in dat de link wordt gevolgd als je op Enter drukt. Focus wordt aangegeven door een kadertje rondom het element met focus. Dat kadertje maakt de browser automatisch aan. Als je op <nav> klikt, krijgt ook de linkerkolom zo'n kadertje.

Dat kadertje is echter niet bij alle browsers door een kunstzinnig genie gemaakt. Laat ik het subtiel en diplomatiek verantwoord zeggen: het kadertje bij Opera en Safari heeft een dikte, waar je 'n volwassen zeeschip aan af kunt meren. En 'n kleur waarmee je elke passerende haai subiet wegjaagt: knalblauw.

Heel handig bij links, want dan weet je precies waar je bent, maar hier weerzinwekkend lelijk. Dat moet dus weg, wat verderop bij nav:focus, article:focus wordt geregeld.

top: 8.5em;

Op 8,5 em vanaf de bovenkant neerzetten. Omdat <header> tot 8,5 em vanaf de bovenkant komt, sluiten <nav> en <header> precies op elkaar aan. Door als eenheid em te nemen, verandert de grootte mee met een andere lettergrootte.

bottom: 5em;

Op 5 em vanaf de onderkant neerzetten. Omdat <footer> tot 5 em vanaf de onderkant komt, sluiten <nav> en <footer> precies op elkaar aan. Door als eenheid em te nemen, verandert de grootte mee met een eventuele andere lettergrootte.

z-index: 50;

In de code komt <nav> voor div#content. Normaal genomen wordt div#content daardoor boven <nav> gezet. En omdat div#content helemaal tot aan de linkerkant doorloopt, zou <nav> hierdoor onder div#content verdwijnen.

Door aan <nav> een hogere z-index te geven, komt <nav> toch boven div#content te staan en is dus gewoon zichtbaar.

Een z-index kan alleen worden gegeven aan een absoluut, fixed of relatief gepositioneerd element. Hierboven is <nav> absoluut gepositioneerd, dus hier kan het.

width: 12em;

Breedte. Als eenheid neem ik em, zodat de breedte mee verandert met de lettergrootte.

overflow: auto;

Zonder overflow: auto; bij de linkerkolom.

Met overflow: auto; bij de linkerkolom.

<nav> heeft een beperkte hoogte, omdat boven- en onderkant zijn opgegeven. De hoogte kan daardoor nooit meer zijn dan de ruimte tussen boven- en onderkant. Als er meer in <nav> staat dan er in past, of als er wordt ingezoomd (vergroot) of de letters worden vergroot, komt de inhoud van <nav> over de footer te staan, zoals links is te zien.

Standaard staat overflow namelijk op visible, zodat standaard ook wat niet in een element past, toch is te zien. Door overflow op auto te zetten, verschijnt een verticale scrollbalk als de inhoud niet helemaal in <nav> past, zoals rechts is te zien. Ook niet echt heel fraai, vind ik persoonlijk, maar beter dan wat er rechts gebeurt.

border: black solid;

Zwarte border. De breedte geef ik hieronder op.

border-width: 0 1px 1px 0;

Boven en links geen border, rechts en onder een border van 1 px breed.

Kleur en stijl heb ik hierboven al opgegeven. Dit is in dit geval makkelijker dan rechts en onder een volledige border op te geven met border-right: black solid 1px; en border-bottom: black solid 1px;

De border rechts is logisch, dat is gewoon het randje tussen linker- en rechterkolom.

Waarom de border aan de onderkant nodig is, is iets ingewikkelder.

<footer> heeft aan de bovenkant een zwarte border van 1 px en een hoogte van 5 em. De totale hoogte is dus 5 em plus 1 px.

<nav> begint op 5 em vanaf de onderkant. <nav> begint dus al op de plaats, waar ook de border van <footer> staat.

Normaal genomen zou <footer>, en dus de border daarvan, over <nav> komen te staan, omdat <footer> later in de code staat. Maar in dit geval heeft <nav> hierboven een z-index van 50 gekregen, waardoor <nav> toch over <footer> heen komt te staan.

Dat is voor <footer> zelf geen probleem, want die is 5 em hoog, en pas daar begint <nav>. Maar de border aan de bovenkant van <footer> valt nu wel precies weg onder <nav>.

Door <nav> zelf aan de onderkant een border te geven, is er voor het oog toch een ononderbroken zwart lijntje aan de bovenkant van de footer, terwijl dit er in werkelijkheid dus twee zijn.

Op de afbeelding is dit even zichtbaar gemaakt, door de border aan de onderkant van <nav> gestreept te maken. Rechts daarvan is de border aan de bovenkant van <footer> te zien. Als je van de gestreepte border een gewone border maakt, is het resultaat voor het oog toch één lange aaneensluitende zwarte lijn.

color: black;

Voorgrondkleur zwart. Dit is onder andere de kleur van de tekst.

Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hieronder geef ik een achtergrondkleur op. Sommige mensen hebben zelf de voorgrond- en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

Door beide op te geven, weet ik redelijk zeker dat achtergrond- en tekstkleur genoeg van elkaar blijven verschillen. Als de gebruiker !important heeft gebruikt, is er nog niets aan de hand, want dan veranderen achtergrond- en voorgrondkleur geen van beide.

background: #0f0;

Lichtgroene achterkleur.

#content

Het element met id="content". De rechterkolom staat binnen twee geneste blok-elementen. Dit is de buitenste van die twee. Hij is te herkennen aan de oranje achtergrondkleur. In werkelijkheid loopt die achtergrondkleur helemaal tot aan de rechterkant van het venster van de browser door, maar dat zie je niet, omdat de groene linkerkolom eroverheen staat.

position: absolute;

De linkerkolom kan worden gescrold, als daar genoeg inhoud in staat, terwijl de rest van de pagina op z'n plaats blijft staan. Dit wordt bereikt door de linkerkolom binnen twee blok-elementen te zetten. De buitenste van die twee heeft maar één functie: doodstil op z'n plek blijven staan, wat er ook gebeurt. Als die buitenste niet beweegt, kan het binnenste blok-element doen wat het wil, zonder dat dit invloed heeft buiten het buitenste blok-element.

Ik zet het buitenste blok-element, div#content, vast door het absoluut te positioneren. Aan de bovenkant komt het tegen <header> aan te staan, aan de onderkant tegen <footer>. Bovendien geef ik het 'n breedte van 100%: even breed als het venster van de browser. Nu staat deze div aan alle kanten op 'n vaste plek.

Nu hoef je er alleen nog maar voor te zorgen dat de inhoud van div#content netjes binnen de div blijft, en dan heb ik een pagina met vaste footer, header en rechterkolom. Voor dat doel dient het binnenste blok-element <article>.

Er wordt gepositioneerd ten opzichte van de eerste ouder die zelf een fixed, relatieve of absolute positie heeft. Als die er niet is, zoals hier het geval is, wordt gepositioneerd ten opzichte van het venster van de browser.

top: 8.5em;

8,5 em vanaf de bovenkant neerzetten. <header> is 8, 5 em hoog, dus div#content sluit precies aan op <header>. Door als eenheid em te nemen, verandert top mee met de lettergrootte, waardoor de verhoudingen beter behouden blijven.

bottom: 5em;

5 em vanaf de onderkant neerzetten. <footer> is 5 em hoog, dus div#content sluit precies aan op <footer>. Door als eenheid em te nemen, verandert bottom mee met de lettergrootte, waardoor de verhoudingen beter behouden blijven.

width: 100%;

Normaal genomen wordt een blok-element zoals deze div automatisch even breed als z'n ouder. Dat is hier <body>, dus div#content zou normaal genomen even breed worden als het venster van de browser.

Maar dat is hier niet het geval, omdat div#content absoluut is gepositioneerd. Een absoluut gepositioneerd element wordt niet breder dan nodig is, om de inhoud weer te kunnen geven.

Binnen de div in dit voorbeeld is toevallig genoeg inhoud om toch de volle breedte van het browservenster te krijgen, maar bij minder inhoud zal dat niet zo zijn. Bovendien klapt in Internet Explorer 7 de hele div dicht als geen breedte wordt opgegeven.

Beide problemen worden opgelost door de div een breedte van 100% te geven. Een breedte in procenten wordt genomen ten opzichte van de ouder van het element. Dat is hier <body>. div#content wordt dus even breed als het venster van de browser.

Binnen deze div staat alleen de rechterkolom. Maar omdat de div even breed is als het hele venster van de browser, levert dat problemen op met de linkerkolom. Deze verdwijnt onder div#content. Bij nav wordt de linkerkolom echter absoluut gepositioneerd en gewoon over div#content heen gezet. Beetje autoritair, maar het werkt wel: ook al is div#content veel te breed, toch zie je nu de linkerkolom gewoon.

Nu moet ik alleen wel voorkomen dat een deel van de rechterkolom verdwijnt onder de linkerkolom, anders heb ik het probleem alleen maar verplaatst. Dat doe ik bij article door een hele grote padding aan de linkerkant te geven.

max-width: 1280px;

Op brede schermen met brede browservensters kun je heel lange regels krijgen in de rechterkolom, die daardoor moeilijk leesbaar worden. Daarom geef ik een maximumbreedte op.

Als je deze maximumbreedte wilt aanpassen, moet je die hier veranderen en bij footer en header.

color: black;

Voorgrondkleur zwart. Dit is onder andere de kleur van de tekst.

Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hieronder geef ik een achtergrondkleur op. Sommige mensen hebben zelf de voorgrond- en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

Door beide op te geven, weet ik redelijk zeker dat achtergrond- en tekstkleur genoeg van elkaar blijven verschillen. Als de gebruiker !important heeft gebruikt, is er nog niets aan de hand, want dan veranderen achtergrond- en voorgrondkleur geen van beide.

background: orange;

Oranje achtergrondkleur.

Als je in plaats van een vaste kleur een afbeelding als achtergrond wilt gebruiken, is dat wat lastiger dan normaal, omdat de rechterkolom breder is, dan wat je ziet. Bovendien kan de rechterkolom worden gescrold, terwijl de rest van de pagina altijd stil blijft staan. Bij <header>, <footer> en <nav> kun je wel op de normale manier een achtergrond-afbeelding gebruiken.

Een vaststaande achtergrond die niet meescrolt in de rechterkolom, is redelijk simpel:

background: url(naam-van-afbeelding) 12em 1px;

De linkerkolom is 12 em breed. Door de eerste achtergrond-afbeelding in div#content ook op 12 em vanaf links neer te zetten, begint de eerste afbeelding precies naast de linkerkolom.

Aan de bovenkant staat de border aan de onderkant van <header> over div#content heen, waardoor er 1 px aan de bovenkant van de achtergrond-afbeelding weg zou vallen. Daarom wordt de achtergrond-afbeelding 1 px omlaag gezet.

Een achtergrond die mee moet scrollen met de rechterkolom is iets lastiger. Gewoon neerzetten in div#content of <article> heeft geen nut, want die staan beide vast, scrollen niet. Alleen de inhoud van <article> scrolt. Dus een achtergrond scrolt ook niet mee.

Voor een meescrollende achtergrond onder de rechterkolom moet een extra div worden aangebracht binnen <article>. Gelijk na <article> komt de <div>, en pas gelijk voor </article> de bijbehorende </div>. Voor het gemak noem ik deze div even div#scrol.

Bij <article> wordt gezorgd voor een padding links en rechts in de rechterkolom. Die moet worden weggehaald, want daar gaat div#scrol voor zorgen. De padding bij <article> wordt veranderd van padding: 0 1.5em 0 13.5em; in padding: 0 0 0 12em;. Het resultaat daarvan is hiernaast te zien: de inhoud van <article> staat nu tegen de buitenkant van <article> aan.

div#scrol krijgt de achtergrond. Omdat deze div gewoon bij de inhoud van <article> hoort, zal hij meescrollen, net als de rest van de inhoud van <article>. En dus scrolt de achtergrond van div#scrol ook mee.

In het voorbeeld is het eerste element binnen <article> een <h2>. Deze heeft van zichzelf een marge aan de bovenkant. Als het eerste element een <p> zou zijn, zou er ook een marge aan de bovenkant zijn. <article> heeft zelf geen marge. In dit geval schuift de marge van het eerste blok-element binnen <article>, in het voorbeeld de <h2>, omhoog, waardoor <article> plotsklaps een marge aan de bovenkant heeft.

Dit lijkt lastig, en dat is het in dit geval ook, maar meestal is dit precies, wat je wilt.

Maar nu even niet. Het probleem is namelijk dat een achtergrond niet doorloopt onder een marge. <article> heeft plotsklaps een marge aan de bovenkant, dus div#scrol komt ook lager te staan, met als resultaat een kier tussen <header> en de achtergrond van div#scrol en dus de achtergrond van de rechterkolom. Die kier is op de afbeelding de oranje streep tussen gele header en achtergrond-afbeelding. Het is de achtergrondkleur van div#content die ertussendoor komt piepen.

Er is een aantal mogelijkheden om het probleem met die marge te voorkomen. In dit geval is het het makkelijkste om bij het eerste element binnen <article> de marge aan de bovenkant gewoon weg te halen:

article :first-child {margin-top: 0;}

Nu staat div#scrol en dus de achtergrond netjes tegen <header> aan.

Nou, eigenlijk net nog niet helemaal. Onder <header> staat nog een border van 1 px aan de onderkant, en die staat over <article> en dus ook over div#scrol heen. En dus ook over de achtergrond-afbeelding in div#scrol. Daarom wordt div#scrol 1 px omlaag gezet:

div#scrol {margin-top: 1px;}

Nu is de achtergrond-afbeelding ook aan de bovenkant volledig zichtbaar.

Als laatste moet de bij <article> weggehaalde padding weer worden aangebracht. En in dit geval moet dat ook aan de bovenkant gebeuren, want door het weghalen van de marge aan de bovenkant van het eerste kind van <article> staat de inhoud van <article> nu ook tegen de bovenkant van <article> aan. Die marge was ongeveer 1 em, dus ik moet aan de bovenkant een padding van 1 em aanbrengen, en links en rechts 1,5em:

div#scrol {padding: 1em 1.5em 0;}

Alle veranderingen op 'n rijtje:

article {padding: 0 0 0 12em;} (de rest blijft hetzelfde) article :first-child {margin-top: 0;} div#scrol {margin-top: 1px; padding: 1em 1.5em 0; background: url(naam-van-afbeelding);

Vanzelfsprekend is voor Internet Explorer 7 weer wat extra css nodig:

div#scrol {margin: 0 -1.5em;}

Boven en onder geen marge, links en rechts een negatieve marge van 1,5 em. Hierdoor wordt div#scrol links en rechts 1,5 em breder, wat een kier bij Internet Explorer 7 wegwerkt.

article

De elementen <article>. Dat is er hier maar eentje, waarbinnen alle tekst uit de rechterkolom staat.

<article> is een blok-element. Het staat binnen #content, ook een blok-element. Samen zorgen deze twee ervoor dat de rechterkolom kan worden gescrold, terwijl de rest van de pagina op z'n plaats blijft staan.

<article> is een van de nieuwe semantische elementen uit html5, waarover je meer kunt lezen bij Semantische elementen en outline. Eigenlijk is <article> niets anders dan een gewone <div>, die speciaal voor een afgerond geheel is bedoeld.

<article> staat binnen div#content. Omdat div#content absoluut is gepositioneerd, ontstaan er bij scrollen in Internet Explorer 7, 8 en zelfs 9 problemen. Hoe je die kunt oplossen, staat bij Het absoluut positioneren van <nav>... Die tekst gaat over <nav>, maar voor <article> geldt hetzelfde. Weliswaar is niet <article> absoluut gepositioneerd maar div#content, maar het effect op <article> is hetzelfde. En de oplossing ook: in de html bij <article> een tabindex van 0 toevoegen.

display: block;

<article> is een blok-element, maar oudere browsers herkennen dit html5-element niet.

Fatsoenlijke oudere browsers oudere browsers verwerken een onbekend element gewoon, maar geven het mogelijk als een inline-element weer. Dit voorkomt dat.

Onfatsoenlijke oudere browsers (Internet Explorer 7 en 8) negeren een onbekend element gewoon volledig. Je moet het eerst met behulp van JavaScript aanmaken, zoals elders gebeurt. Ook dan moet nog worden opgegeven dat <article> een blok-element is.

Maar in de (verre) toekomst zou dit niet meer nodig moeten zijn.

height: 100%;

Een blok-element als <article> krijgt normaal genomen automatisch precies genoeg hoogte om de inhoud weer te kunnen geven.

<article> staat binnen div#content. En die div is vastgezet op 8,5 em van de bovenkant en 5 em van de onderkant van het venster van de browser. Maar omdat overflow standaard op visible staat, verschijnt er rechts een scrollbalk en kun je toch alle inhoud van <article> bekijken. Alleen groeit div#content niet mee.

Omdat de scrollbalk bij de pagina verschijnt, en niet alleen bij <article>, scrolt de hele pagina mee. Het resultaat ziet er opmerkelijk creatief uit:

De inhoud van <article> die te hoog is voor het venster van de browser, wordt gewoon zichtbaar, als je scrolt. Maar omdat div#content niet meegroeit, is er geen oranje achtergrond onder het onderste deel. Bovendien scrolt de footer ook vrolijk mee, waarbij de footer terloops 'n stuk van de tekst binnen de rechterkolom afdekt. Niet helemaal wat ik voor ogen had, eerlijk gezegd.

Dit komt omdat, zoals gezegd, overflow standaard op visible staat. Dat is op zich heel prettig: als er iets misgaat, ziet het er misschien vreemd uit, maar vaak is de inhoud nog wel te lezen. In dit geval is het echter beter om overflow te temmen.

Als ik een hoogte aan <article> opgeef, kan ik vervolgens zeggen dat bij te veel inhoud een verticale scrollbalk moet verschijnen, in plaats van dat het te veel er gewoon aan de onderkant uit stroomt. Dit heeft nog 'n voordeel: bij weinig inhoud zal <article> en dus de rechterkolom in ieder geval de opgegeven hoogte krijgen.

Met height: 100%; maak ik <article> even hoog als z'n ouder. Dat is div#content, die klem is gezet tussen de header en de footer. <article> wordt dus even hoog als div#content, ongeacht hoeveel of hoe weinig erin staat, en wordt ook klem gezet tussen <header> en <footer>. Precies de bedoeling.

De scrollbalk regel ik hieronder bij overflow.

overflow: auto;

Standaard wordt de volledige inhoud van een element getoond, ook als de inhoud hoger is dan de hoogte van het element. Door overflow op auto te zetten, gebeurt dit niet meer. Als de inhoud niet binnen het element past, verschijnt een verticale scrollbalk, maar alleen als dat nodig is.

padding: 0 1.5em 0 13.5em;

Aan de bovenkant geen padding. De marge aan de bovenkant van de eerste <h2> zorgt al voor wat afstand tussen bovenkant en inhoud van <article>.

Rechts een padding van 1,5 em.

Aan de onderkant geen padding. Hoewel er geen enkel bezwaar zou zijn tegen 'n padding.

Links een hele grote padding van 13, 5 em. <article> is even breed als div#content, waar het in staat. Je ziet het niet, maar in werkelijkheid is <article> daardoor even breed als het venster van de browser.

Aan de linkerkant is de linkerkolom absoluut gepositioneerd boven div#content, en dus ook boven <article>. Daardoor zou aan de linkerkant een behoorlijk deel van de tekst binnen <article> wegvallen onder de linkerkolom. Dat is precies wat er op de afbeelding gebeurt, omdat <article> links een padding van slechts 1,5 em heeft.

De linkerkolom is 12 em breed. Door een padding van 13,5 em te nemen, komt de inhoud van <article> naast de linkerkolom te staan en houd ik nog 1,5 em lege ruimte tussen linkerkolom en inhoud van <article> over.

Als eenheid neem ik em, zodat de maten mee veranderen met de lettergrootte. Hierdoor blijven de verhoudingen beter behouden.

footer

De elementen <footer>. Dat is er hier maar eentje: de footer staat erin. Hij is te herkennen aan de lichtblauwe achtergrond.

<footer> is een van de nieuwe semantische elementen uit html5, waarover je meer kunt lezen bij Semantische elementen en outline. Eigenlijk is <footer> niets anders dan een gewone <div>, die speciaal voor een footer is bedoeld.

display: block;

<footer> is een blok-element, maar oudere browsers herkennen dit html5-element niet.

Fatsoenlijke oudere browsers oudere browsers verwerken een onbekend element gewoon, maar geven het mogelijk als een inline-element weer. Dit voorkomt dat.

Onfatsoenlijke oudere browsers (Internet Explorer 7 en 8) negeren een onbekend element gewoon volledig. Je moet het eerst met behulp van JavaScript aanmaken, zoals elders gebeurt. Ook dan moet nog worden opgegeven dat <footer> een blok-element is.

Maar in de (verre) toekomst zou dit niet meer nodig moeten zijn.

(Eigenlijk hoeft dit hier ook niet opgegeven te worden, omdat <footer> hieronder absoluut wordt gepositioneerd. En een absoluut gepositioneerd element verandert automatisch in een blok-element. Maar omdat het vaak wel nodig zal zijn, is het op dit moment beter om je aan te wennen áltijd een blok-element van <footer> te maken.)

position: absolute;

Om de footer op de juiste plaats neer te kunnen zetten.

Er wordt gepositioneerd ten opzichte van de eerste ouder die zelf absoluut, relatief of fixed is gepositioneerd. Als die er niet is, zoals hier het geval is, wordt gepositioneerd ten opzichte van het venster van de browser.

Normaal genomen zou de footer meescrollen met de rest van de pagina en dus niet onderaan het venster van de browser blijven staan. Dat speelt hier niet, omdat de pagina helemaal niet gescrold kan worden. Alleen de rechterkolom kan worden gescrold, maar dat gebeurt binnen die kolom, niet binnen de pagina.

bottom: 0;

Onderaan het venster van de browser zetten.

width: 100%;

Normaal genomen krijgt een blok-element zoals <footer> automatisch dezelfde breedte als z'n ouder. Die ouder is hier <body>, dus normaal genomen zou <footer> even breed worden als de pagina. Wat hier precies de bedoeling is.

Maar als een element absoluut is gepositioneerd, dan wordt het niet breder dan nodig is, om de inhoud weer te kunnen geven.

Op de afbeelding is te zien dat <footer> eindigt waar de tekst, de inhoud van <footer>, eindigt. Als er genoeg inhoud is om meer dan één regel te vullen, wordt <footer> wel even breed als <body>. Maar het is veiliger om gewoon zelf een breedte op te geven. Dan weet je zeker dat het altijd goed gaat, bijvoorbeeld ook als mensen de lettergrootte verkleinen.

Een breedte in procenten wordt altijd genomen ten opzichte van de ouder van het element. Dat is hier <body>, dus <footer> wordt nu altijd even breed als de pagina.

max-width: 1280px;

Op brede schermen met een mogelijk breed venster van de browser kan de rechterkolom heel breed worden. Dat zou dan heel lange regels opleveren, die daardoor lastig leesbaar zouden zijn. Om dat te voorkomen wordt bij #content een maximumbreedte opgegeven.

Maar dan moet ik ook aan <footer> en <header> een maximumbreedte opgeven, omdat in brede vensters de header en footer anders breder worden dan de middelste twee kolommen. Bij max-width 1280px staat een screenshot, waarin je kunt zie hoe dat eruit ziet.

Als je deze maximumbreedte wilt aanpassen, moet je die hier veranderen en bij header en #content.

height: 5em;

5 em hoog maken. Omdat de onderkant absoluut is gepositioneerd op de onderkant van het browservenster, groeit de hoogte vanaf de onderkant. Als wordt ingezoomd (vergroot) of als de letters worden vergroot, schuift de bovenkant van <footer> omhoog.

De linker- en rechterkolom lopen tot 5 em van de onderkant, dus die sluiten precies aan op de footer.

Als eenheid neem ik em, zodat de hoogte ook mee verandert met een andere lettergrootte.

border-top: black solid 1px;

Zwart lijntje aan de bovenkant.

En hier ontstaat een klein probleem. De hoogte van <footer> is 5 em. En daar komt de ene px van deze border nog bij. Linker- en rechterkolom lopen echter tot precies 5 em vanaf de onderkant, dus de onderste px daarvan staat op dezelfde plaats als deze border.

Omdat <footer> in de html na de linker- en rechterkolom komt, zou dat geen probleem hoeven te zijn. Wat later in de html komt, wordt normaal genomen over eerdere delen heen gezet.

Voor de rechterkolom werkt dat ook zo: de border wordt gewoon over de onderste px van de rechterkolom heen gezet en is dus zichtbaar.

Voor <nav> met de linkerkolom gaat het mis. <nav> heeft een z-index van 50 gekregen en wordt dus over <footer> heen gezet, waardoor de border verdwijnt. Daarom wordt bij nav een border gegeven aan de onderkant van <nav>. Nu staat er voor het oog toch 'n doorlopende zwarte lijn boven de footer, hoewel die lijn in werkelijkheid uit twee delen bestaat: onder de rechterkolom de border aan de bovenkant van <footer>, en onder de linkerkolom de border aan de onderkant van <nav>.

color: black;

Voorgrondkleur zwart. Dit is onder andere de kleur van de tekst.

Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hieronder geef ik een achtergrondkleur op. Sommige mensen hebben zelf de voorgrond- en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

Door beide op te geven, weet ik redelijk zeker dat achtergrond- en tekstkleur genoeg van elkaar blijven verschillen. Als de gebruiker !important heeft gebruikt, is er nog niets aan de hand, want dan veranderen achtergrond- en voorgrondkleur geen van beide.

background: #0ff;

Achtergrond lichtblauw.

text-align: center;

Tekst horizontaal centreren. Deze eigenschap wordt geërfd door de kinderen van <footer>, dus ook de tekst binnen de <h2> wordt gecentreerd.

JavaScript voor Internet Explorer 7 en 8

In de <head> staat, gelijk onder de css, een klein stukje JavaScript, binnen een 'conditional comment':

Omdat deze code tussen <!-- en --> staat, wordt de code gezien als een commentaar en dus genegeerd door de browser. Behalve door Internet Explorer. Microsoft heeft een handigheidje bedacht, waardoor je het commentaar kunt gebruiken om alleen voor (een bepaalde versie van) Internet Explorer code te schrijven. Dat is wel nodig ook, want hoe ouder de versie, des te groter de ongelooflijke verzameling bugs en afwijkingen die Microsoft in z'n browsers heeft weten te proppen. Pas Internet Explorer 9 begint zich een een heel klein beetje als een volwassen browser te gedragen. Niet dat het evenveel kan als andere browsers, bij lange na niet, maar hij verpest in ieder geval niet meer van alles.

<!--[if lt IE 9]>: om het stukje tussen de teksthaken gaat het: if lt IE 9. lt is een afkorting voor less than: minder dan. In normale mensentaal staat hier: als minder dan Internet Explorer 9. Oftewel: elke versie van Internet Explorer ouder dan versie 9.

Omdat ik alleen versie 7 en 8 nog ondersteun, gaat het in dit geval alleen om die twee. Het zou kunnen dat dit in Internet Explorer 6 werkt, het zou ook kunnen dat je computer in de fik vliegt en dat je partner de benen neemt. Dit stukje code opent het deel dat alleen door Internet Explorer 7 en 8 wordt gelezen.

<![endif]--> sluit de code voor Internet Explorer weer af.

Het is belangrijk dat de spaties in <!--[if lt IE 9]> en <![endif]--> precies zo worden overgenomen, zoals ze hier staan, want anders werkt het niet.

<script> en </script> geven gewoon het begin en einde van het JavaScript aan. Bij html5 hoef je geen type meer op te geven, want het staat standaard op JavaScript ingesteld.

Het eigenlijke JavaScript bestaat uit:

Tegen de standaard in kun je in Internet Explorer 8 en ouder geen css gebruiken bij onbekende elementen. En hier worden de nieuwe html5-elementen <header>, <section>, <nav>, <article> en <footer> gebruikt. De css voor deze elementen zou dus niet werken.

Door nu via JavaScript de voor Internet Explorer 7 en 8 onbekende elementen gewoon zelf aan te maken, blijken ze plotsklaps wél herkend te worden. En kan dus gewoon css voor deze elementen worden gebruikt.

(In feite worden de elementen aan de DOM toegevoegd, een soort inhoudsopgave van onder andere alle html-elementen in een pagina.)

Internet Explorer 9 kent deze elementen wel, dus hier speel dit probleem niet meer. (Internet Explorer 9 herkent trouwens, zoals het hoort, ook onbekende elementen, zodat je daar hoe dan ook css en zo bij kunt gebruiken.)

Anders dan vaak het geval is, moet deze JavaScript in de <head> van de pagina staan. De browser moet de elementen al kennen, voordat ze kunnen worden weergegeven. Als de elementen worden gelezen, voordat ze zijn aanemaakt, worden ze gewoon genegeerd. En kan er dus ook geen css aan worden gegeven.

Deze JavaScript is uiterst beperkt: alleen de hier gebruikte html5-elementen worden aangemaakt, en dan alleen nog maar voor weergave op een scherm. Als je meer wilt doen dan alleen dit, is het mogelijk beter om voor Internet Explorer 7 en 8 het JavaScript op html5shim te gebruiken.

Dit betekent helaas ook dat de css in Internet Explorer 7 en 8 niet werkt, als de bezoeker JavaScript uit heeft staan. Maar normaal genomen staat JavaScript alleen uit vanwege de veiligheid. En als je ook maar enigszins met veiligheid bezig bent, dan zul je niet Internet Explorer 7 of 8 gebruiken. Dus het aantal mensen waarbij in deze verouderde browsers JavaScript uit zal staan, is waarschijnlijk te verwaarlozen.

Mocht dit wel een bezwaar zijn, dan zul je <nav> en dergelijke door een gewone <div> moeten vervangen.

Een andere mogelijkheid is het gebruik van <noscript>, zoals ik op de site heb gedaan. Dit moet dan alleen voor Internet Explorer 7 en 8 worden gebruikt, want andere browsers herkennen de nieuwe elementen en hebben geen JavaScript nodig. In Internet Explorer kan <noscript> alleen css krijgen via een inline-style. Het wordt dan zoiets:

Los van dat <noscript> alleen css binnen ’n inline-style kan verwerken, moet ook nog ’n extra <div> worden gebruikt. Als je de style met <noscript style="..."> zou gebruiken, wordt een deel van de inhoud van <noscript> altijd getoond in Internet Explorer 8, ook al staat JavaScript aan.

De code aanpassen aan je eigen ontwerp

• Als je dit voorbeeld gaat aanpassen voor je eigen site, houdt het dan in eerste instantie zo eenvoudig mogelijk. Ga vooral geen details invullen.

• Gebruik vooral geen FrontPage, Publisher of Word (alle drie van Microsoft). Deze programma's maken niet-standaard code, die alleen goed te bekijken is in Internet Explorer. In alle andere browsers zie je grotendeels bagger, áls je al iets ziet.

  Publisher en Word zijn niet bedoeld om websites mee te maken. FrontPage is zwaar verouderd en wordt niet meer onderhouden door Microsoft. Als je beslist iets van Microsoft wilt gebruiken, schaf dan (voor honderden euro's) een nieuwer programma aan, dat zich wel aan de standaarden houdt.

  Je kunt natuurlijk ook een goed gratis programma gebruiken. Links naar dat soort programma's vind je op de pagina met links onder Gereedschap → wysiwyg-editor.

  Maar het allerbeste is om gewoon zelf html, css, enz. te leren, omdat zelfs het allerbeste programma het nog steeds zwaar verliest van 'n op de juiste manier met de hand gemaakte pagina.

• Het beste kun je 'n site maken in Firefox. Als je 'n site maakt in Firefox, Opera, Safari of Google Chrome, is er 'n hele grote kans dat hij in alle browsers werkt. Als je in Internet Explorer begint, is dat niet zo. Dat heeft te maken met historische oorzaken (als je geïnteresseerd bent: zoek maar naar 'boxmodel' en 'probleem' of zo op internet, of naar 'quirks mode'). Ik geef de voorkeur aan Firefox, omdat er zoveel extensies (uitbreidingen) voor bestaan. De twee belangrijkste voor 't maken van sites zijn Web Developer en Firebug, maar er bestaan nog tientallen andere.

• Het allereerste dat je moet invoeren, is het doctype, vóór welke andere code dan ook. Een lay-out met een missend of onvolledig doctype ziet er totaal anders uit dan een lay-out met een geldig doctype. Wát er anders is, verschilt ook nog 'ns tussen de diverse browsers. Als je klaar bent en dan nog 'ns 'n doctype gaat invoeren, weet je vrijwel zeker dat je van voren af aan kunt beginnen met de lay-out.

  Geldige doctypes vind je op www.w3.org/QA/2002/04/valid-dtd-list.html.

  Gebruik het volledige doctype, inclusief de url, anders werkt het niet goed.

• Gebruik een 'strict' doctype of het doctype voor html5. Deze zijn bedoeld voor nieuwe sites. Het transitional doctype is bedoeld voor al bestaande sites, niet voor nieuwe. Het transitional doctype staat talloze tags toe, die in html5 zijn verboden. Deze tags worden al zo'n tien jaar afgeraden. Het transitional doctype is echt alleen bedoeld om de puinhoop van vroeger, toen niet volgens standaarden werd gewerkt, enigszins te herstellen.

  Het strict doctype staat verouderde tags niet toe. Daardoor kan met 'n strict doctype, of het nu html of xhtml is, probleemloos worden overgestapt naar html5. Met een transitional doctype en het gebruik van afgekeurde tags kun je niet overstappen naar html5. Je moet dan eerst alle verouderde tags verwijderen, wat echt ontzettend veel werk kan zijn.

• Als tweede voer je de charset in. Het beste kun je utf-8 nemen. Als je later van charset verandert, loop je 'n grote kans, dat je alle aparte tekens als letters met accenten weer opnieuw moet gaan invoeren.
• Test vanaf het allereerste begin in zoveel mogelijk verschillende browsers in 'n aantal resoluties (schermgroottes). Onder het kopje Getest in kun je in deze uitleg vinden waar ikzelf op test. Ook van Internet Explorer kun je meerdere versies naast elkaar draaien. Je kunt daarvoor zoeken op internet en op de pagina met links staan onder de kopjes Gereedschap → Meerdere versies van Internet Explorer draaien en Gereedschap → Weergave testen 'n aantal links, die daar ook bij kunnen helpen.
• Voor alle voorbeelden geldt: breng veranderingen stapsgewijs aan. Als je bijvoorbeeld foto's wilt laten weergeven, begin dan alleen met het veranderen van de namen van de foto's, zodat je eigen foto's worden weergegeven. Maakt niet uit als de maten niet kloppen en de teksten fout zijn. Als dat werkt, ga dan bijvoorbeeld de maten aanpassen. Dan de teksten. En controleer steeds, of alles nog goed werkt.

• Als het om een lay-out of iets dergelijks gaat: zorg eerst dat header, kolommen, footer, menu, en dergelijke staan en bewegen zoals je wilt, en ga dan pas details binnen die blokken invullen. In eerste instantie gebruik je dus bijvoorbeeld 'n leeg blok voor waar uiteindelijk het menu komt te staan.

  Als je begint met allerlei details, is er 'n heel grote kans dat die de werking van de blokken gaan verstoren. Bouw eerst het huis, en ga dan pas de kamers inrichten. Als de blokken eenmaal werken zoals je wilt, zul je het gelijk merken als 'n toegevoegd detail als tekst of 'n afbeelding iets gaat storen. Daarvoor moet je natuurlijk wel regelmatig controleren in verschillende browsers, of alles nog wel goed werkt.

  Je kunt de blokken tijdens het aanpassen opvullen met bijvoorbeeld <br>1<br>2<br>3 enz., tot ze de juiste hoogte hebben. Het is handig om aan het einde even iets toe te voegen als 'laatste', zodat je zeker weet dat er niet drie regels onderaan naar 't virtuele walhalla zijn verhuisd.

  Om de breedte te vullen kun je het best 'n kort woord als 'huis' duizend keer of zo herhalen. Ook hier is het handig om aan 't einde (en hier ook aan 't begin) 'n herkenningsteken te maken, zodat je zeker weet dat je de hele tekst ziet.

• Zolang je in grotere dingen zoals 'n lay-out aan 't wijzigen bent, zou ik je aanraden de verschillende delen een achtergrondkleur te geven. Je ziet dan goed, waar 'n deel precies staat.
• Als je instellingen verandert in de style, verander er dan maar één, hooguit twee tegelijk. Als je er zeventien tegelijk verandert, moet je niet verbaasd zijn, als je niet weet wat er is gebeurd. En als je 't niet meer terug kunt draaien.
• Marges, padding en border worden bij de hoogte en breedte van de inhoud opgeteld. Hier worden vaak fouten mee gemaakt. Als je bijvoorbeeld in een lay-out 'n border toevoegt aan een van de 'hoofdvakken' (header, footer, kolommen), dan wordt deze er dus bij opgeteld. Bij 'n border van 2 px rondom de linkerkolom wordt deze dus plotseling 4 px breder (2 aan beide kanten), en 4 px hoger. Zoiets kan je hele lay-out verstoren, omdat iets net te breed of te hoog wordt. Je moet dan elders iets 4 px kleiner maken. Dat zal vaak zo zijn: als je één maat verandert, zul je vaak ook 'n andere moeten aanpassen.
• In plaats van px kun je ook andere maten gebruiken, met name em. Voordeel van em is dat het door de gebruiker kan worden vergroot en verkleind, ook in Internet Explorer (andere browsers hebben meer mogelijkheden op dit gebied). Nadeel is dat het de lay-out sneller kan verstoren dan bijvoorbeeld px. Dit moet je gewoon van geval tot geval bekijken.

• Valideren, valideren, valideren en dan voor 't slapen gaan nog 'ns valideren.

  Valiwie???

  Valideren is het controleren van je html en css op 'n hele serie fouten. Computers zijn daar vaak veel beter in dan mensen. Als je 300 keer <h2> hebt gebruikt en 299 keer </h2> vindt 'n computer die ene missende </h2> zonder enig probleem. Jij ook wel, maar daarna ben je misschien wel aan vakantie toe.

  Je kunt je css en html zowel valideren als 't online staat, als wanneer 't nog in je computer staat. Web Developer ('n Firefox-extensie) heeft zelfs 'n mogelijkheid om de html voortdurend, bij elke wijziging, opnieuw te valideren. (Die mogelijkheid is er ook bij css, maar daar wordt altijd aangegeven dat 't valid is, wat je er ook aan onzin in zet. Maar als je in de balk op css klikt ga je naar de echte validator, en die controleert wel goed.)

  html kun je valideren op: validator.w3.org

  css kun je valideren op: jigsaw.w3.org/css-validator

  Valideren kan helpen om gekmakende fouten te vinden. Valid code garandeert ook, dat de weergave in verschillende browsers (vrijwel) hetzelfde is. En valid code is over twintig jaar ook nog te bekijken.

Toegankelijkheid en zoekmachines

Het eerste deel van deze tekst is voor alle voorbeelden hetzelfde. Eventueel specifiek voor dit voorbeeld geldende dingen staan verderop onder het kopje Specifiek voor dit voorbeeld.

Toegankelijkheid (accessibility in het Engels) is belangrijk voor bijvoorbeeld blinden die een spraakbrowser gebruiken, of voor motorisch gehandicapte mensen die moeite hebben met het bedienen van een muis. Een spider van een zoekmachine (dat is het programmaatje wat de site indexeert voor de zoekmachine) is te vergelijken met een blinde. Als je je site goed toegankelijk maakt voor gehandicapten, is dat dus gelijk goed voor een hogere plaats in een zoekmachine. Dus als je 't niet uit sociale motieven wilt doen, kun je 't uit egoïstische motieven doen.

(Op die plaats in de zoekmachine heb je maar beperkt invloed. De toegankelijkheid van je site is maar één van de factoren, maar zeker niet onbelangrijk.)

Als je bij het maken van je site al rekening houdt met toegankelijkheid, is dat nauwelijks extra werk. 't Is ongeveer te vergelijken met inbraakbescherming: doe dat bij 'n nieuw huis en 't is nauwelijks extra werk, doe 't bij 'n bestaand huis en 't is al snel 'n enorme klus.

Enkele tips die helpen bij toegankelijkheid:

• Gebruik altijd een alt-beschrijving bij een afbeelding. De alt-tekst is wat wordt gebruikt, als afbeeldingen niet kunnen worden gezien (dat geldt dus ook voor zoekmachines). Als je iets wilt laten zien als je over de afbeelding hovert, gebruik daar dan het title-attribuut voor, niet de alt-beschrijving.
• Gebruik bij een link een title, waarin je omschrijft waar de link naar toe leidt.

• Accesskeys (sneltoetsen) kun je beter niet gebruiken. Deze gaven te veel problemen, omdat ze vaak dubbelop zijn met sneltoetsen voor de browser of andere al gebruikte sneltoetsen. Bovendien is voor de gebruiker meestal niet duidelijk, welke toetsen het zijn.

  In de komende html5 waren ze eerst niet toegestaan, maar inmiddels lijkt het erop dat ze toch worden toegestaan, maar op 'n andere manier dan in html 4.01. Ik ga ze zelf pas weer gebruiken, als duidelijk is hoe ze gaan werken, en als ze beter zijn uitgedacht dan in html 4.01 het geval was, want bij een goede toepassing is het op zich een heel goed idee.

• Met behulp van de Tab-toets (of op 'n soortgelijke manier) kun je in de meeste browsers door de links lopen. Elke tab brengt je één link verder, Shift+Tab één link terug. Met behulp van tabindex kun je de volgorde aangeven waarin de Tab-toets werkt. Zonder tabindex wordt de volgorde van de code aangehouden, maar soms is een andere volgorde logischer.

• In het verleden werd vaak aangeraden de volgorde van de code aan te passen. Een menu bijvoorbeeld kon in de html onderaan worden gezet, terwijl het op het scherm met behulp van css bovenaan werd gezet. Inmiddels zijn screenreaders en dergelijke zo verbeterd, dat dit niet meer wordt aangeraden. De volgorde in de html kan tegenwoordig beter hetzelfde zijn als op het scherm, omdat het anders juist verwarrend kan werken.

  Een andere mogelijkheid is een zogenaamde skip-link: een link die je buiten het scherm parkeert met behulp van css, zodat hij normaal genomen niet te zien is. Zo'n link is wel zichtbaar te maken in speciale programma's zoals spraakbrowsers. Die link staat boven menu, header, en dergelijke, en linkt naar de inhoud van de pagina, zodat mensen met één klik het hele menu kunnen passeren.

• Van oorsprong was html een taal om wetenschappelijke documenten weer te geven, pas later is hij gebruikt voor lay-out. Maar daar is hij dus eigenlijk nooit voor bedoeld geweest. Het gebruiken van html voor lay-out leidt tot enorme problemen voor gehandicapten en tot een lage plaats in zoekmachines.

  De html hoort alleen inhoud te bevatten, lay-out doe je met behulp van css. Die css moet in een extern stylesheet staan of, als hij alleen voor één bepaalde pagina van toepassing is, in de head van die pagina. Zoekmachines zijn ook niet dol op een oerwoud van inline-stijlen (dat zijn stijlen in de tag zelf: <div style="...">.)

• Breng een logische structuur aan in je document. Gebruik een <h1>voor de belangrijkste kop, een <h2> voor een subkop, enz. Spraakbrowsers en dergelijke kunnen van kopregel naar kopregel springen. En een zoekmachine gaat ervan uit dat <h1> belangrijke tekst bevat.

  Dit geldt voor al dit soort structuurbepalende tags.

  Als een <h1> te grote letters geeft, maak daar dan met behulp van je css 'n kleinere letter van, maar blijf die <h1> gewoon gebruiken. Op dezelfde manier kun je al dit soort dingen oplossen.

• Een table is fantastisch, maar alleen als die wordt gebruikt om een echte tabel weer te geven, niet als hij voor opmaak wordt misbruikt. In het verleden is dat op grote schaal gebeurd bij gebrek aan andere mogelijkheden. Een tabel is, als je niet heel erg goed oplet, volstrekt ontoegankelijk voor gehandicapten en zoekmachines. Het lezen van een tabel is ongeveer te vergelijken met het lezen van een krant van links naar rechts: niet per kolom, maar per regel. Dat gaat dus alleen maar goed bij een echte tabel zoals een spreadsheet. In alle andere gevallen garandeert 'n tabel 'n lagere plaats in een zoekmachine.

• Frames zijn een volstrekt verouderde techniek, die heel veel nadelen met zich meebrengt. Deze zijn hier netjes op een rijtje gezet: Webrichtlijnen. iframes hebben voor een deel dezelfde nadelen.

  Als je 'n stuk code vaak wilt gebruiken, zoals 'n menu dat op elke pagina hetzelfde is, include dat dan met PHP of SSI. Dan ziet iedereen (ook 'n zoekmachines dus!) alles als één pagina in plaats van als los zand aan elkaar hangende teksten.

• Geef de taal van het document aan, en bij woorden en dergelijke die afwijken van die taal de afwijkende taal met behulp van lang="..". Ik doe dat op mijn eigen site maar af en toe, omdat de tekst (en vooral de code) een mengsel is van Engels, Nederlands en eigengemaakte namen. Dit soort teksten is gewoon niet goed in te delen in een taal.
• Gebruik de tag <abbr> bij afkortingen. Doe dat de eerste keer op een pagina samen met de title-eigenschap: <abbr title="en dergelijke">e.d.</abbr>. Daarna kun je op dezelfde pagina volstaan met <abbr>e.d.</abbr>. Doe je dit niet, dan is er 'n grote kans dat 'n spraakbrowser e.d. uit gaat spreken als Ed, en 'n zoekmachine kan er ook geen chocola van maken.

• De spider van 'n zoekmachine, spraakbrowsers, en dergelijke kunnen geen plaatjes 'lezen'. Het is soms verbazingwekkend om te zien hoe veel, of eigenlijk: hoe weinig tekst er overblijft op een pagina als de plaatjes worden weggehaald. Hetzelfde geldt voor die fantastisch mooie flash-pagina's, als daarbij geen voorzieningen voor dit soort programma's zijn aangebracht.

  Op Linux kun je met Lynx kijken hoe je pagina eruitziet zonder plaatjes en dergelijke, als echt alleen de tekst overblijft. Een installatie-programma voor Lynx op Windows is te vinden op csant.info/lynx.

  In Windows kun je ook het gratis programma WebbIE installeren. WebbIE laat de pagina zien, zoals een spraakbrowser en dergelijke hem zien. WebbIE is te downloaden vanaf www.webbie.org.uk. Nog een soortgelijk gratis programma is WebFormator.

  De Firefox-extensie Web Developer heeft de mogelijkheid om 'n pagina te bekijken zonder css en/of afbeeldingen.

  Tenslotte kun je je pagina nog online laten controleren op 'n behoorlijk aantal sites. Ik noem er hier enkele. Helaas zijn ze bijna allemaal Engelstalig.

  colorfilter.wickline.org Laat zien hoe een kleurenblinde de site ziet.

  contentquality.com Test op toegankelijkheid. Heel overzichtelijk.

  wave.webaim.org Deze laat grafisch zien hoe de toegankelijkheid is. Heel erg duidelijk, maar bij grotere pagina's wordt 't al snel erg chaotisch.

  Omdat ze de uitleg van de icoontjes heel goed hebben weten te verstoppen, geef ik de link daarvan ook maar gelijk: wave.webaim.org/icons

  www.webrichtlijnen.nl/toetsen De enige Nederlandstalige site. Test op toegankelijkheid.

Specifiek voor dit voorbeeld

Zonder css wordt de site in de volgorde van de html op het scherm gezet: header, linkerkolom, rechterkolom (met de content), footer. Dit is ook zoals de meeste spraakbrowsers en dergelijke het zullen zien. Daarom kan het goed zijn boven bijvoorbeeld een menu een zogenaamde skip-link te zetten, zodat gebruikers van spraakbrowsers en dergelijke in één keer het menu kunnen passeren en snel naar de content kunnen gaan.

Getest in

Laatst gecontroleerd op 4 april 2012.

Dit voorbeeld is getest in Firefox, Opera, Safari, Google Chrome, Internet Explorer 7, 8 en 9 in de resoluties 800x600, 1024x768, 1280x1024 en 1440x900. Steeds met de laatste versie van die browsers, omdat ik geen zin heb om rekening te houden met mensen die met zwaar verouderde browsers surfen. Dat is trouwens vragen om ellende, want updates van browsers hebben heel vaak met beveiligingsproblemen te maken. In de resoluties 1024x768, 1280x1024 en 1440x900 is ook in- en uitzoomen en een kleinere en grotere letter getest. Er is ingezoomd en vergroot tot zover de browser kan, maar niet verder dan tot 200%.

Eventuele problemen met betrekking tot zoomen en lettergrootte staan bij Bekende problemen.

Er is getest met behulp van muis en toetsenbord.

Naast deze 'gewone' browsers is ook getest in Lynx, WebbIE, NVDA en Fangs Screen Reader Emulator. Lynx is een browser die alleen tekst laat zien en geen css gebruikt. WebbIE is een browser die gericht is op mensen met een handicap. NVDA is een screenreader, zoals die door blinden wordt gebruikt. Fangs Screen Reader Emulator is een extensie bij Firefox, die de pagina laat zien zoals een screenreader hem ziet.

Als het voorbeeld in deze vier programma's toegankelijk is, zou het in principe toegankelijk moeten zijn in alle aangepaste browsers en dergelijke. En dus ook voor zoekmachines, want een zoekmachine is redelijk vergelijkbaar met een blinde. Eventuele opmerkingen over de toegankelijkheid van dit voorbeeld staan onderaan Toegankelijkheid en zoekmachines onder het kopje Specifiek voor dit voorbeeld.

Alleen op de hierboven genoemde systemen en browsers is getest. Er is dus niet getest op bijvoorbeeld mobiele systemen als iOS of Android, en ook niet op apparaten als smartphones, iPad, enz. De kans is heel erg groot dat dit voorbeeld niet (volledig) werkt op dat soort systemen en apparaten. Om het wel (volledig) werkend te krijgen, zul je vaak wijzigingen en/of aanvullingen moeten aanbrengen.

De html is gevalideerd met de validator van w3c, de css ook. Als om een of andere reden niet volledig gevalideerd kon worden, wordt dat bij Bekende problemen vermeld.

Nieuwe browsers test ik pas als ze uit het bèta-stadium zijn, omdat er anders 'n redelijke kans is dat ik 'n bug zit te omzeilen, die voor de uiteindelijke versie nog gerepareerd wordt. Dit voorbeeld is alleen getest in de hierboven met name genoemde browsers. Vragen over niet-geteste browsers kan ik niet beantwoorden, en het melden van fouten in niet-geteste browsers heeft ook geen enkel nut. (Melden van fouten, problemen, enz. in wel geteste browsers: graag!)

Wijzigingen

Alleen grotere wijzigingen worden hier vermeld, geen dingen als een link die is geüpdatet.

Oktober 2007:

Nieuw opgenomen.

10 augustus 2008:

Totaal herschreven. De vorige versie hield veel meer rekening met Internet Explorer 6. Deze versie werkt nog wel in die browser, maar maakt veel meer gebruik van dingen die andere browsers wel kunnen en Internet Explorer 6 niet. De veranderingen in de code aangeven is onbegonnen werk, hier alleen maar de belangrijkste en de voordelen daarvan.

• In plaats van allerlei ingewikkelde constructies wordt position: fixed; gebruikt om elementen vast te zetten. Voor Internet Explorer 6 wordt 'n omweg gebruikt.

• Als er in de vorige versie geen scrollbar was vanwege weinig inhoud, was 'n waanzinnig ingewikkelde constructie nodig bij het gebruik van achtergrond-afbeeldingen. Dat is nu niet meer nodig. Bij Internet Explorer 6 kan het nog wel enigszins lastig zijn.

• Bij gebruik van PgDn, PgUp, de spatiebalk en klikken in de scrollbalk werd in de vorige versie meer dan 1 venster verplaatst, behalve in Internet Explorer 6 en 7. Nu werkt dit goed in alle browsers, behalve in Internet Explorer 6: daar wordt iets meer dan 1 venster gescrold bij gebruik van PgDn, PgUp, spatiebalk en klikken in de scrollbalk. Scrollwieltje en pijltjestoetsen werken wel gewoon goed.

• Bij 'n grotere lettergrootte worden header en footer hoger en de linkerkolom breder (en de rechterkolom dus smaller). Er verdwijnt dus geen inhoud meer (behalve bij onwijs sterke vergrotingen).

• Zoomen werkt nu ook goed in Firefox 3. In de vorige versie ontstonden kieren tussen de diverse onderdelen. Bij inzoomen (vergroten) in Internet Explorer 7 verdwijnt door een bug in die browser aan de rechterkant wel inhoud. In versie 8 is dat verholpen. Als je alleen de letters vergroot in Internet Explorer 7 gaat 't wel goed.

• Bij Internet Explorer 6 verdween inhoud uit de rechterkolom onder de linkerkolom als je de letters vergrootte.

• Bij Opera kon je de footer niet te vol maken, want dan kon de lay-out in de war raken als je helemaal omlaag scrolde.

30 maart 2009:

Tekst aangepast aan de nieuw verschenen Internet Explorer 8. De code is hetzelfde gebleven.

6 september 2010:

• Toen ik met deze site begon, had xhtml de toekomst. Inmiddels is dat html, en dat blijft ook zo. Nieuwe voorbeelden maak ik in html. Omdat dit voorbeeld, vooral de uitleg, als template voor andere wordt gebruikt, heb ik het doctype veranderd in dat van html5. Omdat ik al met een strict doctype werkte, verandert er verder nauwelijks iets.
• En omdat ik toch wat veranderde, gelijk alles met een background-color ook een color gegeven. Dit vanwege de toegankelijkheid, zoals bij de Beschrijving op de betreffende plaatsen wordt toegelicht.

1 juni 2011:

Bij Opmerkingen stukje over max-width toegevoegd.

4 april 2012:

Volledig herschreven.

• Alles voor Internet Explorer 6 eruit gesloopt. Nu die ongein eruit is, is de code gelijk 'n heel stuk overzichtelijker en simpeler.
• De nieuwe semantische html5-elementen <nav>, <header>, <footer>, <section> en <article> gebruikt.
• Makkelijk aan te passen maximumbreedte gegeven.
• Bij vergroten verdwijnt de linkerkolom niet meer onder de footer. maar wordt scrollbaar.
• Linkerkant van linkerkolom staat nu precies gelijk met linkerkant van header en footer.
• Padding en dergelijke nu meer in em dan in px opgegeven, waardoor bij zoomen en dergelijke de verhoudingen beter bewaard blijven.

Bekende problemen

Internet Explorer 7, 8 en 9, Firefox en Opera

Normaal genomen kun je op een pagina heen en weer gaan met de toetscombinaties alt+→ en alt+← (of soortgelijke combinaties, afhankelijk van de gebruikte browser en dergelijke). Als je bijvoorbeeld bovenaan de pagina op een link klikt naar een plaats verderop in dezelfde pagina ('n anker), kun je normaal genomen met alt+← weer terug, naar waar je geklikt hebt.

Omdat in dit geval alleen de rechterkolom, bij genoeg inhoud, wordt gescrold, zullen dit soort ankers alleen binnen de rechterkolom voorkomen. Deze rechterkolom zit binnen <article>, en <article> zit weer binnen div#content. Omdat deze elementen beide absoluut gepositioneerd zijn, werken die toetsen hier niet.

Bij een relatieve of statische positie werken de toetsen wel, maar daarmee kun je deze lay-out weer niet maken.

Deze lay-out is dus minder geschikt voor teksten, waarbinnen je veel heen en weer moet gaan, bijvoorbeeld om voetnoten onderaan de pagina te bekijken.

In Safari en Google Chrome werken deze navigatietoetsen sinds 'n paar jaar wel op de normale manier, ook binnen div#content. Er is dus hoop dat ze ooit in alle browsers goed werken.

En om misverstanden te voorkomen: het gaat hier alleen om links binnen div#content. Links vanuit header, footer of linkerkolom naar div#content werken volledig normaal. Ook links naar en van andere pagina's werken op de normale manier, inclusief de genoemde toetscombinaties.

Overigens speelt ditzelfde probleem in de linkerkolom, maar die zal normaal genomen niet hoger zijn dan er ruimte is, en er zullen al helemaal geen ankers in voorkomen.

Firefox

Aansluitend op het hierboven staande: in Firefox kun je niet navigeren met de spatiebalk. Normaal genomen ga je met de spatiebalk één scherm omlaag, en met Shift+Spatiebalk één scherm omhoog. Maar ook dit werkt niet bij een absoluut gepositioneerd element.

Internet Explorer 7

• In Internet Explorer 7 is de zoomfunctie hopeloos slecht. Bij uitzoomen (verkleinen) vallen er op de wildste plaatsen gaten in de lay-out. Bij inzoomen (vergroten) is het nog erger: de linkerkolom komt over de footer te staan, die daarop wraak neemt door boven de rechterkolom te gaan staan. Hierdoor wordt een deel van de content verborgen en dus onleesbaar. In Internet Explorer 8 werkt de zoomfunctie wel goed.

  Als je alleen de lettergrootte verandert, gaat het wel goed.

• Er zitten kleine verschillen tussen Internet Explorer 7 en alle andere browsers in sommige marges, bijvoorbeeld boven de kopjes in linker- en rechterkolom. In het kader van het langzaam afbouwen van ondersteuning voor dit monsterlijke wanproduct laat ik dat lekker zo.
• Voor Internet Explorer 7, 8 en 9 hebben <nav> (de linkerkolom) en <article> (de rechterkolom) een tabindex nodig. Hierdoor krijg je een kadertje rondom linker- of rechterkolom, als je daarop klikt. Dit kadertje is in alle browsers weg te krijgen, maar niet in Internet Explorer 7. Althans: niet zonder JavaScript. Dus laat ik het lekker zo.

Alle browsers

Als er een verticale scrollbalk in het venster van de browser staat, kun je scrollen binnen het element waar die scrollbalk bij hoort. Vaak zal dat de hele pagina zijn. In dit voorbeeld is het de rechterkolom. (Hoewel wat hier beschreven staat ook geldt voor de footer en de linkerkolom, als daar zoveel in staat dat er een verticale scrollbalk zou verschijnen.)

Dat scrollen doen de meeste mensen met het wieltje van de muis of door in de scrollbalk te klikken of te slepen. Dit werkt allemaal zoals het normaal werk.

Scrollen kan echter ook met PgDn of Spatiebalk, PgUp of Shift+Spatiebalk, ↓ of ↑. Met de eerste twee ga je 'n scherm omlaag, met de middelste twee 'n scherm omhoog, en met de pijltjes één regel omlaag of omhoog.

Omdat de rechterkolom binnen een absoluut gepositioneerde div staat, werken deze toetsen niet gelijk. Je moet eerst even binnen div#content klikken. Mensen die deze toetsen gebruiken, zullen dit echter weten, omdat je dit heel vaak tegenkomt. Dus 'n echt groot probleem zal dit niet zijn.

Internet Explorer 7 en 8

Het lijkt niet op wat je op de site ziet. Geen achtergrondkleuren en alles is zomaar ergens neergepletterd.

Waarschijnlijk heb je dan geen JavaScript aangebracht voor deze browsers, of JavaScript staat uit. Bij JavaScript voor Internet Explorer 7 en 8 staat hier meer over.