Uitleg schaalbare inhoudsopgave met voorlooppunten

Laatst aangepast: 28 maart 2023.

Korte omschrijving

Inhoudsopgave met voorlooppunten (stippellijntjes). De voorlooppunten vullen altijd de ruimte tussen tekst en paginanummer. Als de tekst langer is dan één regel, staan voorlooppunten en paginanummer altijd op de onderste regel.

BELANGRIJK

Deze uitleg hoort bij het voorbeeld dat in de download zit. Het voorbeeld uit de download verschilt iets van het voorbeeld hier op de site. In de download ontbreekt bijvoorbeeld de navigatie voor de site. Ook in de kopregels zit vaak wat verschil. Daarnaast kunnen er nog andere (meestal kleine) verschillen zijn.

Als je deze uitleg leest naast de broncode van het voorbeeld op de site, kan het dus bijvoorbeeld zijn dat 'n <h1> uit de css bij 'n <h2> uit de html hoort. Maar het gaat niet om hele grote, fundamentele afwijkingen.

Als je dit lastig vindt, kun je bovenaan de pagina de hele handel downloaden. In de download zit 'n voorbeeld dat wel naadloos aansluit op de uitleg in de download.

Als je deze handleiding graag uitprint (zonde van het bos), gebruik dan de pdf in de download. Deze pagina is niet geoptimaliseerd voor printen, de pdf kan wel makkelijk worden geprint.

Alles op deze site kan vrij worden gebruikt, met drie beperkingen:

* Je gebruikt het materiaal op deze site volledig op eigen risico. Het kan prima zijn dat er fouten in de hier verstrekte info zitten. Voor eventuele schade die door gebruik van materiaal van deze site ontstaat, in welke vorm dan ook, zijn www.css-voorbeelden.nl en medewerkers daarvan op geen enkele manier verantwoordelijk.

* Deze uitleg wordt min of meer regelmatig bijgewerkt. Het is daarom niet toegestaan deze uitleg op welke manier dan ook te verspreiden, zonder daarbij duidelijk te vermelden dat de uitleg afkomstig is van www.css-voorbeelden.nl en dat daar altijd de nieuwste versie is te vinden. Dit is om te voorkomen dat er verouderde versies worden verspreid.

* Het kan zijn dat materiaal is gebruikt dat van anderen afkomstig is. Dat materiaal kan onder een bepaalde licentie vallen, waardoor het mogelijk niet onbeperkt gebruikt mag worden. Als dat zo is, wordt dat vermeld onder Inhoud van de download en licenties.

Een link naar www.css-voorbeelden.nl wordt trouwens altijd op prijs gesteld.

Alle code is geschreven in een afwijkende lettersoort en -kleur. De code die te maken heeft met de basis van dit voorbeeld (essentiële code), is in de hele uitleg onderstippeld blauw. Alle niet-essentiële code is bruin. (In de inhoudsopgave staat alles vanwege de leesbaarheid in een gewone letter.)

Opmerkingen

Dit is een klein deel van de inhoudsopgave uit Perl in 24 uur, 2e editie, 2002, Sams Publishing. 'n Uitstekend boek, hoewel je die 24 uur niet letterlijk moet nemen... En inmiddels zal er wel 'n nieuwere uitgave zijn, neem ik aan.

In de lay-out zijn kleine aanpassingen gemaakt zoals cursieve tekst, zodat ook dat getoond kan worden.
De inhoudsopgave is in verschillende <ol>'s gezet. Die zijn makkelijk op te maken, maar vooral omdat schermlezers van <ol> naar <ol> kunnen 'springen'. Ook staan er op verschillende plaatsen <h>'s, omdat schermlezers ook van <h> naar <h> kunnen 'springen'.

Omdat dit maar een klein stukje van een uitgebreide inhoudsopgave is, is het gebruik van die <ol>'s en <h>'s hier bepaald niet optimaal voor schermlezers. Meer daarover is te vinden bij Schermlezers.

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

Dit voorbeeld is gemaakt op een systeem met Linux (Kubuntu). Daarbij is vooral gebruik gemaakt van Visual Studio Code, GIMP en Firefox met extensies. De pdf-bestanden zijn gemaakt met LibreOffice.

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

Achterliggend idee

In de vorige versie bestond flexbox nog niet. In die versie werden min of meer vaste afstanden voor inspringingen en dergelijke gebruikt. Dat had als één van de nadelen dat, als een tekst niet op één regel paste, de voorlooppunten gewoon verdwenen. Bovendien zag het er in kleinere browservensters zoals op mobieltjes niet uit.

In deze versie is dat met behulp van flexbox opgelost.

De hele inhoud is onderverdeeld in <ol>'s. Die zijn makkelijk op te maken en makkelijk te gebruiken door schermlezers. (Dat laatste klopt hier niet helemaal, omdat wat vreemd zijn gebruikt. Meer daarover bij Schermlezers.)

Op diverse plaatsen in de inhoudsopgave zijn <h>'s aangebracht, omdat schermlezers makkelijk van <h> naar <h> kunnen springen. (Ook dit klopt hier niet helemaal, meer daarover bij Schermlezers.)

De opbouw van elke ingang in de inhoudsopgave is hetzelfde. Van elke <a> is met display: flex; een zogenaamde 'flex container' gemaakt. De directe kinderen van zo'n flex container – 'flex items' – zijn heel makkelijk op allerlei manieren te positioneren.

Die directe kinderen zijn hier twee <span>'s: een <span class="tekst"> met de tekst en een <span class="blz"> met het paginanummer.

De <span> met de tekst wordt zo breed als nodig is. Als de tekst niet op één regel past, komt die op meerdere regels te staan, waarbij tweede en latere regels iets inspringen.

De <span> met het paginanummer staat altijd helemaal links en is altijd ongeveer even breed. Als de tekst uit de eerste <span> op meerdere regels staat, staat de <span> met het paginanummer altijd op de onderste regel van de tekst. Omdat de <span> een flex item is, is dat links en onderaan zetten geen enkel probleem.

Inhoudsopgave opgemaakt maar nog zonder puntjes.

Met nog wat opmaak erbij ziet dat eruit als op de afbeelding. Tekst en paginanummers staan goed, maar de voorlooppunten missen nog. En daar gaat het juist om.

In de ontwerp-specificatie CSS Generated Content for Paged Media Module uit 2014 staat leader() als mogelijke waarde bij de eigenschap content, waarbij je een bepaald karakter kunt opgeven om te gebruiken. Waarmee het probleem van de voorlooppunten in één keer volmaakt wordt opgelost. Op één kleinigheidje na: dit staat al negen jaar te schitteren in de ontwerp-specificatie, maar nog geen enkele browser heeft het geïmplementeerd. Te vrezen valt dat Rutte nog eerder opkrast, dan dat dit bruikbaar wordt.

Je moet dit dus vooralsnog zelf oplossen. Bijvoorbeeld door relatief makkelijk iets als een derde <span> met ::before {content("........")} of zoiets maken. En dan met heel veel puntjes, zodat er altijd genoeg zijn. Alleen lezen schermlezers die puntjes voor. Bovendien is het ook dan lastig de voorlooppunten altijd de volledige ruimte op de onderste regel te laten vullen, ook bij een

In grotere browservensters, waar alles op één regel past, werkte dit uiteindelijk. Maar niet in kleinere vensters en bij een grotere letter of inzoomen. De uiteindelijke truc bleek op op css-tricks.com te staan. Inderdaad een derde <span> gebruiken, span.puntjes, maar deze bínnen de eerste <span> met tekst zetten. En verbergen voor schermlezers:

<a href="..."><span class="tekst">Perl installeren<span class="puntjes" aria-hidden="true"></span></span>

<span class="puntjes"> is een inline-element en wordt dus gewoon achter de tekst in span#tekst gezet. In de css wordt met behulp van ::after een groot aantal puntjes achter span#puntjes, en dus achter de tekst in span#tekst, neergezet. Voldoende puntjes om desnoods de ruimte tussen het scherm en de buren te vullen. Omdat de voorlooppunten gewoon achter de tekst komen te staan, staan ze altijd op de onderste regel, En omdat ze binnen flexbox item span#tekst staan, vullen ze altijd de volle breedte tussen tekst en paginanummer. Met behulp van overflow: hidden; wordt voorkomen dat de puntjes te ver doorlopen.

Schermlezers hebben niets aan de voorlooppunten, daarom worden die voor schermlezers verborgen. Maar alleen tekst gevolgd door een getal is ook niet echt duidelijk. Daarom wordt voor schermlezers met behulp van ::before het woord 'bladzijde' voor elk paginanummer ingevoegd.

Semantische elementen en WAI-ARIA

Deze twee onderwerpen zijn 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!). Enzovoort.

Door het op de goede manier gebruiken van semantische elementen, kunnen zoekmachines, schermlezers, enzovoort 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 door 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 schermlezers, 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 schermlezer 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.)

Html5 heeft een aantal nieuwe elementen, die speciaal zijn bedoeld om de opbouw van een pagina aan te geven. In dit voorbeeld worden hiervan alleen <main> en <nav> gebruikt. <main> en <nav> gedragen zich als een gewone <div>, maar dan een <div> met een semantische betekenis. Hierdoor kunnen schermlezers, zoekmachines, en dergelijke beter zien, hoe de pagina is samengesteld. De meeste schermlezers kunnen dit soort elementen ook gebruiken om snel door de pagina te navigeren.

<main>

Hierbinnen staat de belangrijkste inhoud van de pagina (in dit voorbeeld is dat de hele pagina).

<nav>:

Ook <nav> gedraagt zich als een gewone <div>, maar dan een <div> met een semantische betekenis: navigatie. Hierdoor kunnen schermlezers, zoekmachines, en dergelijke gelijk zien dat hierin links zijn ondergebracht, waarmee je naar andere pagina's en dergelijke kunt gaan.

In dit geval is het gebruik van <nav> om nog een andere reden belangrijk. Bij ol worden met list-style-type: none; de balletjes en dergelijke bij de <li>'s weggehaald. Dat is voor schermlezer VoiceOver op iOS een reden om de <ol>'s, de lijsten, volledig te negeren. Apple beschouwt dat niet als een bug, maar als een 'feature': ontwikkelaars zouden <ol>'s te vaak op een verkeerde manier gebruiken.

Door de <ol>'s binnen een <nav> te zetten, worden ze door nieuwere versies van VoiceOver weer herkend als lijsten. Op iOS 12.5.7 werkt dit nog niet, op iOS 15.7.3 (en iPadOS) wel. Op tussenliggende versies van iOS wordt alleen getest in een simulator, en daarin werkt VoiceOver niet, dus wanneer de truc met <nav> in iOS is gaan werken, is onduidelijk.

<ol> en <h>

Heel veel html-elementen hebben een semantische betekenis, ook de <ol> (ongeordende lijst) en de verschillende <h>'s (kopregels). De inhoudsopgave is opgedeeld in een aantal <ol>'s met bijbehorende <h>'s, waardoor schermlezers snel van het ene deel naar het andere deel kunnen 'springen'. Hier is dat echter op een wat onhandige manier gedaan, die 'in het echt' beter zou moeten. Meer daarover is te vinden bij Schermlezers.

Met behulp van dit soort nieuwe semantische elementen kan bijvoorbeeld een schermlezer in één keer een heel menu passeren en gelijk naar de echte inhoud gaan.

WAI-ARIA-codes

WAI-ARIA wordt vaak ingekort tot ARIA. Voluit betekent het Web Accessibility Initiative - Accessible Rich Internet Applications.

Er wordt in dit voorbeeld één WAI-ARIA-code gebruikt: aria-hidden.

aria-hidden

Met behulp van aria-hidden="true" kan een deel van de code worden verborgen voor schermlezers en dergelijke, zodat dit niet wordt voorgelezen. Op de normale weergave op het scherm heeft dit verder geen enkele invloed.

Voor de weergave van de voorlooppunten wordt een <span> gebruikt:

<span class="puntjes" aria-hidden="true">

Met behulp van ::after en content:"... (nog 324 punten) ..." vult deze <span> de ruimte tussen tekst en paginanummers op met voorlooppunten. Schermlezers lezen echter de inhoud van content voor, omdat die dat als gewone tekst zien. In twee snel geteste schermlezers bleken die dit voor te lezen als 'driehonderddertig punten'. Maar misschien zijn er ook nog wel schermlezers die enthousiast 330 keer 'puntje' roepen.

Een gebruiker van een schermlezer heeft hier natuurlijk helemaal niets aan. Daarom wordt de <span> met de puntjes voor schermlezers met aria-hidden="true" verborgen.

(Omdat schermlezers nu de tekst gelijk gevolgd door een paginanummer zouden voorlezen, wat ook niet erg duidelijk is, wordt bij .blz::before voor schermlezers het woord 'bladzijde' tussengevoegd voor het paginanummer.)

Bij 'Inleiding' staat als paginanummer het Romeinse getal voor 23: 'XXIII'. Dit wordt door schermlezers letter voor letter voorgelezen, of ze maken er iets van wat wel heel opwindend en exotisch klinkt, maar waarvan volstrekt onduidelijk is, bij welke taal dat opwindende en exotische hoort.

Karakters (zoals tekst) op websites worden tegenwoordig weergegeven met behulp van de standaard utf-8. Die standaard heeft voor elk karakter uit elke taal, elk cijfer, heel veel symbolen, runentekens, dominostenen, noem maar op, een eigen code. Waardoor deze overal ter wereld in elke browser hetzelfde worden weergegeven.

In die standaard zitten ook codes voor Romeinse cijfers. Als je die codes gebruikt voor de Romeinse cijfers, zou dat correct moeten worden voorgelezen. TalkBack echter leest ze dan gewoon helemaal niet voor. VoiceOver op iOS leest het wel voor, maar dan als iets dat klinkt als 'X X ai ai ai'. Misschien dat een oogchirurg hier wat aan heeft, maar de gemiddelde gebruiker van een schermlezer vermoedelijk niet. Andere schermlezers zijn niet geprobeerd, want dat zou mogelijk nog meer exotische opwinding opleveren.

Dit kennelijke gebrek aan ondersteuning in schermlezers wordt opgelost door het Romeinse cijfer in schermlezers te vervangen door gewone tekst:

<span class="blz" aria-hidden="true">XXIII</span><span class="romeins-23">bladzijde romeins 23</span>

Met behulp van aria-hidden="true" wordt het Romeinse getal voor schermlezers verborgen. span#romeins-23 met de tekst 'bladzijde romeins 23' wordt met behulp van css onzichtbaar buiten het scherm neergezet, zodat de lay-out niet wordt verstoord. Maar ook al zie je deze tekst niet, ze wordt toch gewoon voorgelezen door schermlezers.

De code aanpassen aan je eigen ontwerp

Als je dit voorbeeld gaat aanpassen voor je eigen site, houd het dan in eerste instantie zo eenvoudig mogelijk. Ga vooral geen details invullen.
Gebruik geen FrontPage, Publisher of Word (alle drie van Microsoft). Publisher en Word zijn niet bedoeld om websites mee te maken. FrontPage is zwaar verouderd en wordt al jaren niet meer onderhouden door Microsoft.

Ook OpenOffice en LibreOffice leveren een uiterst beroerd soort html af. Tekstverwerkers met al hun toeters en bellen zijn gewoon niet geschikt om websites mee te bouwen.

Je kunt beter 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, enzovoort te leren, omdat zelfs het allerbeste programma het nog steeds zwaar verliest van 'n op de juiste manier met de hand gemaakte pagina.
Als je in een desktopbrowser met behulp van zoomen het beeld vergroot, heeft dit hetzelfde effect, als wanneer de pagina in een kleiner browservenster wordt getoond. Je kunt hiermee dus kleinere apparaten zoals een tablet of een smartphone simuleren. Maar het blijft natuurlijk wel een simulatie: het is nooit hetzelfde als testen op een écht apparaat. Zo kun je bijvoorbeeld aanrakingen alleen echt testen op een echt touchscreen.

Inmiddels hebben veel browsers in de ontwikkelgereedschappen mogelijkheden voor het simuleren van weergave op een kleiner scherm ingebouwd. Ook dit blijft een simulatie, maar geeft vaak wel een beter beeld dan zoomen.
Als je 'n site maakt in Firefox, Opera, Safari, Google Chrome of Edge, is er 'n hele grote kans dat hij in alle browsers werkt. Ik geef de voorkeur aan Firefox, omdat het de enige grote browser is die niet bij een bedrijf hoort dat vooral op je centen of je data uit is.

Google Chrome wordt ook door veel mensen gebruikt, maar ik heb dus wat moeite met hoe Google je hele surfgedrag, je schoenmaat en de kleur van je onderbroek vastlegt. Daarom gebruik ik Google Chrome zelf alleen om in te testen.
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.

Gebruik het volledige doctype, inclusief de eventuele url, anders werkt het niet goed.
Gebruik een 'strict' doctype of (beter!) 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.

Het doctype voor html5 is uiterst simpel: <!doctype html>. Omdat het doctype voor html5 in alle browsers werkt, zelfs in de gelukkig vrijwel uitgestorven nachtmerrie Internet Explorer 6, is er geen enkele reden dit uiterst simpele doctype niet te gebruiken.
De eerste regel binnen de <head> moet de charset zijn. Dit vertelt de browser, welke tekenset er gebruikt moet worden, zodat letters met accenten en dergelijke overal goed worden weergegeven. 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. In html5 is het simpele <meta charset="utf-8"> voldoende.
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 dit voorbeeld in is getest.
Voor alle voorbeelden geldt: breng veranderingen stapsgewijs aan. Als je bijvoorbeeld foto's wilt laten weergeven, begin dan met het alleen 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. Ga daarna pas details binnen die blokken invullen. In eerste instantie gebruik je dus bijvoorbeeld 'n leeg blok op de plaats, 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. Zorg eerst dat de blokken werken, zoals je wilt. Dan zul je het daarna gelijk merken, als 'n toegevoegd detail als tekst of 'n afbeelding iets gaat verstoren. 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 enzovoort, 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 ongemerkt 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 eind (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, kan het helpen de verschillende delen een achtergrondkleur te geven. Je ziet dan goed, waar 'n deel precies staat. Een achtergrondkleur heeft - anders dan bijvoorbeeld een border - verder geen invloed op de lay-out, dus die is hier heel geschikt voor.
Als je eigenschappen verandert in de css, verander er dan maar één, hooguit twee tegelijk. Als je er zeventien tegelijk verandert, is de kans groot dat je niet meer weet, wat je hebt gedaan. En dat je 't dus niet meer terug kunt draaien.
margin, padding en border worden bij de hoogte en breedte van het element 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 bij opgeteld. Bij 'n border van 2 px rondom de linkerkolom wordt deze dus plotseling 4 px breder (2 px 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.

Css geeft de mogelijkheid om met behulp van box-sizing de padding en border bínnen de breedte en hoogte van de inhoud te zetten, als je dat handiger vindt.

Met nieuwere css-eigenschappen als grid en flexbox, die speciaal zijn gemaakt om een lay-out mee te maken, spelen dit soort problemen veel minder. In alle browsers waarop hier nog wordt getest, werken flexbox en grid prima. Maar als je oudere browsers moet ondersteunen, kan dat wel problemen opleveren en moet je ook in die oudere browsers testen.
In plaats van een absolute eenheid als px kun je ook een relatieve eenheid gebruiken, met name em en rem. Voordeel van em en rem is dat een lettergrootte, regelhoogte, en dergelijke in em en rem in alle browsers kan worden veranderd. Nadeel is dat het de lay-out sneller kan verstoren dan bijvoorbeeld px. Dit moet je gewoon van geval tot geval bekijken. Voor weergave in mobiele apparaten zijn relatieve eenheden als em en rem vrijwel altijd beter dan absolute eenheden als px.

(De minder bekende rem is ongeveer hetzelfde als de em. Alleen is de lettergrootte bij rem gebaseerd op de lettergrootte van het <html>-element, waardoor de rem overal op de pagina precies even groot is. Bij de em kan de lettergrootte worden beïnvloed door de voorouders van het element, bij de rem niet.)

Zoomen kan trouwens altijd, ongeacht welke eenheid je gebruikt.
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.

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

Valideren moet trouwens ook niet worden overdreven. Het is een hulpmiddel om echte fouten te vinden, meer niet. Het gaat erom dat je site goed werkt, niet dat je het braafste kind van de klas bent. Als de code niet valideert, maar daar is een goede reden voor, is daar niets op tegen. Zeker met nieuwere html en css wil de validator nog wel eens achterlopen, terwijl dat al prima is te gebruiken.

Op deze site is alle css en html gevalideerd. Als de code niet helemaal valide is (wat regelmatig voorkomt), staat daar onder Bekende problemen (en oplossingen) de reden van.

Je kunt je css en html valideren als 't online staat, maar ook als het nog in je computer staat.

Html kun je valideren op: validator.w3.org/nu.

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

Toegankelijkheid en zoekmachines

De tekst in dit hoofdstukje is een algemene tekst, die voor elke pagina geldt. Eventueel specifiek voor dit voorbeeld geldende problemen en eventuele aanpassingen om die problemen te voorkomen staan bij Bekende problemen (en oplossingen).

Toegankelijkheid (in het Engels 'accessibility') is belangrijk voor bijvoorbeeld blinden die een schermlezer gebruiken, of voor motorisch gehandicapte mensen die moeite hebben met het bedienen van een muis. Een spider van een zoekmachine (dat is het programmaatje dat de site indexeert voor de zoekmachine) is te vergelijken met een blinde. Als je je site goed toegankelijk maakt voor gehandicapten, is dat 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 wordt gebruikt, als afbeeldingen niet kunnen worden getoond of 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.

Als een afbeelding alleen maar voor de sier wordt gebruikt, zet je daarbij alt="", om aan te geven dat de afbeelding niet belangrijk is voor het begrijpen van de tekst of zo.
Gebruik in links een tekst die duidelijk aangeeft, waar de link naartoe gaat. Een tekst als 'pagina met externe links' is waarschijnlijk duidelijk genoeg, een tekst als alleen 'links' waarschijnlijk niet. Een duidelijke zwart-witregel is niet te geven, omdat dit ook van tekst en dergelijke in de omgeving van de link afhangt.

Schermlezers kunnen een lijst van alle links in de pagina weergeven, en een duidelijke tekst is daarbij belangrijk. Alleen 'volgende' zegt niets, als dat in 'n lijst met alleen links staat.
Accesskeys (sneltoetsen) kun je beter niet gebruiken, deze geven 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.

Op zichzelf zijn accesskeys een heel goed idee. Maar helaas zijn ze ook in html5 volstrekt onvoldoende gedefinieerd. Er is nog steeds geen standaard voor de meest gebruikelijke accesskeys, zoals Zoek of Home.

Er is nog steeds niet vastgelegd, hoe accesskeys zichtbaar gemaakt kunnen worden. Voor de makers van browsers zou dit 'n relatief kleine moeite zijn, voor de makers van 'n site is het bergen extra werk.

Hierdoor zijn accesskeys (vrijwel) niet te gebruiken. Misschien kunnen ze nog enig nut hebben op sites, die gericht zijn op 'n specifieke groep gebruikers. Maar voor algemene sites is het advies: normaal genomen niet gebruiken.
Met behulp van de Tab-toets (of op 'n soortgelijke manier) kun je in de meeste browsers door links, invoervelden, en dergelijke lopen. Elke tab brengt je één link, invoerveld, en dergelijke verder, Shift+Tab één plaats terug. Met behulp van het attribuut tabindex kun je de volgorde aangeven, waarin de Tab-toets werkt. Zonder tabindex wordt de volgorde van de html aangehouden bij gebruik van de Tab-toets, maar soms is een andere volgorde logischer.

In principe is het beter, als tabindex niet nodig is, maar gewoon de volgorde van de html wordt aangehouden. Bij verkeerd gebruik kan tabindex heel verwarrend zijn. Het is niet bedoeld om van de pagina een hindernisbaan voor kangoeroes te maken, waarop van beneden via links over rechts naar boven wordt gesprongen.
Als, zoals hierboven beschreven, een gebruiker van de Tab-toets bij een link, invoerveld, en dergelijke is aangekomen, heeft dit element 'focus'. Dit wordt aangegeven door de link, invoerveld, en dergelijke extra te markeren met een kadertje. Dat kadertje mag je alleen weghalen, als op een andere manier wordt duidelijk gemaakt, welk element focus heeft. Een gebruiker van de Tab-toets kan anders niet zien, waar zij of hij zit, en welk element gaat reageren op bijvoorbeeld een Enter.
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 schermlezers en dergelijke zo sterk verbeterd dat dit niet meer wordt aangeraden. De volgorde in de html kan tegenwoordig beter hetzelfde zijn als die op het scherm, omdat het anders juist verwarrend kan werken.
Een zogenaamde skip-link is vaak nog wel zinvol. Dat is 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 gewoon zichtbaar in speciale programma's zoals tekstbrowsers en schermlezers, want die kijken gewoon naar wat er in de broncode staat.

(Alleen in de schermlezer TalkBack op oudere versies van Android werkt zo'n buiten het scherm geplaatste link niet. TalkBack leest zo'n link wel voor, maar de link kan niet worden gevolgd, als deze buiten het scherm staat. Met ingang van versie 8.1 van Android is dit eindelijk opgelost en werkt een skip-link ook fatsoenlijk in TalkBack.)

Een skip-link staat bovenaan de pagina, nog boven menu, header, en dergelijke, en linkt naar de eigenlijke inhoud van de pagina. Hierdoor kunnen mensen met één toetsaanslag naar de eigenlijke inhoud van de pagina gaan.

Een skip-link is vooral nuttig voor gebruikers van de Tab-toets. Zodra de normaal genomen onzichtbare link door het indrukken van de Tab-toets focus krijgt, kun je hem op het scherm plaatsen, waardoor hij zichtbaar wordt. Bij een volgende tab wordt hij dan weer buiten het scherm geplaatst en is dus niet meer zichtbaar, zodat de lay-out niet wordt verstoord.

Op pagina's en in voorbeelden waar dat nuttig is, wordt op deze site een skip-link gebruikt. (Althans: nog niet in alle voorbeelden die daarvoor in aanmerking komen, zit een skip-link. Maar geleidelijk aan worden dat er steeds meer.)
Van oorsprong is 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 externe stylesheet staan of, als hij alleen voor één bepaalde pagina van toepassing is, in de <head> van die pagina.
Breng een logische structuur aan in je document. Gebruik een <h1> voor de belangrijkste kop, een <h2> voor een subkop, enzovoort. Schermlezers en dergelijke kunnen van kop naar kop 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.
<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 volstrekte ontoegankelijkheid voor schermlezers en dergelijke en als extra bonus vaak 'n lagere plaats in een zoekmachine.
Frames horen bij een volstrekt verouderde techniek, die heel veel nadelen met zich meebrengt. <iframe>'s hebben voor een deel dezelfde nadelen. Eén van die nadelen is dat de verschillende frames voor zoekmachines, schermlezers, en dergelijke als los zand aan elkaar hangen, omdat ze los van elkaar worden weergegeven. Ze staan wel naast elkaar op het scherm, maar er zit intern geen verband tussen.

Als je 'n stuk code vaker wilt gebruiken, zoals 'n menu dat op elke pagina hetzelfde is, voeg dat dan in met PHP. Dan wordt de pagina niet pas in de browser, maar al op de server samengesteld. Hierdoor zien zoekmachines, schermlezers, en dergelijke één pagina, net zoals wanneer je maar één pagina met html zou hebben geschreven.

(Je kunt ook invoegen met behulp van SSI. Maar tegenwoordig kun je beter PHP dan SSI gebruiken, omdat SSI min of meer aan het uitsterven is en PHP veel meer mogelijkheden heeft. Op deze site wordt in enkele voorbeelden nog SSI gebruikt, maar zodra die worden bijgewerkt, gaat dat vervangen worden door PHP.)
Geef de taal van het document aan, en bij woorden en dergelijke die afwijken van die taal de afwijkende taal met behulp van lang="...". Op deze site gebeurt dat maar af en toe, omdat de tekst (en vooral de code) een mengsel is van Engels, Nederlands en eigengemaakte namen. Dat soort teksten is gewoon niet goed in te delen in een taal. Maar bij enigszins 'normale' teksten hoor je een taalwisseling aan te geven.

Op deze site wordt de lijst op woordenlijst.org gebruikt om te bepalen, of een woord inmiddels 'Nederlands' is. Als het woord in deze lijst voorkomt, wordt geen lang-attribuut gebruikt, ook niet als het woord oorspronkelijk uit een andere taal komt.
Gebruik de tag <abbr> bij afkortingen. Doe dat de eerste keer op een pagina samen met de title-eigenschap: <abbr title="ten opzichte van">t.o.v.</abbr>. Daarna kun je op dezelfde pagina volstaan met <abbr>t.o.v.</abbr>. Doe je dit niet, dan is er 'n grote kans dat 'n schermlezer 't.o.v.' uit gaat spreken als 'tof', en 'n zoekmachine kan er ook geen chocola van maken.
Geef een verandering niet alleen door kleur aan. Een grote groep mensen heeft moeite met het onderscheiden van kleuren en/of het herkennen van kleuren. Verander bijvoorbeeld een ronde rode knop niet in een ronde groene knop, maar in een vierkante groene knop. Door ook de vorm te veranderen, is het herkennen van de verandering niet alleen van een kleur afhankelijk.
Zorg voor voldoende contrast tussen achtergrond- en voorgrondkleur, tussen background-color en color. Soms zie je heel lichtgrijze tekst op een donkergrijze achtergrond, en dan ook nog in een mini-formaat. Dat is dus voor heel veel mensen stomweg volledig onleesbaar. Op de pagina met links staat onder het kopje Toegankelijkheid → Contrast en kleurenblindheid een hele serie sites, waar je kunt controleren of het contrast groot genoeg is.
De spider van 'n zoekmachine, schermlezers, 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.

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 invisible-island.net/lynx.

Ook kun je in Windows het gratis programma WebbIE installeren. WebbIE laat de pagina zien, zoals een tekstbrowser en dergelijke hem ziet. WebbIE is te downloaden vanaf www.webbie.org.uk.

Ten slotte kun je je pagina nog online op toegankelijkheid laten controleren op 'n behoorlijk aantal sites, zoals:

lowvision.support: laat zien hoe een kleurenblinde de site ziet. Engelstalig.

wave.webaim.org: deze laat grafisch zien, hoe de toegankelijkheid is. Engelstalig. Deze tester is ook als extensie in Firefox en Google Chrome te installeren.

Op de pagina met links kun je onder Toegankelijkheid links naar meer tests en dergelijke vinden.

Getest in

Laatst gecontroleerd op 28 maart 2023.

Onder dit kopje staat alleen maar, hoe en waarin is getest. Alle eventuele problemen, ook die met betrekking tot zoomen, lettergroottes, toegankelijkheid, uit staan van JavaScript en/of css, enzovoort staan iets hieronder bij Bekende problemen (en oplossingen). Het is belangrijk dat deel te lezen, want uit een test kan ook prima blijken dat iets totaal niet werkt!

Dit voorbeeld is getest op de volgende systemen:

Desktopcomputers

Linux (Kubuntu 20.04 LTS, 'Focal Fossa') (2560 x 1080 px, resolution: 96 ppi):
Firefox, Google Chrome en Vivaldi, in grotere en kleinere browservensters.
In Vivaldi is ook ruimtelijke navigatie ('Spatial Navigation') getest.

Laptops

Windows 10 (1600 x 900 px, resolution: 106 ppi):
Firefox, Google Chrome en Edge, in grotere en kleinere browservensters.

OS X 11.7.4 ('Big Sur') (1440 x 900 px, resolution: 96 ppi, device-pixel-ratio: 1):
Firefox, Safari, Google Chrome en Microsoft Edge, in grotere en kleinere browservensters.

Tablets

iPad met iOS 12.5.7 (2048 x 1536 px, device-pixel-ratio: 2:
Safari, Chrome, Firefox en Microsoft Edge (alle portret en landschap).

iPad met iOS 13.3 (gesimuleerd in Xcode):
Safari (portret en landschap).

iPad met iPadOS 16.4 (2160 x 1620 px, 264 ppi):
Safari, Chrome, Firefox en Microsoft Edge (alle portret en landschap).

Android 6.0 ('Marshmallow') (1920 x 1200 px, resolution: 224 ppi):
Samsung Internet, Firefox en Chrome (alle portret en landschap).

Android 8.1 ('Oreo') (1920 x 1200 px, resolution: 218 ppi):
Samsung Internet, Firefox, Microsoft Edge en Chrome (alle portret en landschap).

Android 13 (2000 x 1200 px, resolution: 225 ppi):
Samsung Internet, Firefox, Microsoft Edge en Chrome (alle portret en landschap).

Smartphones

iPhone 7 met iOS 12.4 (gesimuleerd in Xcode):
Safari (portret en landschap).

iPhone 8 met iOS 13.3 (gesimuleerd in Xcode):
Safari (portret en landschap).

iPhone met iOS 15.7.4 (1334 x 750 px, 326 ppi):
Safari, Chrome, Firefox en Microsoft Edge (alle portret en landschap).

Android 7.0 ('Nougat') (1280 x 720 px, resolution: 294 ppi):
Samsung Internet, Firefox, Microsoft Edge en Chrome (alle portret en landschap).

Android 9.0 ('Pie') (1920 x 1080 px, resolution: 424 ppi):
Samsung Internet, Firefox, Microsoft Edge en Chrome (alle portret en landschap).

Android 13 ('Tiramisu') (2408 x 1080 px, resolution: 401 ppi):
Samsung Internet, Firefox, Microsoft Edge en Chrome (alle portret en landschap).

Er is op de aan het begin van dit hoofdstukje genoemde controledatum getest in de meest recente versie van de browser, die op het betreffende besturingssysteem kon draaien. Het aantal geteste browsers en systemen is al tamelijk fors, en als ook nog rekening gehouden moet worden met (zwaar) verouderde browsers, is het gewoon niet meer te doen. Surfen met een verouderde browser is trouwens vragen om ellende, want updates van browsers hebben heel vaak met beveiligingsproblemen te maken.

In- en uitzoomen en - voor zover de browser dat kan - een kleinere en grotere letter zijn ook getest. Er is ingezoomd en vergroot tot zover de browser kan, maar niet verder dan 200%.

Er is getest met behulp van muis en toetsenbord, behalve op iOS, iPadOs en Android, waar een touchscreen is gebruikt. Op Windows 10 is getest met touchscreen, touchpad, toetsenbord, muis, en - waar dat zinvol was - op een combinatie daarvan. Op OS X 11.7.4 is getest met (een combinatie van) toetsenbord, touchpad en muis.

Als in een voorbeeld JavaScript is gebruikt, is ook getest of het werkt zonder JavaScript. Dat is alleen gedaan in de browsers, waarin in de instellingen JavaScript kan worden uitgeschakeld.

Ook is getest zonder css en - als afbeeldingen worden gebruikt - zonder afbeeldingen.

Schermlezers en dergelijke

Naast deze 'gewone' browsers is ook getest in Lynx, WebbIE, NVDA, TalkBack, VoiceOver en Verteller.

Lynx is een browser die alleen tekst laat zien en geen css gebruikt. Er is getest op Linux.

WebbIE. is een browser die gericht is op mensen met een handicap. Er is getest op Windows 10.

NVDA is een schermlezer, zoals die door blinden wordt gebruikt. Er is getest op Windows 10 in combinatie met Firefox.

TalkBack is een in Android ingebouwde schermlezer. Er is getest in combinatie met Chrome op Android 6.0, 7.0, 8.1, 9 en 13

VoiceOver is een in iOS en OS X ingebouwde schermlezer. Er is getest in combinatie met Safari op iOS 12.5.7 en 15.7.4, iPadOS 16.4 en OS X 11.7.4.

Verteller (Narrator) is een in Windows 10 ingebouwde schermlezer. Er is getest in combinatie met Edge.

(Voor de bovenstaande programma's zijn links naar sites met uitleg en dergelijke te vinden op de pagina met links onder Toegankelijkheid → Schermlezers, tekstbrowsers, en dergelijke.)

Als het voorbeeld in deze 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 problemen in schermlezers (en eventuele aanpassingen om die te voorkomen) staan iets hieronder bij Bekende problemen (en oplossingen).

Alleen op de hierboven genoemde systemen en browsers is getest. Er is dus niet getest op bijvoorbeeld 'n Blackberry. Er is een kans dat dit voorbeeld niet (volledig) werkt op niet-geteste systemen en apparaten. Om het wel (volledig) werkend te krijgen, zul je soms (kleine) wijzigingen en/of (kleine) aanvullingen moeten aanbrengen, bijvoorbeeld met JavaScript.

Er is ook geen enkele garantie dat iets werkt in een andere tablet of smartphone dan hierboven genoemd, omdat fabrikanten in principe de software kunnen veranderen. Dit is anders dan op de desktop, waar browsers altijd (vrijwel) hetzelfde werken, zelfs op verschillende besturingssystemen. Iets wat in Samsung Internet op Android werkt, zal in de regel overal werken in die browser, maar een garantie is er niet. De enige garantie is het daadwerkelijk testen op een fysiek apparaat. En aangezien er duizenden mobiele apparaten zijn, is daar geen beginnen aan.

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

Nieuwe browsers worden pas getest, als ze uit het bèta-stadium zijn. Anders is er 'n redelijke kans dat je tegen 'n bug zit te vechten, 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 kunnen niet worden beantwoord, en het melden van fouten in niet-geteste browsers heeft ook geen enkel nut. (Melden van fouten, problemen, enzovoort in wel geteste browsers: graag! Dat kan op het forum.)

Bekende problemen (en oplossingen)

Waarop en hoe is getest, kun je gelijk hierboven vinden bij Getest in.

Als je hieronder geen oplossing vindt voor een probleem dat met dit voorbeeld te maken heeft, kun je op het forum proberen een oplossing te vinden voor je probleem. Om forumspam te voorkomen, moet je je helaas wel registreren, voordat je op het forum een probleem kunt aankaarten.

Bij toegankelijkheid is er vaak geen goed onderscheid te maken tussen oplossing en probleem. Zonder (heel simpele) aanpassingen heb je vaak 'n probleem, en omgekeerd. Daarom staan wat betreft toegankelijkheid aanpassingen en problemen hier bij elkaar in dit hoofdstukje.

Voor zover van toepassing wordt eerst het ontbreken van JavaScript, css en/of afbeeldingen besproken. Vervolgens problemen en aanpassingen met betrekking tot toegankelijkheid voor specifieke groepen bezoekers, zoals zoomen en andere lettergrootte, Tab-toets, tekstbrowsers en schermlezers. Als laatste volgen de overige problemen in één of meer specifieke browsers.

Als in een onderdeel geen problemen aanwezig zijn, staat in een smal groen kadertje 'Geen problemen'. Bij een onderwerp over toegankelijkheid zijn er soms geen problemen, maar alleen aanpassingen. Ook in dat geval staat bovenaan in een smal groen kadertje 'Geen problemen'. Daaronder staan dan de aanpassingen.

Als in een onderdeel één of meer problemen worden besproken, staat van elk probleem in een breed rood kadertje een korte samenvatting daarvan.

Als bij het probleem een oplossing wordt gegeven, staat de samenvatting in een rode stippellijn. Bij een onderwerp over toegankelijkheid zijn er soms, naast de opgeloste problemen, ook aanpassingen. In dat geval staan staan die aanpassingen boven de kadertjes met opgeloste problemen.

Als bij het probleem geen oplossing is gevonden, staat de samenvatting in een rode ononderbroken lijn. Bij een onderwerp over toegankelijkheid zijn er soms, naast de problemen, ook aanpassingen. In dat geval staan staan die aanpassingen boven de kadertjes met problemen.

Zonder JavaScript

Geen problemen.

Omdat JavaScript niet wordt gebruikt, maakt het niets uit of JavaScript aan- of uitstaat.

Zonder css

Probleem: zonder css vallen voorlooppunten en (voor schermlezers) het woord 'bladzijde' weg.

De indeling van de pagina blijft grotendeels hetzelfde, omdat <h>'s en <ol>'s zonder css gewoon op de standaardmanier worden weergegeven.

De voorlooppunten worden met behulp van css neergezet. Dat geldt ook voor het woordje 'bladzijde', dat (in plaats van de voorlooppunten) voor schermlezers voor het paginanummer wordt tussengevoegd.

In principe werkt alles nog gewoon, alleen komen de paginanummers nu direct tegen de tekst aan te staan. De eerste ingang zou dan 'Inleiding23' worden, als één woord. Dat is onduidelijk en voor schermlezers wordt dit een tongbreker. (Aan denken: patent aanvragen voor een schermlezer met een tong.) Om dit te voorkomen is voor elk paginanummer een spatie gezet. De eerste ingang wordt dan 'Inleiding 23', wat prima uit te spreken is.

Het is nog steeds wat onduidelijk misschien, maar dat geldt voor schermlezers én voor wat op het scherm staat. Overigens zullen mensen die css uit hebben staan tegen nog wel grotere problemen aanlopen.

Tekstbrowsers

Geen problemen.

Lynx en WebbIE geven de inhoud beide volledig weer. Bij beide worden de voorlooppunten en het voor schermlezers ingevoegde 'bladzijde' niet getoond.

Schermlezers

Probleem: het gebruik van <ol>'s en <h>'s is wat onhandig.

Dit voorbeeld is min of meer een imitatie van een klein deel van een inhoudsopgave. Daardoor is het grootste deel van die inhoudsopgave weggevallen.

Links binnen een of meerdere <ol>'s of <ol>'s zetten is handig voor de lay-out, omdat ze dan makkelijk zijn op te maken. Bovendien kunnen schermlezers van lijst naar lijst 'springen', waardoor ze makkelijk door de inhoud kunnen lopen en bijvoorbeeld snel naar het vijfde hoofdstuk kunnen gaan.

Deze inhoudsopgave is overgenomen van een boek, en ook nog 'ns slechts gedeeltelijk. Omdat de inhoudsopgave een kopie moest worden van de inhoudsopgave in dat boek, is de indeling in <ol>'s niet bepaald optimaal voor schermlezers. Als je een inhoudsopgave voor een site zou maken, zou je de indeling kunnen optimaliseren. Hier gaat het echter vooral om de voorlooppunten, dus dat die indeling hier niet optimaal is, wordt voor lief genomen.

Voor de <h>'s geldt min of meer hetzelfde. Als boven elk deel van een pagina een <h> staat, kunnen schermlezers van <h> naar <h> 'springen' en zo een overzicht van de indeling van de pagina krijgen. In een inhoudsopgave met meerdere <ol>'s of <ul>'s kan dat net zo werken, als boven elke <ol> of <ul> een <h> staat.

Die <h>'s boven de <ol> staan hier, maar er staan nog veel meer <h>'s. Binnen bijvoorbeeld 'Uur 1' zit weer een aantal hoofdstukjes. Die hebben niet allemaal een eigen <ol> gekregen, want dat zou een oerwoud aan <ol>'s opleveren. Maar als je alleen <h>'s boven een <ol> zou gebruiken, zouden die hoofdstukjes worden gemist, als een schermlezer van <h> naar <h> springt. Daarom hebben ook die hoofdstukjes een <h> gekregen. Normaal genomen zou je dat niet doen, omdat er dan veel te veel <h>'s zijn.

Verder zijn er nog wat 'loslopende' ingangen die een <h> hebben gekregen, omdat ook die anders zouden worden gemist, als van <h> naar <h> wordt gesprongen.

n een inhoudsopgave voor een site zou je dit op een betere manier kunnen oplossen. Hier is dat niet aangepast, omdat de indeling van het voorbeeld uit het boek is aangehouden.

Probleem: het is voor schermlezers onduidelijk, waar de pagina over gaat.

De pagina heeft een titel en een beschrijving, maar afhankelijk van de instellingen leest niet elke schermlezer dat voor. Bovendien springen veel gebruikers van een schermlezers van <h> naar <h>, om op die manier snel een overzicht van de pagina te krijgen. Hierdoor zouden ze het begin van de inhoudsopgave missen.

Om beide problemen op te lossen, staat aan het begin van de pagina een <h1> met een omschrijving van de inhoudsopgave. Deze <h1> is onzichtbaar buiten het venster geparkeerd, omdat hij allen voor schermlezers is bedoeld. Ook al zie je de <h1> niet, deze wordt gewoon voorgelezen.

Probleem: schermlezers lezen de voorlooppunten voor als iets als 'driehonderddertig punten'.

En dat bij élke ingang. Daarom worden de voorlooppunten voor schermlezers vervangen door het woord 'bladzijde'. Hoe dit precies gebeurt is te vinden bij WAI-ARIA-codes.

Probleem: het Romeinse getal 'XXIII' wordt door schermlezers verhaspeld.

Bij 'Inleiding' staat als paginanummer het Romeinse getal voor 23: 'XXIII'. Hierover struikelen schermlezers, daarom wordt dit voor schermlezers vervangen door 'bladzijde romeins 23'. Hoe dit precies gebeurt, is te vinden bij WAI-ARIA-codes.

Probleem: in oudere versies van VoiceOver worden de <ol>'s niet als lijst herkend.

Bij ol worden met list-style-type: none; de bolletjes en dergelijke bij de <li>'s verwijderd. Hierdoor herkent VoiceOver de <ol>'s niet meer als een lijst. In nieuwere versies worden ze wel weer herkend, als de <ol>'s binnen een <nav> staan. Meer hierover bij <nav>.

Zoomen en andere lettergrootte

Geen problemen.

Als de tekst te lang wordt voor één regel, komen voorlooppunten en paginanummer altijd op de onderste regel te staan.

Wijzigingen

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

25 mei 2009:

Nieuw opgenomen.

30 januari 2011:

Op diverse plaatsen color: black; opgenomen vanwege de toegankelijkheid. De reden waarom en zo staat op de betreffende plaatsen.

9 januari 2012:

Bij Bekende problemen stukje over zoomen toegevoegd onder Alle browsers behalve Internet Explorer 7.

28 maart 2023:

Er zijn eigenlijk te veel wijzigingen om ze allemaal op te noemen. De volledige code is herschreven. Daarom worden hier niet alle wijzigingen in de code gemeld, zoals eerder wel gebeurde. Alleen de grote lijnen worden weergegeven.

Alles voor Internet Explorer verwijderd.
xhtml omgezet naar html.
Selectors zijn zoveel mogelijk ingekort.
Elke ingang stond in een eigen <p>. Dit is vervangen door een indeling in <ol>'s met bijbehorende <h>'s.
Het uitlijnen van tekst, voorlooppunten en paginanummers gebeurt nu met behulp van flexbox. Daardoor blijven de voorlooppunten nu altijd zichtbaar, ook als de tekst te lang is voor één regel.
Door de andere lay-out kan de inhoud nu een witte achtergrond en een border krijgen.
Elke ingang is in een link gezet. Achter de links zit een klein aantal hulppagina's.
Afstand tussen ingangen vergroot, waardoor de links ook met vingers zijn aan te raken (een vinger is wat minder precies dan een muis).
Nieuw hoofdstuk over Semantische elementen en WAI-ARIA.
Aantal aanpassingen voor schermlezers toegevoegd.
Tig kleinere wijzigingen.

Inhoud van de download en licenties

De inhoud van deze download kan vrij worden gebruikt, met drie beperkingen:

* Sommige onderdelen die van 'n andere site of zo afkomstig zijn, vallen mogelijk onder een of andere licentie. Dat is hieronder bij het betreffende onderdeel te vinden.

* Je gebruikt het materiaal uit deze download volledig op eigen risico. Het kan prima zijn dat er fouten in de hier verstrekte code en dergelijke zitten. Voor eventuele schade die door gebruik van materiaal uit deze download ontstaat, in welke vorm dan ook, zijn www.css-voorbeelden.nl en medewerkers daarvan op geen enkele manier verantwoordelijk.

* Dit voorbeeld (en de bijbehorende uitleg en dergelijke) wordt min of meer regelmatig bijgewerkt. Het is daarom niet toegestaan dit voorbeeld (en de bijbehorende uitleg en dergelijke) op welke manier dan ook te verspreiden, zonder daarbij duidelijk te vermelden dat voorbeeld, uitleg, en dergelijke afkomstig zijn van www.css-voorbeelden.nl en dat daar altijd de nieuwste versie is te vinden. Dit is om te voorkomen dat er verouderde versies worden verspreid.

Een link naar www.css-voorbeelden.nl wordt trouwens altijd op prijs gesteld.

tekst-062-dl.html: de pagina met het voorbeeld.

tekst-062.pdf: deze uitleg (aangepast aan de inhoud van de download).

tekst-062-inhoud-download-en-licenties.txt: een kopie van de tekst onder dit kopje (Inhoud van de download en licenties).

062-css-dl:

tekst-062-dl.css: stylesheet voor tekst-062-dl.html.

tekst-062-hulp-dl.css: stylesheet voor de hulppagina's achter de links.

062 files-dl:

de vijf hulppagina's achter de links.

HTML

De code is geschreven in een afwijkende lettersoort. De code die te maken heeft met de basis van dit voorbeeld (essentiële code), is in de hele uitleg onderstippeld blauw. Alle niet-essentiële code is bruin. (In de inhoudsopgave staat alles in een gewone letter vanwege de leesbaarheid.)

In de html hieronder wordt alleen de html besproken, waarover iets meer is te vertellen. Een <h1> bijvoorbeeld wordt in de regel niet genoemd, omdat daarover weinig interessants valt te melden. (Als bijvoorbeeld het uiterlijk van de <h1> wordt aangepast met behulp van css, staat dat verderop bij de bespreking van de css.)

Zaken als een doctype en charset hebben soms wat voor veel mensen onbekende effecten, dus daarover wordt hieronder wel een en ander geschreven.

Omdat de html voor de hulppagina's achter de links heel simpel is, wordt die hier niet besproken.

<!doctype html>

Een document moet met een doctype beginnen om weergaveverschillen tussen browsers te voorkomen. Zonder doctype is de kans op verschillende (en soms volkomen verkeerde) weergave tussen verschillende browsers heel erg groot.

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

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

Het hier gebruikte doctype is dat van html5. Dit kan zonder enig probleem worden gebruikt: het werkt zelfs in Internet Explorer 6.

<html lang="nl">

Het attribuut lang="nl" bij <html> geeft aan dat de pagina in het Nederlands is. De taal is van belang voor schermlezers, automatisch afbreken, automatisch genereren van aanhalingstekens, juist gebruik van decimale punt of komma, en dergelijke.

<meta charset="utf-8">

Zorgt dat de browser letters met accenten en dergelijke goed kan weergeven.

utf-8 is de beste charset (tekenset), omdat deze alle talen van de wereld (en nog heel veel andere extra tekens) bestrijkt, maar toch niet meer ruimte inneemt voor de code, dan nodig is. Als je utf-8 gebruikt, hoef je veel minder entiteiten (ä en dergelijke) te gebruiken, maar kun je bijvoorbeeld gewoon ä gebruiken.

Deze regel moet zo hoog mogelijk komen te staan, als eerste regel binnen de <head>, omdat hij anders door sommige browsers niet wordt gelezen.

In html5 hoeft deze regel niet langer te zijn, dan wat hier staat.

<meta name="viewport" content="width=device-width, initial-scale=1">

Mobiele apparaten variëren enorm in grootte. En dat is een probleem. Sites waren, in ieder geval tot enkele jaren geleden, gemaakt voor desktopbrowsers. En die hebben, in vergelijking met bijvoorbeeld een smartphone, heel brede browservensters. Hoe moet je op 'n smartphone een pagina weergeven, die is gemaakt voor de breedte van een desktop? Je kunt natuurlijk wachten tot álle sites zijn omgebouwd voor smartphones, tablets, enzovoort, maar dan moet je waarschijnlijk heel erg lang wachten.

Mobiele browsers gokken erop dat een pagina een bepaalde breedte heeft. Safari voor mobiel bijvoorbeeld gaat ervan uit dat een pagina 980 px breed is. De pagina wordt vervolgens zoveel versmald dat hij binnen het venster van het apparaat past. Op een iPhone wordt de pagina dus veel smaller dan op een iPad. Vervolgens kan de gebruiker inzoomen op het deel van de pagina dat deze wil zien.

Dit betekent ook dat bij het openen van de pagina de tekst meestal heel erg klein wordt weergegeven. (Meestal, want niet alle browsers en apparaten doen het op dezelfde manier.) Niet erg fraai, maar bedenk maar 'ns 'n betere oplossing voor bestaande sites.

Nieuwe sites of pagina's kunnen echter wel rekening houden met de veel kleinere vensters van mobiele apparaten. In dit voorbeeld bijvoorbeeld wordt de breedte van de inhoudsopgave aan de breedte van het venster aangepast.

Maar die stomme mobiele browser weet dat niet, dus die gaat ervan uit dat ook deze pagina 980 px breed is, en verkleint die dan. Dat is ongeveer even behulpzaam als de gedienstige kelner die behulpzaam de stoel naar achteren trekt, net als jij wilt gaan zitten.

Om de door de browser aangeboden hulp vriendelijk maar beslist te weigeren, wordt deze tag gebruikt. Hiermee geef je aan dat de pagina is geoptimaliseerd voor mobiele apparaten.

De kreet width=device-width zegt tegen de mobiele browser dat de breedte van de weer te geven pagina gelijk is aan de breedte van het apparaat. Als een iPad in portretstand bijvoorbeeld 768 px breed is, wordt de pagina ook 768 px breed.

Er staat nog een tweede deel in de tag: initial-scale=1. Sommige mobiele apparaten zoomen een pagina gelijk in of uit. Ook weer in een poging behulpzaam te zijn. Ook dat is hier niet nodig. Er is ook een instructie om zoomen helemaal onmogelijk te maken, maar die wordt niet gebruikt. De bezoeker kan zelf nog gewoon zoomen, wat belangrijk is voor mensen die wat slechter zien.

<link rel="stylesheet" href="062-css-dl/tekst-062-dl.css">

Dit is een koppeling naar een externe stylesheet (stijlbestand), waarin de css staat. In html5 is de toevoeging type="text/css" niet meer nodig, omdat dit standaard al zo staat ingesteld. Je moet uiteraard de naam van en het pad naar de stylesheet aanpassen aan de naam en plaats, waar je eigen stylesheet staat.

Voordeel van een externe stylesheet is onder andere dat deze geldig is voor alle pagina's, waaraan deze is gelinkt. 'n Verandering in de lay-out hoef je dan maar in één enkele stylesheet aan te brengen, in plaats van in elke pagina apart. Op een grotere site kan dit ontzettend veel werk schelen. Bovendien hoeft de browser zo'n externe stylesheet maar één keer te downloaden, ongeacht hoeveel pagina's er gebruik van maken. Zou je de css in elke pagina opnieuw aanbrengen, dan worden de te downloaden bestanden veel groter.

In dit voorbeeld heeft een extern stylesheet eigenlijk geen nut, omdat er maar één pagina is die dit stylesheet gebruikt. In dit geval kun je de css beter in de <head> van de html-pagina zelf zetten. Voor de omvang maakt het hier niets uit, want de css wordt hoe dan ook altijd precies één keer gedownload, en nooit vaker. Voor het onderhoud maakt het ook geen verschil, want ook hier hoef je de css maar op één plaats te wijzigen. Maar het scheelt wel een extra aanroep naar de server, omdat geen apart stylesheet hoeft te worden gedownload.

Dat opnemen in de <head> gaat heel simpel: je kopieert gewoon het hele stylesheet en zet die bovenin de <head>, tussen <style> en </style>:

<style> body {color: black;} (...) rest van de css (...) div {color: red;} </style>

Maar zodra een stylesheet op meerdere pagina's wordt gebruikt, wat meestal het geval zal zijn, is een extern stylesheet beter.

(De reden dat er toch een extern stylesheet is, terwijl hierboven omstandig wordt beweerd dat dat in dit voorbeeld eigenlijk geen nut heeft: overzichtelijkheid. Nu kun je html en css los van elkaar bekijken.)

De hulppagina's achter de knoppen hebben een gezamenlijke stylesheet: tekst-062-hulp-dl.css. Deze wordt hier verder niet besproken, omdat hij uiterst simpel is. Op de site is deze met de stylesheet voor het voorbeeld zelf (en nog andere pagina's) gecombineerd tot één gezamenlijke stylesheet.

<h1>Inhoudsopgave Perl in 24 uur, 2e editie, 2002, Sams <span lang="en">Publishing</span></h1>

Deze kopregel is bedoeld voor schermlezers. Afhankelijk van de instellingen leest niet elke schermlezer de beschrijving of titel van de pagina voor. In dat geval is niet duidelijk, waar de pagina over gaat.

Schermlezers kunnen van <h> naar <h> 'springen' om snel een overzicht van de pagina te krijgen. Daardoor zouden ze het begin van de inhoudsopgave missen.

Beide dingen worden opgelost door links buiten het venster een <h1> neer te zetten. Hoewel deze <h1> niet is te zien, wordt deze gewoon voorgelezen door schermlezers.

<p id="inleiding"><a href="062-files-dl/tekst-062-inleiding-dl.html"><span class="tekst">Inleiding<span class="puntjes" aria-hidden="true"></span></span><span class="blz" aria-hidden="true"> XXIII</span><span class="romeins-23">bladzijde romeins 23</span></a></p>

De opbouw van alle ingangen in de inhoudsopgave is in grote lijnen hetzelfde, alleen staan alle andere ingangen niet in een <p>, maar in een <li>. Verder is daar geen <span class="romeins-23"> aanwezig, maar soms wel een extra <h2>, <h3> of <h4>.

span.puntjes zorgt voor de stippellijnen. Omdat een schermlezer daar niets aan heeft, wordt die <span> verborgen met aria-hidden="true". Meer over aria-hidden is te vinden bij WAI-ARIA-codes.

De spatie voor het paginanummer (hier 'XXIII') is bedoeld voor het geval css uitstaat of niet goed wordt gedownload of zo. In dat geval staat er in ieder geval nog een spatie tussen tekst en paginanummer.

Omdat 'XXIII' voor schermlezers onduidelijk is, wordt span.blz met het paginanummer met aria-hidden="true" voor schermlezers verborgen en met behulp van span.romeins-23 vervangen door 'bladzijde romeins 23'. Meer hierover is te vinden bij WAI-ARIA-codes.

In andere ingangen staan geen Romeinse cijfers, daar wordt span.blz niet verborgen, maar juist gebruikt om voor schermlezers met behulp van ::before bij .blz::before het woord 'bladzijde' in te voegen voor het paginanummer.

<abbr lang="en" title="Common Gateway Interface">CGI</abbr>

Op een aantal plaatsen staat in de inhoudsopgave een afkorting. De eerste keer dat een afkorting wordt gebruikt, wordt de afkorting voluit in het title-attribuut geschreven. Omdat het in dit geval om een Engelstalige afkorting staat, wordt dit met lang="en" aangegeven, zodat schermlezers het op de juiste manier uit kunnen spreken.

CSS

De code is geschreven in een afwijkende lettersoort. De code die te maken heeft met de basis van dit voorbeeld (essentiële code) is in de hele uitleg onderstippeld blauw. Alle niet-essentiële code is bruin. (In de inhoudsopgave staat alles in een gewone letter vanwege de leesbaarheid.)

De css voor de hulppagina's achter de links is heel simpel, daarom wordt die hier niet besproken.

Technisch gezien is er geen enkel bezwaar om de css in de stylesheet allemaal achter elkaar op één regel te zetten:

div#header-buiten {position: absolute; right: 16px; width: 100%; height: 120px; background: yellow;} div p {margin-left 16px; height: 120px; text-align: center;}

Maar als je dat doet, garandeer ik je hele grote problemen, omdat het volstrekt onoverzichtelijk is. Beter is het om de css netjes in te laten springen:

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

        div p {
            margin-left: 16px;
            height: 120px;
            text-align: center;
        }

Hiernaast is het heel belangrijk voldoende commentaar (uitleg) in de stylesheet te schrijven. Op dit moment weet je waarschijnlijk (hopelijk...), waarom je iets doet. Maar over vijf jaar kan dat volstrekt onduidelijk zijn. Op deze site vind je nauwelijks commentaar in de stylesheets, maar dat heeft een simpele reden: deze uitleg is in feite één groot commentaar.

Op internet zelf is het goed, als de stylesheet juist zo klein mogelijk is. Dus voor het uploaden kun je normaal genomen het beste het commentaar weer verwijderen. Veel mensen halen zelfs alles wat overbodig is weg, voordat ze de stylesheet uploaden. Inspringingen bijvoorbeeld zijn voor mensen handig, een computer heeft ze niet nodig.

Je hebt dan eigenlijk twee stylesheets. De uitgebreide versie waarin je dingen uitprobeert, verandert, enzovoort, met commentaar, inspringingen, en dergelijke. Dat is de mensvriendelijke versie. Daarnaast is er dan een stylesheet die je op de echte site gebruikt: een gecomprimeerde versie.

Dat comprimeren kun je met de hand doen, maar er bestaan ook hulpmiddelen voor. Op de pagina met links kun je onder het kopje Gereedschap → Snelheid, testen, gzip, comprimeren (inclusief theorie) links naar sites vinden, waar je bestanden kunt comprimeren.

(Stylesheets op deze site zijn niet gecomprimeerd. Omdat het vaak juist om de css gaat, kunnen mensen dan zonder al te veel moeite de css bekijken.)

css voor alle vensters

/* tekst-062-dl.css */

Om vergissingen te voorkomen is het een goede gewoonte bovenaan het stijlbestand even de naam neer te zetten. Voor je het weet, zit je anders in het verkeerde bestand te werken.

body

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

background: #ff9;

Achtergrondkleurtje.

color: black;

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

Hoewel dit de standaardkleur is, wordt deze toch specifiek opgegeven. Hierboven is een achtergrondkleur opgegeven. Sommige mensen hebben zelf de voorgrond‑ en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als nu de achtergrondkleur wordt veranderd, maar niet de voorgrondkleur, loop je het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

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

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

Als Arial is geïnstalleerd op de machine van de bezoeker, wordt deze gebruikt, anders Helvetica. Als die ook niet wordt gevonden, wordt in ieder geval een schreefloze letter (zonder dwarsstreepjes) gebruikt.

margin: 0;

Slim om te doen vanwege verschillen tussen browsers.

main

Alle <main>'s. Dat is er maar één: de belangrijkste inhoud van de pagina staat erin. Hier is dat de hele pagina.

background: white;

Witte achtergrond.

color: black;

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

Dit is ook al bij <body> opgegeven, maar sommige mensen hebben bij álle elementen de kleuren veranderd. Het heeft immers weinig zin, als ze dat alleen bij de body doen, terwijl de sitebouwer de kleuren ook bij bijvoorbeeld de paragrafen heeft aangepast.

width: 660px;

Breedte.

max-width: 90vw;

Hier gelijk boven is een breedte van 660 px opgegeven. Als het browservenster smaller is dan 660 px, zou hierdoor horizontaal gescrold moeten worden om alles te zien. Om dit te voorkomen wordt hier de maximumbreedte beperkt.

De eenheid vw is gebaseerd op de breedte van het venster van de browser. 1 vw is 1% van de breedte van het venster, en 90 vw is 90% van de breedte. <main>, en daardoor ook de erin zittende inhoud, wordt hierdoor nooit breder dan 90% van de breedte van het venster, ongeacht de breedte van het venster.

margin: 20px auto 0;

Omdat voor links geen waarde is opgegeven, krijgt links automatisch dezelfde waarde als rechts. Hier staat dus eigenlijk 20px auto 0 auto in de volgorde boven – rechts – onder – links.

Boven een marge van 20 px voor wat afstand tot de bovenkant van het browservenster. Onderaan geen marge.

Links en rechts auto, wat hier hetzelfde betekent als evenveel. Hierdoor komt <main> altijd horizontaal gecentreerd binnen ouder <body> te staan. <body> is een blok-element en wordt daardoor normaal genomen even breed als z'n ouder <html>. Omdat <html> het buitenste element is, wordt dit normaal genomen even breed als het venster van de browser.

Hierdoor staat uiteindelijk <main altijd horizontaal gecentreerd binnen het venster van de browser, ongeacht de breedte van het venster. En daarmee ook de in <main> zittende inhoudsopgave.

Deze manier van horizontaal centreren van een blok-element werkt alleen, als het blok-element een breedte heeft, want anders zou het normaal genomen even breed worden als de ouder ervan. Dat is geregeld, want iets hierboven heeft <main> een breedte van 660 px en een maximumbreedte van 90 vw gekregen.

border: black solid 1px;

Zwart randje.

padding: 5px;

Aan alle kanten wat afstand tussen de tekst en de buitenkant van <main>.

h1

Alle <h1>'s. Dat is er maar één: de belangrijkste kopregel. Als je de pagina ziet, zie je gelijk dat het om een inhoudsopgave gaat. Voor schermlezers is dat echter niet gelijk duidelijk, daar is deze <h1> voor bedoeld.

position: absolute;

Om de <h1> op een bepaalde plaats neer te kunnen zetten.

Er wordt gepositioneerd ten opzichte van het 'containing block'. Dat is de eerste voorouder die zelf een bepaalde eigenschap heeft, zoals een andere positie dan statisch. Als zo'n voorouder er niet is, zoals hier het geval is, wordt gepositioneerd ten opzichte van het venster van de browser.

top: -300px; left: -20000px;

Boven en links buiten het browservenster zetten. Als de <h1> alleen links buiten het venster wordt gezet, levert dat soms toch nog problemen in schermlezers op. Door de <h1> ook aan de bovenkant buiten het venster neer te zetten, wordt dit voorkomen.

#inleiding a, li a

Alle <a>'s binnen het element met id="inleiding" en alle <a>'s binnen een <li>. Dit zijn bij elkaar alle links in de inhoudsopgave. De eerste ingang in de inhoudsopgave wijkt wat af, daarom staat de eerste <a> niet in een <li>, maar binnen p#inleiding.

color: black;

Zwarte kleur.

Standaard hebben links een wat afwijkende kleur, maar dat is hier niet echt heel mooi. Aan de lay-out is hier al te zien dat het om links gaat, dus een aparte kleur is niet echt nodig.

display: flex;

De waarde flex is onderdeel van een hele reeks eigenschappen en waarden, die bij elkaar 'flexbox' worden genoemd. Met display: flex; worden de <a>'s in een zogenaamde 'flex container' veranderd. Dit maakt het veel makkelijker om de directe kinderen van dit element, de 'flex items', op een bepaalde plaats neer te zetten. De directe kinderen van de <a>'s zijn hier de twee <span>'s met tekst en paginanummers.

In dit geval komen de twee <span>'s naast elkaar te staan, omdat dat de standaardinstelling van flex-direction is. Zou je hier flex-direction: column; gebruiken, dan zouden de flex items onder elkaar komen te staan.

De waarde van flex-direction is van belang voor een aantal andere eigenschappen van flexbox, zoals het iets verderop gebruikte flex-grow en flex-end.

text-decoration: none;

Standaard zijn links onderstreept, maar dat is hier niet echt heel mooi. Aan de lay-out is al te zien dat het om links gaat, dus onderstrepen is niet echt nodig.

margin-bottom: 12px;

Tamelijk grote marge aan de onderkant van elke link. Bij gebruik van een muis is dat niet nodig, maar op touchscreens wel. Een vinger is veel minder nauwkeurig dan een muis. Een klik of aanraking werkt niet op een marge, dus hierdoor krijg je 'n stukje 'niemandsland' tussen de links. Zou je padding gebruiken in plaats van margin, dan zou een klik of aanraking wel werken en zou het heel makkelijk zijn net de verkeerde link aan te raken.

#inleiding a:visited, li a:visited

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

#inleiding a, li a {color: black; display: flex; text-decoration: none; margin-bottom: 12px;}

Alle <a>'s binnen het element met id="inleiding" en alle <a>'s binnen een <li>, maar alleen als deze zijn bezocht. Dit zijn bij elkaar alle links in de inhoudsopgave. De eerste ingang in de inhoudsopgave wijkt wat af, daarom staat de eerste <a> niet in een <li>, maar binnen p#inleiding.

color: #6b1e8b;

Hier iets boven is bij #inleiding a, li a de standaardkleur van een link veranderd in zwart, omdat de links ook zonder die kleur wel zijn te herkennen. Als de link is bezocht wordt de kleur van de link wel aangepast, omdat je anders niet kunt zien, welke link al is bezocht.

#inleiding a:focus-visible, li a:focus-visible

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

#inleiding a, li a {color: black; display: flex; text-decoration: none; margin-bottom: 12px;}

Alle <a>'s binnen het element met id="inleiding" en alle <a>'s binnen een <li>, maar alleen als dit element de focus heeft, én als zichtbaar moet zijn dat dit element de focus heeft. Dit zijn bij elkaar alle links in de inhoudsopgave. De eerste ingang in de inhoudsopgave wijkt wat af, daarom staat de eerste <a> niet in een <li>, maar binnen p#inleiding.

Sommige mensen gebruiken niet de muis of een touchscreen, maar de Tab-toets om links, knoppen, tekstvelden, en dergelijke te bezoeken. Dat kan vanwege een beperking zijn, maar ook omdat het vaak gewoon veel sneller werkt dan de muis. Elke keer als de Tab-toets wordt ingedrukt, wordt een volgend element bezocht. Dat element heeft dan de 'focus': een link bijvoorbeeld wordt dan gevolgd bij het indrukken van Enter, in een tekstveld kan tekst worden ingevoerd, enzovoort.

Welk element de focus heeft, wordt standaard aangegeven door er een kadertje omheen te zetten. Dat is belangrijk, want anders weet een gebruiker van de Tab-toets niet, waar op de pagina deze is, en welke link bijvoorbeeld gevolgd wordt bij het indrukken van Enter.

Bij gebruik van een touchscreen of de muis is zo'n kadertje niet nodig, want je mag hopen dat iemand weet waar is geklikt of aangeraakt. In het verleden was dat een probleem, want die kadertjes zijn spuuglelijk. Daarom werden ze vaak verwijderd. Maar dat maakt een site dus (vrijwel) onbruikbaar voor gebruikers van de Tab-toets.

:focus-visible lost dit probleem op. Als vinger of muis worden gebruikt, wordt geen kadertje om het element met de focus neergezet, maar bij gebruik van de Tab-toets wel. Het lelijke kadertje is nu weg, tenzij het echt nuttig is.

outline: blue solid 3px;

Blauwe outline rondom het element met focus zetten. Een outline en geen border, want een outline neemt geen ruimte in beslag. Bij gebruik van een border zou elke link die de focus krijgt met alles wat eronder staat een stukje verspringen.

#inleiding

Het element met id="inleiding". Dit is de eerste ingang in de inhoudsopgave. Deze wijkt wat af van de andere, daarom heeft deze een eigen id.

font-variant: small-caps;

Kleinkapitalen.

Als de gebruikte lettersoort een kleinkapitaal als variant heeft, wordt die gebruikt. Veel lettersoorten hebben die variant niet. Een kleinkapitaal wordt speciaal ontworpen, het is iets anders dan 'alle letters als grotere of kleinere hoofdletters weergeven'. Sommige letters kunnen er zelfs heel anders uitzien.

Als de lettersoort geen kleinkapitaal als variant heeft, maakt de browser die. Dat wil zeggen dat de browser gewoon alle letters in grotere of kleinere hoofdletters veranderd. Dat kan mooi zijn, maar vaak is het foeilelijk. Het is heel iets anders dan een speciaal ontworpen font. Elke rechtgeaarde typograaf gruwt hiervan.

font-weight: bold;

Vette letter.

Als de gebruikte lettersoort een vette variant heeft, wordt die gebruikt. De meeste lettersoorten hebben wel een vette variant, soms zelfs meerdere. Een vette variant wordt speciaal ontworpen, het is iets anders dan 'alle lijntjes wat dikker maken'. Sommige letters kunnen er zelfs heel anders uitzien.

Als de lettersoort geen vette variant heeft, maakt de browser de letter vet. Dat wil zeggen dat de browser gewoon alle lijntjes wat dikker maakt. Dat kan mooi zijn, maar vaak is het foeilelijk. Het is heel iets anders dan een speciaal ontworpen font. Elke rechtgeaarde typograaf gruwt hiervan.

margin-left: 30px;

Marge links, zodat de inleiding wat inspringt.

.romeins-23

De elementen met class="romeins-23". Dat is er maar één: de <span> die voor schermlezers het Romeinse 'XXIII' vervangt door 'bladzijde romeins 23'. Waarom dit nodig is, is te vinden bij WAI-ARIA-codes.

position: absolute;

Om de <span> op een bepaalde plaats neer te kunnen zetten.

top: -300px; left: -20000px;

Boven en links buiten het browservenster zetten. Als de <span> alleen links buiten het venster wordt gezet, levert dat soms toch nog problemen in schermlezers op. Door de <span> ook aan de bovenkant buiten het venster neer te zetten, wordt dit voorkomen.

ol

Alle <ol>'s. De inhoud is onderverdeeld in een aantal <ol>'s, omdat de daarin zittende <li>'s relatief makkelijk zijn op te maken. Bovendien zijn <ol>'s goed toegankelijk voor schermlezers, omdat deze van <ol> naar <ol> kunnen 'springen'.

list-style: none;

Bolletjes en dergelijke bij de <li>'s weghalen.

In oudere versies van iOS worden hierdoor <ol>'s niet meer als lijst herkend in schermlezer VoiceOver. In nieuwere versies kan dit worden opgelost door de <ol>'s binnen een <nav> te zetten. Meer hierover bij <nav>.

padding: 0;

Standaard heeft een <ol> links een padding van maar liefst 40 px. Die wordt hier weggehaald.

ol ol

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

ol {list-style: none; padding: 0;}

Alle <ol>'s die binnen een andere <ol> staan.

margin-left 10px;

Links een marge van 10 px. Hierdoor springt elke geneste <ol> een klein stukje in. Waardoor ook de in de <ol>'s zittende <li>'s een klein stukje inspringen. Hierdoor is beter te zien, welke ingangen bij een bepaald hoofdstuk en dergelijke horen.

#bijlage ol

Voor dit element is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

ol {list-style: none; padding: 0;}

ol ol {margin-left: 10px;}

Alle <ol>'s binnen het element met id="bijlage". Dat is er maar één. In deze <ol> zitten de ingangen onder 'Bijlage A Modules installeren'. In het origineel in het boek springen deze iets meer in, dus dat gebeurt hier ook.

margin-left: 20px;

Links een marge van 20 px, waardoor de <ol> 'n stukje inspringt. Hierdoor springen de in de <ol> zittende <li>'s ook zo'n stukje in.

.tekst

De elementen met class="tekst". De <span>'s waar de tekst in zit.

flex-grow: 1;

Deze <span>'s zijn directe kinderen van de <a>'s, die bij #inleiding a, li a met display: flex; in een flex container zijn veranderd. Hierdoor zijn deze <span>'s veranderd in een 'flex item', waardoor ze makkelijk neer zijn te zetten.

Een flex item neemt standaard niet meer ruimte in dan nodig is om de inhoud ervan weer te geven.

Tekst en paginanummers staan tegen elkaar aan

Op de afbeelding is flex-grow: 1; even weggehaald. De <a>'s, de flex containers waar de <span>'s in zitten, hebben een blauwe achtergrond gekregen. De <span>'s zijn nu niet breder dan nodig is om de tekst erin weer te geven. De <span>'s met de paginanummers staan daardoor tegen de tekst aan.

(Op de afbeelding zijn maar 'n paar ingangen weergegeven. Andere ingangen geven door alle andere lay-out een vertekend beeld van wat er zonder flex-grow gebeurt, vandaar.)

Met flex-grow regel je hoe groot een flex item mag worden. Dat kun je heel precies opgeven en er zijn ook nog eigenschappen die regelen dat een flex item kleiner mag worden, maar dat gebeurt hier allemaal niet. De waarde 1 bij flex-grow betekent heel simpel dat de <span> mag groeien.

Er zijn twee directe kinderen van flex container <a> in elke <a>: span.tekst met de tekst en span.blz met het paginanummer. De standaardwaarde van flex-grow is 0: niet groeien, niet breder worden dan nodig is om de inhoud ervan weer te geven. Omdat bij span.blz niets wordt opgegeven, groeit span.blz niet. Alle vrije ruimte in flex container <a> wordt hierdoor gebruikt door de tekst. (En later wordt die vrije ruimte dan opgevuld met voorlooppunten, maar dat staat hier min of meer los van.)

overflow: hidden;

In elke span.tekst zit een span.puntjes, die voor de voorlooppunten zorgt:

<span class="tekst">Workshop<span class="puntjes" aria-hidden="true"></span></span>

Bij .puntjes::after worden met behulp van ::after bij span.puntjes 330 puntjes weergegeven, de voorlooppunten. Omdat span.puntjes achter de tekst in span.tekst staat, komen die punten gewoon achter de tekst te staan. Daar passen natuurlijk nooit 330 punten achter. (330 punten, dat is altijd genoeg. Tweehonderd of zo trouwens ook, waarschijnlijk.)

De standaardwaarde bij overflow is visible: geef alles weer, ook als het niet in het element past. Mogelijk wordt dan wel de lay-out verpest, maar er verdwijnt in ieder geval geen tekst of zo. Alleen is een browser niet zo heel erg slim. Die puntjes worden als gewone tekst gezien, en dus weergegeven.

Op de afbeelding heeft span.tekst een blauwe achtergrond gekregen. De <span> loopt netjes door tot aan het paginanummer, zoals de bedoeling is. En de puntjes lopen netjes door buiten span.tekst, zoals niet de bedoeling is. Met overflow: hidden; verberg je, wat niet in het element past. In dit geval worden de puntjes die niet binnen span.tekst passen verborgen. Door nog wat te goochelen met marges en zo eindigen ze dan net voor het paginanummer.

text-indent: -10px;

Elke eerste regel van de <span> 10 px naar links zetten. Je zou dit ook met behulp van een extra <span> kunnen doen, maar dan moet je precies weten hoelang die eerste regel is. En dat weet je niet, want bij een grotere of kleinere letter wordt de eerste regel langer of korter. Nu regelt de browser het en wordt het automatisch aan de lettergrootte aangepast.

hyphens: auto;

Automatisch afbreken aanzetten. Voor bredere browservensters wordt dit later weer uitgezet, maar in smallere vensters voorkomt dit grote lege ruimtes aan het eind van een regel.

padding-left: 10px;

Hier iets boven is met text-indent: -10px; elke eerste regel 10 px naar links gezet. Hier wordt de tekst in de <span> weer 10 px naar rechts gezet. De eerste regel staat hierdoor weer op dezelfde plaats als zonder text-indent en padding-left: -10 px + 10 px = 0 px. Maar tweede en latere regels worden niet met text-indent 10 px naar links gezet, die worden hier alleen 10 px naar rechts gezet. En springen dus iets in ten opzichte van de eerste regel.

(Het effect hiervan zie je uiteraard alleen maar als de tekst te lang is voor één regel.)

position: relative;

Om nakomelingen van span.tekst te kunnen positioneren ten opzichte van de <span>, moet de <span> zelf een andere positie dan statisch hebben. Een relatieve positie heeft verder geen invloed op span.tekst, omdat niets voor top en dergelijke wordt opgegeven.

.puntjes::after

Met behulp van ::after wordt bij de elementen met class="puntjes", de <span>'s die voor de voorlooppunten zorgen, een pseudo-element gemaakt. Dit pseudo-element wordt gebruikt om de voorlooppunten weer te geven.

content: "..........................................................................................................................................................................................................................................................................................................................................";

Binnen content staat tussen aanhalingstekens wat wordt weergegeven. In dit geval zijn dat 330 gewone punten. Dat zijn er zoveel, omdat ze de ruimte tussen de tekst en het paginanummer moeten opvullen, en je weet niet hoe groot die ruimte is. Tweehonderd of zo was trouwens waarschijnlijk ook al ruim voldoende geweest, maar bij gebrek aan een kind dat wat wilde bijverdienen, zijn die puntjes niet precies uitgeteld.

font-size: 0.7rem;

Kleinere letter dan normaal.

Als eenheid wordt de relatieve eenheid rem gebruikt, omdat bij gebruik van een absolute eenheid zoals px niet alle browsers de lettergrootte kunnen veranderen. Zoomen kan wel altijd, ongeacht welke eenheid voor de lettergrootte wordt gebruikt.

De minder bekende rem is ongeveer hetzelfde als de em. Alleen is de lettergrootte bij rem gebaseerd op de lettergrootte van het <html>-element, waardoor de rem overal op de pagina precies even groot is, ook als de bezoeker de lettergrootte heeft veranderd.

Een deel van de ingangen in de inhoud heeft een andere lettergrootte. Als de punten als lettergrootte 0,7 em zouden krijgen, zou dat ten opzichte van die andere lettergrootte zijn. Hierdoor zouden de verschillende rijen punten een verschillende grootte krijgen, wat nogal lelijk is.

Omdat in de inhoud nogal wat verschillende lettergroottes worden gebruikt, is het hier het makkelijkste om gewoon overal in de inhoudsopgave rem als eenheid te gebruiken. De verschillende lettergroottes kunnen elkaar dan niet beïnvloeden.

Die 0,7 rem is een kwestie van smaak. Alles blijft gewoon werken bij een andere lettergrootte voor de puntjes

font-weight: normal;

Sommige ingangen in de inhoud hebben een vette letter. Omdat span.puntjes onderdeel is van die ingangen, zouden de puntjes in die ingangen ook vet worden. Nu worden alle punten normaal weergegeven.

(Bij sommige ingangen wordt ook cursief en kleinkapitaal gebruikt. Eigenlijk zou je dat ook hier moeten corrigeren, maar bij puntjes zien er cursief en in kleinkapitaal hetzelfde uit als gewone puntjes.)

(Oho, als je tot minstens 300% vergroot en met je neus in de monitor gaat hangen, blijken die puntjes toch cursief te zijn. Maar de enkele gek die neus en monitor daaraan gaat opofferen, heeft vermoedelijk grotere problemen dan cursieve puntjes, dus we laten het lekker zo.)

text-indent: 3px;

Eerste regel 3 px naar rechts laten inspringen. De reden daarvan staat gelijk hieronder, onderaan bij position: absolute;.

position: absolute;

Standaard wordt een met ::after gemaakt pseudo-element gewoon statisch gepositioneerd. De in ::after zittende puntjes worden als gewone tekst gezien. Die combinatie betekent dat de puntjes worden samengevoegd met het woord ervoor. Dat is wat op de afbeelding gebeurt: de puntjes zitten aan het laatste woord 'al' vast. Daardoor wordt dit 'woord' te lang voor de eerste regel en komen 'al' en puntjes op een nieuwe regel te staan.

Goed, dan zetten we aan het begin van de puntjes een spatie, zodat – net als bij gewone woorden – de puntjes op de volgende regel komen te staan. En dat werkt fantastisch. Alleen heeft het één klein nadeel: het ziet er volstrekt belachelijk uit, zoals op de afbeelding is te zien.

Daarom wordt span.puntjes absoluut gepositioneerd: het komt dan helemaal los van de rest van de tekst in span.tekst te staan, zoals op de afbeelding.

Omdat voor left of right niets is opgegeven, komen de puntjes gelijk achter de punt te staan, waar ze ook zonder absolute positionering zouden komen te staan.

De puntjes zijn gewone tekst, daarom komen ze halverwege de regelhoogte te staan. Er is weliswaar geen regelhoogte opgegeven, maar die is standaard aanwezig bij tekst. Dit wordt iets hieronder bij bottom: 1px; gecorrigeerd.

Wat op de afbeelding lastiger is te zien: bij .tekst is met text-indent: -10px; opgegeven dat de eerste regel van de tekst 10 px naar links moet komen te staan. Dit blijkt ook te werken voor de in span.tekst zittende span.puntjes, als deze absoluut wordt gepositioneerd. Hierdoor komen de puntjes niet tegen de tekst aan te staan, maar iets over de tekst heen.

De tekst in span.tekst wordt 10 px naar links gezet. En daardoor de puntjes ook. Met text-indent: 0; bij span.puntjes corrigeer je dat. Maar dan staan de puntjes nog steeds pal tegen de tekst aan. Met het iets hierboven opgegeven text-indent: 3px; corrigeer je het inspringen én zorg je gelijk voor een ruimte van 3 px tussen de tekst en de puntjes.

bottom: 1px;

Omdat span.puntjes gelijk hierboven toch al absoluut is gepositioneerd, kunnen we daar gelijk gebruik van maken om de puntjes onderaan de regel te zetten.

Er wordt gepositioneerd ten opzichte van het 'containing block'. Dat is de eerste voorouder die zelf een bepaalde eigenschap heeft, zoals een andere positie dan statisch. Dat is hier span.tekst, die bij .tekst relatief is gepositioneerd. Op deze hoogte staan de puntjes precies aan de onderkant van de regel met tekst.

.blz

De elementen met class="blz". De <span>'s met de paginanummers.

align-self: flex-end;

Bij #inleiding a, li a is elke <a> in een 'flex container' veranderd. De directe kinderen van de <a> zijn daardoor veranderd in een 'flex item'. Ook deze <span>'s met paginanummers zijn een direct kind van een <a>, en daarmee ook een flex item.

Op de afbeelding zijn de <a>'s, de flex containers, blauw gemaakt. Standaard wordt de inhoud van een flex item bovenin gezet. Als de tekst op één regel past, zoals op de bovenste regel op de afbeelding, staat het paginanummer goed.

Op de onderste regel op de afbeelding past de tekst niet op één regel. De <a>, de flex container, wordt hoger, zodat de tekst erin past. Maar flex item span.blz wordt nog steeds bovenin flex container <a> gezet, waardoor het paginanummer nu te hoog staat.

Met align-self: flex-end; wordt span.blz altijd onderin flex container <a> gezet, ongeacht de hoogte van de <a>.

font-size: 1rem;

Standaard lettergrootte.

Een deel van de ingangen in de inhoud heeft een andere lettergrootte. Als de paginanummers als lettergrootte 1 em zouden krijgen, zou dat ten opzichte van die andere lettergrootte zijn. Hierdoor zouden de verschillende paginanummers een verschillende grootte krijgen, wat nogal lelijk is.

font-weight: normal;

Sommige ingangen in de inhoud hebben een vette letter. Omdat span.blz onderdeel is van die ingangen, zouden de paginanummers in die ingangen ook vet worden. Nu worden alle paginanummers normaal weergegeven.

.blz::before

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

.blz {align-self: flex-end; font-size: 1rem; font-weight: normal;}

Met behulp van a::before wordt bij de elementen met class="puntjes" een pseudo-element gemaakt.

Met behulp van de WAI-ARIA-code aria-hidden="true" zijn de voorlooppunten in span.puntjes voor schermlezers verborgen, want die hebben weinig aan een schermlezer die bij elke ingang 330 keer 'puntje' of zoiets zegt. Voor schermlezers wordt met behulp van dit pseudo-element voor elk paginanummer het woord 'bladzijde' ingevoegd.

content: "bladzijde ";

Het woord dat woord ingevoegd.

position: absolute;

Om het pseudo-element op een bepaalde plaats neer te kunnen zetten.

top: -10000px; left: -20000px;

Ver boven en links buiten het browservenster neerzetten. Ook boven het venster, want als het alleen links buiten het venster wordt neergezet, kan dit bij het voorlezen in sommige schermlezers toch problemen opleveren.

Omdat 'bladzijde' buiten het scherm staat, verstoort het de lay-out niet. Maar schermlezers lezen het gewoon voor.

h2

Alle <h2>'s. Hierin zitten de titels van de twee delen en van de bijlage.

font-size: 1.2rem;

Lettergrootte. De standaardgrootte van een <h2> wordt hier iets kleiner gemaakt.

font-variant: small-caps;

Kleinkapitalen.

margin: 15px 0 0;

Omdat voor links geen waarde is opgegeven, krijgt links automatisch dezelfde waarde als rechts. Hier staat dus eigenlijk 15px 0 0 0 in de volgorde boven – rechts – onder – links.

Links en rechts geen marge. Standaard heeft een <h2> een marge aan boven- en onderkant. Bovenaan wordt die hier verkleind tot 15 px, onderaan wordt die weggehaald.

h3

Alle <h3>'s. Hierin staan de kopjes met de uren en nog wat kopjes en losse ingangen in de bijlage. De <h3> wordt hier niet helemaal correct gebruikt, omdat de inhoudsopgave zoveel mogelijk op het boek moest lijken. Over wat niet helemaal correct is, is meer te vinden bij Schermlezers.

font-size: 1rem;

Lettergrootte. De standaardlettergrootte van een <h3> wordt hier iets verminderd.

font-variant: small-caps;

Kleinkapitalen.

margin: 5px 0;

Omdat voor onder en links geen waarden zijn opgegeven, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 5px 0 5px 0 in de volgorde boven – rechts – onder – links.

Links en rechts geen marge. Een <h3> heeft standaard een marge aan boven- en onderkant, die wordt hier verkleind tot 5 px.

#bijlage h2

Voor dit element is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

h2 {font-size: 1.2rem; margin: 15px 0 0;}

Alle <h2>'s binnen het element met id="bijlage". Dat is er hier maar één: de kop boven de bijlage. Deze kop moet er iets anders uitzien dan de andere <h2>'s.

font-variant: small-caps;

Kleinkapitalen.

font-size: 1rem;

Lettergrootte. De standaard grotere letter van een <h2> wordt teruggebracht tot een gewone lettergrootte.

#bijlage h3

Voor dit element is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

h3 {font-size: 1rem; font-variant: small-caps; margin: 5px 0;}

Alle <h3>'s binnen het element met id="bijlage". Hierin staan wat kopjes binnen de bijlage, maar ook een aantal gewone ingangen binnen de bijlage. De <h3> wordt hier niet helemaal correct gebruikt, omdat de inhoudsopgave zoveel mogelijk op het boek moest lijken. Over wat niet helemaal correct is, is meer te vinden bij Schermlezers.

font-variant: normal;

In de bijlage moeten de <h3>'s er als een gewone letter uitzien, daarom worden de eerder opgegeven kleinkapitalen hier weer weggehaald.

font-weight: normal;

Een <h3> is standaard vet. Dat wordt hier bij de <h3>'s in de bijlage veranderd in normaal.

margin: 0;

Een <h3> heeft standaard een marge aan boven- en onderkant. Deze wordt hier bij de <h3>'s in de bijlage weggehaald.

h4

Alle <h4>'s. Hierin staan wat kopjes boven hoofdstukken binnen de uren, maar ook wat losse ingangen binnen de uren.. De <h4> wordt hier niet helemaal correct gebruikt, omdat de inhoudsopgave zoveel mogelijk op het boek moest lijken. Over wat niet helemaal correct is, is meer te vinden bij Schermlezers.

font-weight: normal;

Een <h4> is standaard vet. Dat wordt hier veranderd in normaal.

margin: 0;

Een <h4> heeft standaard een marge aan boven- en onderkant. Die wordt hier weggehaald.

.samenvatting .tekst, .samenvatting ~ li .tekst

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

.tekst {flex-grow: 1; overflow: hidden; text-indent: -10px; hyphens: auto; padding-left: 10px; position: relative;}

Twee selectors, gescheiden door een komma. .samenvatting .tekst, de eerste:

.samenvatting: alle elementen met class="samenvatting".

.tekst: alle elementen met class="tekst".

De hele eerste selector: alle elementen met class="tekst" binnen een element met class="samenvatting". Dit zijn de <span>'s met tekst binnen de <li>'s aan het eind van elk uur met het woord 'Samenvatting'.

De tweede selector, .samenvatting ~ li .tekst:

.samenvatting: alle elementen met class="samenvatting".

~: het hierachter staande element moet ergens in de html staan, na het hiervoor staande element. Het hoeft er, anders dan bij de +, niet gelijk op te volgen, als het maar ergens na het eerste element in de html staat.

De enige voorwaarde is verder dat het voor en het na de ~ staande element dezelfde ouder hebben. Dat is hier het geval: li.samenvatting voor de ~ en de <li>'s na de ~ hebben alle als ouder dezelfde <ol>.

.tekst: de elementen met class="tekst". De <span>'s waar de tekst in zit.

De hele tweede selector in gewone taal: doe iets met de <span>'s met tekst die in de <li>'s zitten, die volgen op li.samenvatting.

Bij elkaar bestrijken deze twee selectors de ingang 'Samenvatting' en de daarop volgende ingangen van dat uur, tot aan het einde van het uur. De samenvatting en de onderdelen daarvan worden iets anders weergegeven dan de andere ingangen.

font-style: italic;

Cursief.

Als de gebruikte lettersoort cursief als stijl heeft, wordt die gebruikt. Heel veel lettersoorten hebben die stijl. Een cursieve stijl wordt speciaal ontworpen, het is iets anders dan 'alle letters gewoon 'n beetje scheef neerzetten'. Sommige letters kunnen er zelfs heel anders uitzien.

Als de lettersoort geen cursief als stijl heeft, maakt de browser die. Dat wil zeggen dat de browser gewoon alle letters een soort schop geeft, waardoor ze allemaal 'n beetje omvallen. Dat kan mooi zijn, maar vaak is het foeilelijk. Het is heel iets anders dan een speciaal ontworpen font. Elke rechtgeaarde typograaf gruwt hiervan.

.paragraaf

De elementen met class="paragraaf". Dit zijn de <li>'s met de ingangen die het meest moeten inspringen.

margin-left: 10px;

Marge links, waardoor deze ingangen iets verder naar rechts komen te staan.

.module

De elementen met class="module". In de bijlage staan een paar ingangen die een kleinere letter moeten krijgen. De <li>'s met die ingangen hebben een class="module".

font-size: 0.9rem;

Iets kleinere lettergrootte.

.module a

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

#inleiding a, li a {color: black; display: flex; text-decoration: none; margin-bottom: 12px;}

De <a>'s binnen een element met class="module". Dit zijn de links binnen de ingangen die gelijk hierboven bij .module een kleinere letter hebben gekregen.

margin: 13px 0;

Omdat voor onder en links geen waarden zijn opgegeven, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 13px 0 13px 0 in de volgorde boven – rechts – onder – links.

Eerder hebben de <a>'s bij #inleiding a, li a aan de onderkant een marge gekregen, zodat ze ook met een vinger op een touchscreen goed zijn aan te raken. Als je geen regelhoogte opgeeft, heeft tekst standaard een regelhoogte die bij de lettergrootte past. De marge aan boven- en onderkant wordt bij die regelhoogte opgeteld, waardoor je voldoende afstand tussen de <a>'s hebt.

Bij de <a>'s binnen <li> met class="module" echter is iets hierboven bij .module de lettergrootte verkleind. Daardoor wordt ook de bijbehorende regelhoogte kleiner. Waardoor de afstand tussen deze <a>'s net te weinig wordt om goed aan te kunnen raken op een touchscreen. Door de marge aan boven- en onderkant iets te vergroten, wordt dit opgelost.

#register h3

Voor dit element is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat.

h3 {font-size: 1rem; font-variant: small-caps; margin: 5px 0;}

bijlage h3 {font-variant: normal; font-weight: normal; margin: 0;}

Alle <h3>'s binnen het element met id="register". Dat is er maar één: de ingang helemaal onderaan met het woord 'Register'. De <h3> wordt hier niet helemaal correct gebruikt, omdat de inhoudsopgave zoveel mogelijk op het boek moest lijken. Over wat niet helemaal correct is, is meer te vinden bij Schermlezers.

font-size: 1.2rem;

Lettergrootte. Eerder is de lettergrootte van de <h3>'s verkleind. Hier wordt die voor deze <h3> weer wat vergroot.

font-variant: small-caps;

Kleinkapitalen.

font-weight: bold;

Vette letter.

css voor vensters minimaal 640 px breed

@media screen and (min-width: 640px)

De css die hier tot nu toe staat, geldt voor alle browservensters. De css die binnen deze 'media query' staat, geldt alleen voor vensters die minimaal 640 px breed zijn. In deze bredere vensters worden lettergrootte, inspringingen, en dergelijke iets vergroot.

@media: geeft aan dat het om css gaat die alleen van toepassing is, als aan bepaalde voorwaarden wordt voldaan. Al langer bestond de mogelijkheid om met behulp van zo'n @media-regel css voor bijvoorbeeld printers op te geven. css3 heeft dat uitgebreid tot veel meer eigenschappen, zoals de breedte en hoogte van het venster van de browser.

screen: deze regel geldt alleen voor schermweergave.

and: er komt nog een voorwaarde, waaraan moet worden voldaan.

(min-width: 640px): het venster moet minimaal 640 px breed zijn. Is het venster smaller, dan wordt de css die binnen deze media query staat genegeerd.

Gelijk na deze regel komt een { te staan, en aan het einde van de css die binnen deze query valt een bijbehorende afsluitende }. Die zijn in de regel hierboven weggevallen, maar het geheel ziet er zo uit:

@media screen and (min-width: 640px) { body {color: silver;} (...) rest van de css voor deze media query (...) footer {color: gold;} }

Voor de eerste css binnen deze media query staat dus een extra {, en aan het eind staat een extra }.

Als je nou 'n mobieltje hebt met een resolutie van – om maar wat te noemen – 1024 x 768 px, dan geldt deze media query soms toch niet voor dat mobieltje. Terwijl dat toch echt meer dan 640 px breed is. Een vuig complot van gewetenloze multinationals? Voordat je je gaat beklagen bij Radar, zou ik eerst even verder lezen.

Steeds meer mobiele apparaten, maar ook steeds meer gewone beeldschermen, hebben een hogere resolutiedichtheid. Dat wil zeggen dat ze kleinere pixels hebben, die dichter bij elkaar staan. Daardoor zijn foto's, tekst, en dergelijke veel scherper weer te geven. Hoe kleiner de puntjes (de pixels) zijn, waaruit een afbeelding is opgebouwd, hoe duidelijker het wordt.

Er ontstaat alleen één probleem: als je de pixels twee keer zo klein maakt, wordt ook wat je ziet twee keer zo klein. En inmiddels zijn er al apparaten met pixels die meer dan vier keer zo klein zijn. Een lijntje van 1 px breed zou op die apparaten minder dan 'n kwart van de oorspronkelijke breedte krijgen en vrijwel onzichtbaar zijn. Een normale foto zou in een thumbnail veranderen. Kolommen zouden heel smal worden. Tekst zou onleesbaar klein worden. Allemaal fantastisch scherp, maar je hebt 'n vergrootglas nodig om 't te kunnen zien.

Om dit te voorkomen wordt een verschil gemaakt tussen css-pixels en schermpixels (in het Engels 'device-pixels'). De css-pixels zijn gebaseerd op de – tot voor kort – normale beeldschermen van de desktop. 1 css-pixel is op zo'n beeldscherm 1 pixel. Het aantal schermpixels is het werkelijk op het apparaat aanwezige aantal pixels (dat is het aantal pixels, waarvoor je hebt betaald).

Dat eerder genoemde mobieltje van 1024 x 768 px heeft wel degelijk het aantal pixels, waarvoor je hebt betaald. Maar die zitten dichter bij elkaar. Op een gewoon beeldscherm zitten 96 pixels per inch, wat wordt uitgedrukt met de eenheid ppi ('pixels per inch'). (Vaak wordt foutief de eenheid dpi gebruikt. Die eenheid is voor printers.) Als dat mobieltje een resolutie van 192 ppi heeft, 192 pixels per inch, zijn de pixels ervan twee keer zo klein als op een origineel beeldscherm. Er zijn per inch twee keer zoveel schermpixels aanwezig.

Om nu te voorkomen dat alles op dat mobieltje twee keer zo klein wordt, geeft het mobieltje niet het echte aantal schermpixels (1024 x 768), maar een lager aantal css-pixels door bij een media query. De 192 ppi van het mobieltje is twee keer zo veel als de 96 ppi van een normaal beeldscherm. Het aantal css-pixels is dan het aantal schermpixels gedeeld door 2. 1024 x 768 gedeeld door 2 is 512 x 384 px. Het aantal css-pixels is 512 x 384 px en zit daarmee dus ruim onder de grens van deze media query.

Je bent dus niet opgelicht, of in ieder geval niet wat betreft het aantal pixel.

Door deze truc is een lijn van 1 px breed op een normaal beeldscherm ook op het mobieltje nog steeds 1 px breed, alleen wordt die ene (css‑)pixel opgebouwd uit twee schermpixels (feitelijk vier, want het verhaal geldt voor breedte én hoogte). De dikte van het lijntje is hetzelfde, maar het is veel fijner opgebouwd. Bij lijntjes is dat verschil bijvoorbeeld in bochten goed te zien.

Hetzelfde verhaal geldt voor hogere resoluties, Een tablet met een breedte van 4096 schermpixels en een ppi van 384 (vier keer de originele dichtheid) geeft 4096 gedeeld door 4 = 1024 css-pixel door. Het lijntje van 1 px breedte op de originele monitor is nog steeds 1 css pixel breed op de tablet, maar die ene css-pixel is nu opgebouwd uit zestien schermpixel.

(Overigens kun je met behulp van media query's ook testen op de resolutie met gebruik van het sleutelwoord 'resolution'. Apple gebruikt het niet-standaard 'device-pixel-ratio', maar het idee is hetzelfde. Dit kan bijvoorbeeld handig zijn om te bepalen, hoe groot een foto moet zijn.)

Kort samengevat: omdat niet het aantal schermpixels (waarvoor je hebt betaald), maar het aantal css-pixels (de door de ontwerper bedoelde afmeting) wordt doorgegeven, wordt voorkomen dat een hogeresolutiescherm onleesbaar klein wordt.

body

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

Voor dit element is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat. (Alleen wat binnen deze media query geldig is, wordt binnen dit blokje herhaald.)

body {background: #ff9; color: black; font-family: Arial, Helvetica, sans-serif; margin: 0;}

font-size: 1.3rem;

Lettergrootte. In deze bredere browservensters wordt de lettergrootte iets vergroot.

main

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

main {background: white; color: black; width: 660px; max-width: 90vw; margin: 20px auto 0; border: black solid 1px; padding: 5px;}

Alle <main>'s. Dat is er maar één: de belangrijkste inhoud van de pagina staat erin. Hier is dat de hele pagina.

padding: 10px;

De eerder opgegeven afstand tussen tekst in en buitenkant van <main> voor deze bredere browservensters iets groter maken.

#inleiding

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

#inleiding {font-variant: small-caps; font-weight: bold; margin-left: 30px;}

Het element met id="inleiding". Dit is de eerste ingang in de inhoudsopgave. Deze wijkt wat af van de andere, daarom heeft deze een eigen id.

margin-left: 70px;

De eerder opgegeven marge links in deze bredere browservensters groter maken.

ol ol ol

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

Voor deze elementen is eerder css opgegeven. Deze wordt binnen dit blokje herhaald in de volgorde, waarin deze in de stylesheet staat, zodat alles hier overzichtelijk bij elkaar staat. (Alleen wat binnen deze media query geldig is, wordt binnen dit blokje herhaald.)

ol {list-style: none; padding: 0;}

ol ol {margin-left: 10px;}

Elke <ol> binnen een <ol> die weer binnen een andere <ol> staat. Hierin zitten de ingangen die binnen de uren vallen.

margin-left: 60px;

In deze bredere browservensters wordt de marge links van deze ingangen vergroot.

#bijlage ol

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

ol {list-style: none; padding: 0;}

ol ol {margin-left: 10px;}

#bijlage ol {margin-left: 20px;}

Alle <ol>'s binnen het element met id="bijlage". Dat is er maar één. De ingangen onder 'Bijlage A Modules installeren' zitten hierin. In het origineel in het boek springen deze iets meer in, dus dat gebeurt hier ook.

margin: 15px 0 0 70px;

In deze bredere browservensters komt aan de bovenkant een marge van 15 px, links een marge van 70 px.

.tekst

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

.tekst {flex-grow: 1; overflow: hidden; text-indent: -10px; hyphens: auto; padding-left: 10px; position: relative;}

.samenvatting .tekst, .samenvatting ~ li .tekst {font-style: italic;}

De elementen met class="tekst". De <span>'s waar de tekst in zit.

text-indent: -30px;

Elke eerste regel van de <span> 30 px naar links zetten. Je zou dit ook met behulp van een extra <span> kunnen doen, maar dan moet je precies weten hoelang die eerste regel is. En dat weet je niet, want bij een grotere of kleinere letter wordt de eerste regel langer of korter. Nu regelt de browser het en wordt het automatisch aan de lettergrootte aangepast.

hyphens: none;

Het eerder voor smallere browservensters aangezette automatisch afbreken wordt hier weer uitgezet, want echt mooi is dat niet. En in deze bredere vensters is het ook niet nodig.

padding-left: 30px;

Hier iets boven is met text-indent: -30px; elke eerste regel 30 px naar links gezet. Hier wordt de tekst in de <span> weer 30 px naar rechts gezet. De eerste regel staat hierdoor weer op dezelfde plaats als zonder text-indent en padding-left: -30 px + 30 px = 0 px. Maar tweede en latere regels worden niet met text-indent 30 px naar links gezet, die worden hier alleen 30 px naar rechts gezet. En springen dus iets in ten opzichte van de eerste regel.

(Het effect hiervan zie je uiteraard alleen maar als de tekst te lang is voor één regel.)

.blz

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

.blz {align-self: flex-end; font-size: 1rem; font-weight: normal;}

De elementen met class="blz". De <span>'s met de paginanummers.

font-size: 1.3rem;

Lettergrootte. Hier iets boven is bij body een lettergrootte van 1,3 rem opgegeven. Die lettergrootte wordt door door de nakomelingen van <body>, waaronder de tekst, geërfd. Maar niet door de <span>'s met de paginanummers, want die hebben eerder bij .blz een lettergrootte van 1 rem gekregen, zodat ze overal even groot zijn.

Om de paginanummers even groot te maken als de tekst krijgen ook de <span>'s met de paginanummers een lettergrootte van 1,3 rem.

padding-left: 4px;

Bij deze grotere lettergrootte is iets meer ruimte links van de paginanummers mooier.

h2

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

h2 {font-size: 1.2rem; margin: 15px 0 0;}

#bijlage h2 {font-variant: small-caps; font-size: 1rem;}

Alle <h2>'s. Hierin zitten de titels van de twee delen en van de bijlage.

font-size: 1.5rem;

In deze bredere browservensters wordt de lettergrootte weer iets groter gemaakt.

h3

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

h3 {font-size: 1rem; font-variant: small-caps; margin: 5px 0;}

#bijlage h3 {font-variant: normal; font-weight: normal; margin: 0;}

#register h3 {font-size: 1.2rem; font-variant: small-caps; font-weight: bold;}

font-size: 1.2rem;

In deze bredere browservensters wordt de lettergrootte weer iets groter gemaakt.

margin: 15px 0;

Omdat voor onder en links geen waarden zijn opgegeven, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 15px 0 15px 0 in de volgorde boven – rechts – onder – links.

Marge aan boven- en onderkant iets verhogen, zodat ook op touchscreens deze ingangen goed kunnen worden aangeraakt.

#bijlage h2

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

h2 {font-size: 1.2rem; margin: 15px 0 0;}

#bijlage h2 {font-variant: small-caps; font-size: 1rem;}

h2 {font-size: 1.5rem; font-variant: small-caps;}

Alle <h2>'s binnen het element met id="bijlage". Dat is er hier maar één: de kop boven de bijlage. Deze kop moet er iets anders uitzien dan de koppen boven de uren.

font-size: 1.2rem;

In deze bredere browservensters wordt de lettergrootte weer iets groter gemaakt.

.paragraaf

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

.paragraaf {margin-left: 10px;}

De elementen met class="paragraaf". Dit zijn de <li>'s met de ingangen die het meest moeten inspringen.

margin-left: 30px;

Marge links, zodat deze ingangen in deze bredere browservensters iets verder inspringen.

.module .blz

Deze selector werkt alleen in browservensters minimaal 640 px breed. Voor andere vensters is de uitleg hieronder niet van belang.

.blz {margin-left: 10px;}

.blz {text-indent: -30px; hyphens: none; padding-left: 30px;}

De elementen met class="blz" binnen een element met class="module". In deze <span>'s staan paginanummers.

In de bijlage staan een paar ingangen die een kleinere letter moeten krijgen. De <li>'s met die ingangen hebben een class="module". In deze bredere browservensters is het mooier, als ook de bijbehorende paginanummers een kleinere letter krijgen (hoewel dat vooral 'n kwestie van smaak is).

font-size: 0.9rem;

Kleinere letter.

Uitleg schaalbare inhoudsopgave met voorlooppunten

Korte omschrijving

BELANGRIJK

Opmerkingen

Achterliggend idee

Semantische elementen en WAI-ARIA

Semantische elementen

<main>

<nav>:

<ol> en <h>

WAI-ARIA-codes

aria-hidden

De code aanpassen aan je eigen ontwerp

Toegankelijkheid en zoekmachines

Getest in

Desktopcomputers

Laptops

Tablets

Smartphones

Schermlezers en dergelijke

Bekende problemen (en oplossingen)

Zonder JavaScript

Zonder css

Tekstbrowsers

Schermlezers

Zoomen en andere lettergrootte

Wijzigingen

Inhoud van de download en licenties

062-css-dl:

062 files-dl:

HTML

<!doctype html>

<html lang="nl">

<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-scale=1">

<link rel="stylesheet" href="062-css-dl/tekst-062-dl.css">

<h1>Inhoudsopgave Perl in 24 uur, 2e editie, 2002, Sams <span lang="en">​Publishing​</span>​</h1>

<p id="inleiding"><a href="062-files-dl/tekst-062-inleiding-dl.html"><span class="tekst">Inleiding<span class="puntjes" aria-hidden="true"></span></span><span class="blz" aria-hidden="true"> XXIII</span><span class="romeins-23">bladzijde romeins 23</span></a></p>

<abbr lang="en" title="Common Gateway Interface">CGI</abbr>

CSS

css voor alle vensters

/* tekst-062-dl.css */

body

main

h1

#inleiding a, li a

#inleiding a:visited, li a:visited

#inleiding a:focus-visible, li a:focus-visible

#inleiding

.romeins-23

ol

ol ol

#bijlage ol

.tekst

.puntjes::after

.blz

.blz::before

h2

h3

#bijlage h2

#bijlage h3

h4

.samenvatting .tekst, .samenvatting ~ li .tekst

.paragraaf

.module

.module a

#register h3

css voor vensters minimaal 640 px breed

@media screen and (min-width: 640px)

body

main

#inleiding

ol ol ol

#bijlage ol

.tekst

.blz

h2

h3

#bijlage h2

.paragraaf

<h1>Inhoudsopgave Perl in 24 uur, 2e editie, 2002, Sams <span lang="en">Publishing</span></h1>