Bij aanraken van, hoveren over of tabben naar een gearceerd woord opent een illustratie - uitleg

Korte omschrijving

Als de cursor boven een van de gearceerde woorden komt, een van de gearceerde woorden wordt aangeraakt, of als je met de Tab-toets naar een van de gearceerde woorden gaat, opent een bij de woorden horende kleine afbeelding.

Opmerkingen

• Dit voorbeeld is oorspronkelijk gemaakt in de tijd dat er nog (vrijwel) alleen (grote) desktopcomputers met toetsenbord en muis bestonden. Dat was relatief simpel: als je met een muis over een gearceerd woord hoverde, verscheen een afbeelding. Gebruikers van het toetsenbord hadden pech, want ook deze site deed nog niet zoveel aan toegankelijkheid.

  Deze laatste versie van dit voorbeeld werkt inmiddels ook op touchscreens, op smartphones en met het toetsenbord. Maar als je ziet hoeveel aanpassingen er voor allerlei browsers en systemen nodig zijn om afwijkingen en bugs op te vangen, ziet het geheel er toch wat wiebelig uit. Je kunt je dan ook afvragen, of het verstandig is deze techniek 'in het echt' te gebruiken.

• De in dit voorbeeld gebruikte afbeeldingen zijn bedoeld als kleine aanvullingen. Daarom worden ze niet getoond of beschreven in schermlezers. Voor grotere afbeeldingen die echt wezenlijke informatie geven (en dus voor schermlezers een omschrijving horen te hebben) is deze constructie absoluut ongeschikt.

  Voor schermlezers is deze constructie hoe dan ook niet te gebruiken. Als je gewoon de tekst leest, gaat dat prima. Maar in deze tekst zitten 37 afbeeldingen. Als een schermlezer de tekst voorleest en dat voorlezen 37 keer onderbreekt voor 'n afbeelding, is de tekst niet meer te volgen.

• De 36 afbeeldingen worden altijd allemaal geladen, ook als ze niet worden getoond. Maar omdat deze samen slechts 76,3 kilobyte groot zijn, maakt dat hier weinig uit.
• Er zijn 36 afbeeldingen, maar in de tekst wordt regelmatig het getal 37 genoemd. Weer niet van de whisky af kunnen blijven? Nou, nee. Eén afbeelding wordt twee keer gebruikt. (Mogelijk heb ik bij de eerste versie jaren geleden door woeste uitspattingen wel 'n keer 'n afbeelding dubbel gezien, dat weet ik niet meer.)

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

De tekst is 'n gewone normale tekst (nou ja, normaal, wat heet...). In die tekst zijn bepaalde woorden gearceerd. Die woorden staan in 'n <span>, en als je over die span hovert wordt een kleine afbeelding zichtbaar, die bij dat woord hoort. Als er niet wordt gehoverd, staat die afbeelding links buiten het scherm geparkeerd.

Dat was het oorspronkelijke voorbeeld, zoals dat werkte op desktopcomputers met een muis.

Met een muis of touchpad werkt het nog grotendeels hetzelfde. Alleen wordt nu gebruik gemaakt van het relatief nieuwe position: sticky; waardoor de afbeeldingen niet meer regelmatig gedeeltelijk buiten het venster van de browser komen te staan.

In lage browservensters, zoals op smartphones, werkt dit niet echt lekker. Daarom wordt in lage vensters de afbeelding in het midden van het venster geplaatst.

Voor gebruikers van de Tab-toets is een extra (lege) <span> voor de afbeelding gezet. Door deze <span> tabindex="0" te geven, kan de <span> focus krijgen, waardoor de erachter zittende afbeelding getoond kan worden. In principe zou je ook de afbeelding zelf tabindex="0" kunnen geven, maar dan noemen sommige schermlezers de afbeelding. Wat bij 37 afbeeldingen dus wat bezwaarlijk is.

Als de <span> met de gemarkeerde woorden een tabindex krijgt, melden sommige schermlezers iets als 'klikbaar'. Alleen een lege <span> wordt bij het voorlezen door alle geteste schermlezers volledig genegeerd.

Als een afbeelding wordt geopend door hoveren over of aanraken van een gemarkeerd woord, is duidelijk bij welk woord de afbeelding hoort. Maar bij gebruik van de Tab-toets is dat niet duidelijk. Normaal genomen is een element dat de focus heeft te herkennen aan een kadertje. Hier ontbreekt dat kadertje echter, want de <span> met focus is leeg.

Daarom staan de gemarkeerde woorden, de lege <span> en de afbeelding in een gezamenlijke buitenste <span>. Nieuwere browsers ondersteunen de pseudo-class :focus-within: als een nakomeling van een element focus heeft, kun je het element met behulp van css aanpassen. Zodra de lege <span> focus heeft, kan de buitenste <span> een kadertje krijgen.

Voor browsers die :focus-within niet ondersteunen wordt een klein beetje JavaScript gebruikt om hetzelfde effect te krijgen.

Dan zijn er nog wat aanpassingen voor verschillende browsers en systemen nodig. Deze worden bij de uitleg van de code besproken.

Voorwaarden waaraan html en css moeten voldoen

Voor gebruikers van de Tab-toets is niet duidelijk, bij welke gemarkeerde tekst een afbeelding hoort. Daarom wordt met behulp van de pseudo-class :focus-within de bij een afbeelding horende gemarkeerde tekst voorzien van een kadertje, zodra de afbeelding wordt getoond.

Voor browsers die dit niet ondersteunen, wordt gebruik gemaakt van een beetje JavaScript. Om dit script goed te laten werken, moet de html aan twee simpele voorwaarden voldoen.

De voorvoegsels -moz-, -ms- en -webkit-

Voordat een nieuwe css-eigenschap wordt ingevoerd, is er in de regel een experimentele fase. Browsers passen het dan al toe, maar met een aangepaste naam. Tijdens deze fase kunnen problemen worden opgelost en worden veldslagen uitgevochten, over hoe de standaard precies moet worden toegepast.

Als iedereen het overal over eens is en alle problemen zijn opgelost, wordt de officiële naam uit de standaard gebruikt.

De belangrijkste browsers hebben elk een eigen voorvoegsel:

Firefox: -moz-, naar de maker: Mozilla.

Op webkit gebaseerde browsers, zoals Google Chrome, Opera, Safari en Android browser: -webkit-.

(Google Chrome is van webkit overgestapt op een eigen weergave-machine: Blink. Blink gaat geen voorvoegsels gebruiken. Het is echter een aftakking van webkit, dus het zal nog wel even duren voor -webkit- hier helemaal uit is verdwenen. Ook Opera gebruikt Blink.)

Internet Explorer: -ms-, naar de maker: Microsoft. (Edge gebruikt geen voorvoegsels, maar vanwege compatibiliteit met oudere sites kunnen er nog wat aanwezig zijn.)

Zodra de experimentele fase voorbij is, wordt het voorvoegsel weggelaten. Omdat dat moment niet bij alle browsers hetzelfde is, zet je nu ook al de officiële naam erbij. Deze wordt als laatste opgegeven. Bijvoorbeeld Android browser herkent -webkit-linear-gradient. Zodra Android browser linear-gradient gaat herkennen, zal dit -webkit-linear-gradient overrulen, omdat het er later in staat. Dat ze er beide in staan, is dus geen enkel probleem.

In dit voorbeeld worden user-select en position: sticky; gebruikt.

Inmiddels is de algemene mening dat 'vendor prefixes', zoals deze voorvoegsels in het Engels heten, geen groot succes zijn. Eén van de grootste problemen: veel sitemakers gebruiken alleen de -webkit-variant. Daar kwamen ze in het verleden nog mee weg, omdat Apple op mobiel zo'n beetje 'n monopolie had. Inmiddels is dat niet meer zo, maar deze gewoonte bestaat nog steeds. Waardoor 'n site alleen in op webkit georiënteerde browsers goed is te bekijken.

Dit is zo'n groot probleem dat andere browsers soms de variant met -webkit- ook maar zijn gaan implementeren, naast de standaard. Want als 'n site het niet goed doet in 'n bepaalde browser, krijgt in de regel niet de site maar de browser de schuld.

Vanwege alle problemen met 'vendor prefixes' worden deze door steeds meer browsers niet meer gebruikt. Nieuwe, experimentele css-eigenschappen zitten inmiddels in bijvoorbeeld Firefox, Google Chrome en Safari achter een zogenaamde vlag: de gebruiker moet iets veranderen in de instellingen, waarna de eigenschap gebruikt (en getest) kan worden. Als alles werkt, zoals het hoort te werken, schakelt de browsermaker de vlag standaard in.

Voorlopig zijn we echter nog niet van deze voorvoegsels af. Als je ze gebruikt, gebruik dan álle varianten, en eindig met de variant zonder voorvoegsel, zoals die uiteindelijk ooit gebruikt gaat worden. Als je alleen de -webkit-variant gebruikt, ben je in feite 'n onbetaalde reclamemaker voor Apple.

Semantische elementen en WAI-ARIA

Deze twee onderwerpen zijn samengevoegd, omdat ze veel met elkaar te maken hebben.

Tabindex en Tab-toets

Links, invoervelden in formulieren, en dergelijke kunnen met behulp van de Tab-toets (of een soortgelijke toets) één voor één worden bezocht, in de volgorde waarin ze in de html voorkomen. Shift+Tab-toets keert de volgorde van de Tab-toets om. Dit is een belangrijk hulpmiddel voor mensen die om een of andere reden de muis niet kunnen of willen gebruiken. (En het is vaak ook veel sneller dan de muis, vooral in formulieren.)

In sommige browsers en/of besturingssystemen is dit vreemd genoeg standaard uitgeschakeld en is een zoektocht in de instellingen nodig om dit aan te zetten. Maar gebruikers van de Tab-toets zullen dit al hebben gedaan.

Als je met behulp van de Tab-toets een element hebt bereikt, heeft dit 'focus': als het een link is en je drukt op Enter, wordt de link gevolgd. Bij een tekstveld kun je tekst gaan invoeren. Enzovoort.

De Tab-toets volgt normaal genomen de volgorde van de elementen in de html. Het maakt niet uit, in welke volgorde ze op het scherm staan. Als je met behulp van css de elementen van plaats verwisselt op het scherm, wordt toch gewoon de volgorde in de html gevolgd.

De volgorde van de Tab-toets kan worden veranderd met behulp van het tabindex-attribuut: <div tabindex="3">. Deze <div> zal nu als derde worden bezocht, ook al krijgt een simpele <div> normaal genomen nooit bezoek van de Tab-toets.

Normaal genomen is het gebruik van een tabindex niet nodig. Het is zeker niet bedoeld om de bezoeker als een kangoeroe op een hindernisbaan van onder via links over rechts naar boven te laten springen. Maar soms kan het handig zijn voor kleinere correcties, als de normale volgorde in de html niet optimaal is. Of om een element bereikbaar te maken voor de Tab-toets, zoals de hierboven genoemde <div>.

Schermlezers blijven altijd de volgorde van de html volgen, dus als de tabindex sterk afwijkt van de volgorde in de html, kan dat behoorlijk verwarrend zijn.

De tabindex kan drie verschillende waarden hebben: -1, 0 of een positief getal.

In principe is de volgorde bij gebruik van de Tab-toets als volgt: eerst worden alle positieve getallen in volgorde afgewerkt. Als twee tabindexen dezelfde waarde hebben, wordt de volgorde in de html aangehouden. Een waarde van '0' wordt, afhankelijk van browser en besturingssysteem, verschillend behandeld, waarover iets hieronder bij Tabindex="0" meer.

Muis, toetsenbord, touchpad en touchscreen

Vroeger, toen het leven nog mooi was en alles beter, waren er alleen monitors. Omdat kinderen daar niet af konden blijven met hun tengels, besloten fabrikanten dan maar touchscreens te gaan maken, omdat je die mag aanraken. Het bleek makkelijker te zijn om volwassenen ook te leren hoe je 'n scherm vies maakt, dan om kinderen te leren met hun vingers van de monitor af te blijven.

Zo ontstonden touchscreens en kreeg het begrip ellende een geheel nieuwe lading. In de perfecte wereld van vroeger, waarin alleen desktops bestonden, werkten dingen als hoveren, klikken en slepen gewoon. Zonder dat je eerst 'n cursus hogere magie op Zweinstein hoefde te volgen. Zelfs in JavaScript was het nog wel te behappen, ook voor mensen zoals ik die toevallig niet Einstein heten.

Op dit moment kun je computerschermen ruwweg in twee soorten indelen: schermen die worden aangeraakt, en schermen die worden bediend met hulpmiddelen als een toetsenbord, muis of touchpad. Omdat ook computerschermen zich kennelijk vermengen, bestaan er inmiddels ook schermen die zowel van aanraken als van muizen houden.

Hieronder staat een lijstje met dingen die zijn aangepast voor de verschillende soorten schermen, zodat dit voorbeeld overal werkt. Een touchpad werkt ongeveer hetzelfde als een muis. Als hieronder iets over een muis staat, geldt dit ook voor een touchpad.

Gegenereerde code

Het onderstaande geldt alleen voor desktopbrowsers. In browsers op mobiele systemen is het vaak ook mogelijk gegenereerde code te bekijken, maar dat is veel ingewikkelder. Bovendien verandert de manier, waarop dat kan, nogal snel.

Als je html schrijft, kan dat (hopelijk) in de browser worden weergegeven. Vanuit de browser kun je die html bekijken, precies zoals je hem hebt ingevoerd. Alsof je het in een editor ziet. In Firefox bijvoorbeeld kan dat door in het menu te kiezen voor Extra → Webontwikkelaar → Paginabron. (Of door de veel snellere sneltoets Ctrl+U.) Elke browser heeft dit soort mogelijkheden.

Wat je dan te zien krijgt, is exact de code, zoals jij die hebt ingetypt. Inclusief alle fouten, hoofd- en kleine letters, noem maar op. Als je zo slordig bent om een <p> niet af te sluiten, zit er niet plotsklaps een afsluitende </p> in de code. Als er css wordt gebruikt, html wordt ingevoegd via JavaScript, noem maar op, zie je daar niets van, want dat heb jij niet ingetypt.

Daar heb je dus eigenlijk vrij weinig aan, want die code kende je al. Die heb je zelf bloedig zitten intypen.

Wat de browser daadwerkelijk gebruikt, is iets totaal anders: de gegenereerde code. En die is veel interessanter, want die code blijkt (fors) af te wijken, van wat jij heb ingetypt. De browser gebruikt een tijdelijke kopie van de door jou geschreven code, die zo is aangepast dat er voor de browser mee is te werken.

Elke browser heeft inmiddels mogelijkheden om de gegenereerde code te bekijken. In Firefox bijvoorbeeld in het menu Extra → Webontwikkelaar → Hulpmiddelen in-/uitschakelen. In Google Chrome in het menu onder Meer hulpprogramma's → Hulpprogramma's voor ontwikkelaars. In Edge open je dit door op F12 te drukken, en het kan vast ook via het menu.

Houdt er wel rekening mee dat elke browser de door jou ingetypte code iets zal aanpassen. In Firefox bijvoorbeeld wordt een <P> veranderd in een <p>. Als er 'n </p> mist, is die opeens wel aanwezig in de gegenereerde code. Wat elke browser precies aanpast, zal iets verschillen en kan ook nog veranderen. In het verleden veranderde Internet Explorer bijvoorbeeld een <p> juist in een <P>, nu is dat niet meer zo.

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). Deze programma's maken niet-standaard code die alleen goed te bekijken is in Internet Explorer. In alle andere browsers zie je grotendeels bagger, áls je al iets ziet.

  Publisher en Word zijn niet bedoeld om websites mee te maken. FrontPage is zwaar verouderd en wordt 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.

• Ik maak zelf het liefst een site in Firefox. 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.

• Als tweede voer je de charset in. 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. Ook van Internet Explorer kun je meerdere versies naast elkaar draaien. Op de pagina met links staan onder het kopjes Gereedschap → Weergave en dergelijke testen 'n aantal links die daarbij kunnen helpen. De compatibiliteitsweergave in Internet Explorer is niet geschikt om in te testen, omdat deze enigszins verschilt van de weergave in échte browsers.

  (Overigens wordt op deze site alleen nog in Internet Explorer 11 getest. Oudere versies van Internet Explorer worden niet meer ondersteund en zijn daardoor per definitie uiterst onveilig. In Edge, de opvolger van Internet Explorer, wordt wel gewoon 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, s, 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 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. Maar hier moet je weer goed op de ondersteuning door browsers letten, want niet elke browser ondersteunt al alles van deze eigenschappen, en zeker niet foutloos.

• 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.

• Als uit de tekst in een link niet duidelijk wordt, waar de link naartoe leidt, gebruik dan een title bij de link. Een tekst als 'pagina met externe links' is waarschijnlijk duidelijk genoeg, een tekst als alleen 'links' mogelijk niet. Een duidelijke zwart-witregel is niet te geven, omdat dit ook van tekst en dergelijke in de omgeving van de link afhangt.

• 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 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.)

  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 (Server Side Includes). 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.
• 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. Een uitstekende online contrastchecker is bijvoorbeeld te vinden op snook.ca.

• 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. Hetzelfde geldt voor die fantastisch mooie flash-pagina's, als daarbij geen voorzieningen voor dit soort programma's zijn aangebracht. (Omdat flash wordt uitgefaseerd en op steeds minder machines is te bekijken, zijn flash-pagina's hoe dan ook geen goed idee meer.)

  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 zien. WebbIE is te downloaden vanaf www.webbie.org.uk. (LET OP: kies voor 'Install WebbIE 4 Web Browser Now'. Dat is – op het moment van schrijven – de een na bovenste knop. Als je voor de bovenste download kiest, krijg je 'n hele berg hulpprogramma's erbij, waar je voor het testen niets aan hebt.)

• 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 mei 2019.

Onder dit kopje staat alleen maar, hoe en waarin is getest. Alle eventuele problemen, ook die met betrekking tot zoomen, lettergroottes, toegankelijkheid, uitstaan 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:

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, Android en Windows 10 Mobile, waar een touchscreen is gebruikt. Op Windows 8.1 en 10 is getest met touchscreen, touchpad, toetsenbord, muis, en – waar dat zinvol was – op een combinatie daarvan.

Als JavaScript is gebruikt, is op de desktop ook getest zonder JavaScript. Op iOS, Android en Windows 10 Mobile is niet getest zonder JavaScript, omdat je JavaScript in een toenemend aantal mobiele browsers niet uit kunt zetten. Bovendien is een mobiel apparaat zonder JavaScript niet veel meer dan een duur en groot uitgevallen horloge. Ook in Edge is niet getest zonder JavaScript, omdat Microsoft het onmogelijk heeft gemaakt dit uit te zetten. Ten slotte is getest zonder css en – als afbeeldingen worden gebruikt – zonder afbeeldingen.

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 validator van w3c, de css ook. 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 algemene problemen in alle of in specifieke browsers.

Als in een onderdeel één of meer problemen worden besproken, staat in een breed rood kadertje een korte samenvatting daarvan. Bij een onderwerp over toegankelijkheid zijn er soms geen problemen, maar alleen aanpassingen. In dat geval staat in een smal groen kadertje 'Geen problemen'.

Wijzigingen

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

26 juni 2008:

Nieuw opgenomen.

10 april 2009:

Tekst aangepast aan de nieuw verschenen Internet Explorer 8. De code is niet veranderd.

28 mei 2019:

• Met bijzonder groot genoegen alle aanpassingen voor Internet Explorer 10 en eerder eruit gegooid.
• xhtml omgezet naar html5.
• Afbeeldingen worden nu ook getoond bij gebruik van de Tab-toets.
• Werkt nu ook op touchscreens.
• Regelafstand vergroot voor gebruik op touchscreens (anders staan de gemarkeerde woorden te dicht op elkaar).
• Werkt nu ook in kleine browservensters zoals die op smartphones.
• Negatieve marges bij de <img>'s gecorrigeerd (breedte en hoogte waren omgewisseld).
• Afbeeldingen staan nu altijd binnen het venster van de browser.
• Alt-tekst ingekort ('Thumbnail van' overal weggehaald).
• Afbeeldingen duidelijker naam gegeven (bijvoorbeeld '001.jpg' is nu 'lay-out-1.jpg').
• Aantal selectors wat ingekort.
• Aantal nieuwe hoofdstukken, voornamelijk over toegankelijkheid en touchscreens.
• Tig kleinere wijzigingen in de tekst en de code.

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 ode en dergelijke zitten. Voor eventuele schade die door gebruik van materiaal uit deze download ontstaat, in welke vorm dan ok, zijn www.css-voorbeelden.nl en medewerkers daarvan op geen enkele manier verantwoordelijk.

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

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

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

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

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

HTML

CSS

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-037-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.

font-size: 110%;

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

Als eenheid wordt de relatieve eenheid % 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.

margin: 0; padding: 0;

Slim om te doen vanwege verschillen tussen browsers.

(Mogelijk is padding niet meer nodig, maar in het verleden verschilde de standaard-padding tussen browsers. Het is simpeler om dit gewoon te blijven gebruiken dan om een uitgebreide test uit te gaan voeren om te kijken, of dit nog wel nodig is.)

main

Alle <main>'s. Dat is er maar één: de belangrijkste inhoud van de pagina staat erin. (Hier is dat alleen de flauwekultekst met de afbeeldingen.)

background: white;

Witte achtergrond.

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.

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.

display: block;

Oudere browsers kennen <main> niet. Een onbekend element is standaard een inline-element, waardoor eigenschappen als breedte niet kunnen worden gebruikt. Nu weten alle browsers dat dit een blok-element is.

width: 800px;

Breedte. Een maximumbreedte voorkomt te lange, slecht leesbare regels.

max-width: 95%;

Hier gelijk boven is een breedte van 800 px opgegeven. Als het venster van de browser smaller is, moet je hierdoor horizontaal scrollen om alles te kunnen zien. Daarom wordt hier de breedte beperkt tot maximaal 95%.

Een breedte in procenten is normaal genomen ten opzichte van de ouder. Die ouder is hier <body>, een blok-element. Een blok-element wordt normaal genomen automatisch even breed als z'n ouder. Die ouder is <html>. Omdat <html> het buitenste element is, wordt dit normaal genomen even breed als het venster van de browser.

Hierdoor wordt <main> uiteindelijk nooit breder dan 95% van de breedte van het browservenster, ongeacht de breedte van het venster.

line-height: 2em;

Tamelijk grote regelafstand. In de tekst zitten gemarkeerde woorden, die moeten worden aangeraakt om een afbeelding te openen. Door een grotere regelafstand zijn deze gemarkeerde woorden op een touchscreen makkelijk te raken.

Als eenheid wordt de relatieve eenheid em gebruikt, omdat bij gebruik van een absolute eenheid zoals px de regelhoogte niet in alle browsers mee verandert met de lettergrootte. Zoomen kan wel altijd, ongeacht welke eenheid voor de regelhoogte wordt gebruikt.

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 kleine afstand tot de bovenkant van het venster van de browser.

Links en rechts auto, wat hier hetzelfde betekent als evenveel. Hierdoor staat <main> altijd horizontaal gecentreerd binnen z'n ouder <body>, ongeacht de breedte van <body>.

Zoals iets hierboven bij max-width beschreven is <body> altijd even breed als het venster van de browser. Hierdoor staat <main>, en daarmee de tekst en dergelijke erin ook, altijd horizontaal gecentreerd binnen het venster, ongeacht de breedte van het venster.

border: black solid 1px;

Zwart randje.

padding: 5px;

Kleine afstand tussen buitenkant van en tekst in <main>.

h1

Alle <h1>'s. Dat is er maar één: de belangrijkste kopregel van de pagina staat erin.

font-size: 1.4em;

Van zichzelf is een <h1> wel heel enthousiast groot. Daarom wordt hier de lettergrootte iets verkleind.

Als eenheid wordt de relatieve eenheid em 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.

font-weight: normal;

Standaard is een <h1> vet. Hier wordt dat veranderd naar normaal.

text-align: center;

Tekst horizontaal centreren.

.buiten

Alle elementen met class="buiten". In elke span.buiten staat onder andere een stukje gemarkeerde tekst en de daarbij horende afbeelding.

border: transparent solid 1px;

Onzichtbaar randje rondom de <span>. Dit is geen onderdeel van een goocheltruc of zoiets, maar lost een probleem in Google Chrome en Opera op.

Als een nieuwe regel toevallig binnen een stuk gemarkeerde tekst begint, staat een deel van de tekst aan het eind van de bovenste regel. Als over dat deel van de tekst wordt gehoverd, moet de bijbehorende afbeelding gewoon worden getoond.

In Google Chrome en Opera echter wordt de afbeelding wel getoond, maar verdwijnt gelijk weer. En dat in een tempo van tientallen keren per seconde. Bij hoveren over de gemarkeerde tekst in de onderste regel gaat het wel goed.

Een doorzichtige rand rondom de hele constructie blijkt dit op te lossen. Mogelijk zijn er nog wel meer oplossingen mogelijk, maar omdat span.buiten toch al aanwezig is, kan deze worden gebruikt voor deze simpele oplossing.

.markeer

Alle elementen met class="markeer". Dit zijn de <span>'s, waarin de gemarkeerde tekst zit.

background: #fe8;

Afwijkende achtergrondkleur.

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.

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.

border: black dotted 1px;

De tekst die een afbeelding tevoorschijn doet komen, heeft hierboven een afwijkende kleur gekregen. Voor mensen die moeite hebben met kleuren, is dit mogelijk niet duidelijk genoeg. Daarom wordt rondom de tekst ook nog een stippellijntje gezet.

padding: 2px;

Door de <span> een kleine padding te geven, wordt deze wat breder en hoger. Hierdoor wordt de markering wat duidelijker.

img

Alle afbeeldingen.

background: white;

Witte achtergrond.

Normaal genomen zie je de achtergrondkleur van de afbeelding niet. Maar elke <img> heeft een korte alt-tekst. Deze wordt getoond, als de afbeelding om een of andere reden niet wordt weergegeven. Door de afbeelding een witte achtergrond te geven, is de tekst altijd goed leesbaar.

color: black;

Voorgrondkleur zwart. Dit is onder andere de kleur van de alt-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.

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.

display: none;

Afbeelding verbergen. Door display: none; te gebruiken is de afbeelding volledig verborgen voor schermlezers. In dit geval is dat prima, omdat de kleine thumbnails nauwelijks informatie geven. Als de afbeelding wel informatief is, is het geen goed idee deze te verbergen voor schermlezers.

width: 119px; height: 106px;

Alle afbeeldingen hebben dezelfde breedte en hoogte. Het spaart behoorlijk wat html uit, als je die breedte en hoogte één keer opgeeft in de css. Omdat de afbeeldingen normaal genomen niet worden getoond, is het ook niet nodig om er ruimte voor te reserveren bij het opbouwen van de pagina.

margin: -53px 0 0 -60px;

Iets hieronder wordt de linkerbovenhoek van de afbeeldingen met position: fixed;, top: 50%; en left: 50%; precies in het midden van het venster van de browser geplaatst.

De afbeelding is 106 px hoog. Als de afbeelding met een negatieve marge van -53 px naar boven wordt gezet, komt de afbeelding verticaal precies in het midden van het venster van de browser te staan.

De afbeelding is 119 px breed, dus met een negatieve marge naar links van -60 px komt de afbeelding ook horizontaal in het midden van het browservenster te staan.

In browservensters minimaal 630 px hoog wordt de positie van de afbeelding later op een andere manier bepaald. Die manier werkt echter niet in kleinere vensters, omdat de afbeelding dan heel vaak (grotendeels) buiten het venster zou komen te staan.

border: black solid 1px;

Zwart randje rondom de afbeelding.

pointer-events: none;

Deze css-eigenschap moet niet worden verward met Pointer Events uit JavaScript. Hier is heel handig dezelfde naam voor gekozen, maar dit heeft helemaal niets te maken met deze css-eigenschap.

Deze eigenschap zorgt ervoor dat aanraken van of hoveren over de <img> volledig wordt genegeerd. Als de <img> wordt aangeraakt of als erover wordt gehoverd, wordt dit doorgegeven aan het element onder de <img>. Dit is nodig voor Microsoft Edge op een touchscreen.

Op de illustratie is het gemarkeerde woord 'imagemap' te zien met de bijbehorende afbeelding. De afbeelding staat gedeeltelijk over het gemarkeerde woord heen. Omdat de afbeelding doorzichtig is gemaakt, is het hele gemarkeerde woord toch te zien.

Als je op Edge het gemarkeerde woord aanraakt op een plaats, waar later de afbeelding boven komt te staan, sluit de afbeelding gelijk weer. Op de illustratie staat 'ima' niet onder de afbeelding. Als je 'ima' aanraakt, blijft ook op Microsoft Edge de afbeelding geopend. Maar als je 'gemap' aanraakt, het deel waarover de afbeelding komt te staan, sluit de afbeelding gelijk weer.

Het gemarkeerde woord 'imagemap' reageert op :hover. Dat wordt op een touchscreen omgezet naar een aanraking. Als de afbeelding wordt geopend, raak je het gemarkeerde woord onder de afbeelding niet langer aan, want daar raak je nu de afbeelding aan. Dit is precies zoals het hoort en gebeurt in alle browsers.

Oorspronkelijk werd dit opgevangen met img:hover {display: block;}: ook als je over de <img> hovert of deze aanraakt, blijft de <img> geopend. Dit bleek echter op Microsoft Edge tot het hierboven probleem te leiden. Door de <img> volledig ongevoelig voor aanraken (of hoveren) te maken, wordt dit opgelost.

Hier zit één klein nadeel aan. Bij hoveren zou de afbeelding eigenlijk getoond moeten blijven, zolang de cursor boven de <img> staat. Nu sluit de <img> echter, zodra de cursor de gemarkeerde tekst verlaat. Een echt probleem blijkt dit echter niet te zijn.

position: fixed; top: 50%; left: 50%;

De linkerbovenhoek van de afbeelding in het midden van het browservenster neerzetten. Met behulp van de iets hierboven opgegeven negatieve marges komt de afbeelding uiteindelijk precies in het midden van het venster te staan. Het hele verhaal is bij die marges te vinden.

z-index: 100;

Elementen worden normaal genomen op het scherm gezet in de volgorde, waarin ze in de html voorkomen. Op de illustratie staat een afbeelding die tamelijk onderin een <p> staat. Hierdoor komt tekst uit de <p> daaronder over de afbeelding te staan.

Door de <img> een z-index te geven, komt de afbeelding toch boven de latere <p> te staan.

Een z-index werkt alleen in bepaalde omstandigheden. Eén van die omstandigheden is een fixed positie. Die is hierboven gegeven, dus dat is geregeld.

(In browservensters minimaal 630 px breed wordt de<img> relatief of sticky gepositioneerd, en ook dan werkt een z-index.)

.buiten:focus-within .markeer

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.

.markeer {background: #fe8; color: black; border: black dotted 1px; padding: 2px;}

Alle elementen met class="buiten", maar alleen als een nakomeling van dat element focus heeft.

In elke span.buiten zit onder andere een <span class="pict" tabindex="0">. Met behulp van de Tab-toets kunnen links, tekstvelden, en dergelijke worden bezocht. Het bezochte veld heeft focus: een link kan worden gevolgd door het indrukken van Enter, in een tekstveld kan tekst worden ingevoerd, enzovoort.

Normaal genomen kan een <span> geen focus krijgen. Maar door toevoeging van het attribuut tabindex="0" kan dat wel. Dit is het geval bij span.pict. Omdat deze <span> verder helemaal leeg en daardoor onzichtbaar is, kan de <span> alleen focus krijgen door de Tab-toets te gebruiken. Aanraken van of hoveren over een onzichtbare <span> is wat lastig, vandaar. Deze selector kan dus alleen maar werken, als de Tab-toets wordt gebruikt.

Omdat span.pict binnen span.buiten zit, gaat de pseudo-class :focus-within werken, zodra span.pict de focus heeft. Op dat moment kan er dus css worden uitgevoerd bij span.buiten.

outline: green dotted 3px;

Groen gestippeld kadertje rondom span.buiten zetten.

Als je een gemarkeerd woord aanraakt of erover hovert, weet je dat de getoonde afbeelding daarbij hoort. Voor gebruikers van de Tab-toets is dat niet duidelijk. Daarom wordt, als een afbeelding wordt getoond, een groen gestippeld kadertje rondom de gemarkeerde woorden gezet.

Dit kadertje komt rondom span.buiten te staan en daarmee dus ook om alles wat ín span.buiten zit. Dat is span.markeer met de gemarkeerde tekst. Dat komt goed uit, want dat is precies de tekst, waarom het kadertje moet komen te staan.

Slimmeriken denken nou natuurlijk: "ho, wacht even, er zit toch nog veel meer in span.buiten?" (Om minderwaardigheidsgevoelens en andere enge dingen te voorkomen: als je dat niet hebt gedacht, ben je niet dom. Je bent dan zo superslim dat je gelijk de eindconclusie hebt gevonden en deze stap hebt overgeslagen.)

Buiten de tekst zit in span.buiten nog span.pict. Die staat inderdaad ook binnen dat kadertje, maar omdat span.pict leeg is en dus onzichtbaar, heeft die geen invloed op de grootte van het kadertje.

Dan zit er nog de <img> in, maar die is fixed of absoluut gepositioneerd, als deze selector werkt. En een fixed of absoluut gepositioneerd element heeft geen invloed op de grootte van z'n ouder.

Kortom: het kadertje komt precies rondom de gemarkeerde tekst die bij de afbeelding hoort.

Voor browsers die het relatief nieuwe :focus-within niet ondersteunen wordt dit met behulp van een beetje JavaScript gesimuleerd.

.markeer:hover

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.

.markeer {background: #fe8; color: black; border: black dotted 1px; padding: 2px;}

.buiten:focus-within .markeer {outline: green dotted 3px;}

Alle elementen met class="markeer", maar alleen als daarover wordt gehoverd of, op touchscreens, bij aanraking van het element. In deze <span>'s staan de gemarkeerde woorden.

-moz-user-select: none; -ms-user-select: none; -webkit-user-select: none; user-select: none;

Hier staat in feite vier keer hetzelfde: user-select: none;. Waarom dat zo is, staat bij De voorvoegsels -moz-, -ms- en -webkit-.

Als op een touchscreen de gemarkeerde tekst iets langer wordt aangeraakt, opent de afbeelding niet, maar wordt de tekst geselecteerd. Dit maakt het heel moeilijk de afbeelding te openen. (Heel moeilijk, want bij precies de juiste aanraking is de afbeelding toch te zien. Maar het vangen van een vlo met de blote hand is 'n stuk makkelijker.)

Als je de tekst niet kunt selecteren, kun je die ook niet kopiëren en dergelijke. Maar dat geldt alleen als je alleen precies zo'n gemarkeerd stukje wilt selecteren. Als je van iets voor tot iets achter de gemarkeerde tekst selecteert, wordt ook de tussenliggende gemarkeerde tekst geselecteerd, want daar hover je dan niet over. Het selecteren van één extra spatie voor en na de gemarkeerde tekst is al genoeg, om ook de gemarkeerde tekst te kunnen selecteren.

.markeer:hover + span + img, .pict:focus + img

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.

img {background: white; display: none; width: 119px; height: 106px; margin: -53px 0 0 -60px; border: black solid 1px; pointer-events: none; position: fixed; top: 50%; left: 50%; z-index: 100;}

De eerste selector, die voor de komma:

.markeer:hover: alle elementen met class="markeer", maar alleen als daarover wordt gehoverd (of als deze worden aangeraakt). Dit zijn de <span>'s, waarin de gemarkeerde tekst staat.

+: het element achter de + moet in de html direct volgen op het element voor de +. In dit geval gaat het om een <span> die gelijk op span.markeer volgt. Beide elementen moeten ook nog dezelfde ouder hebben. Dat is hier het geval, ze hebben beide als ouder span.buiten.

span: omdat deze <span> direct op span.markeer moet volgen, kan dit alleen span.pict zijn.

+: het element achter de + moet in de html direct volgen op het element voor de +. In dit geval gaat het om de <img> die gelijk op span.pict volgt. Beide elementen moeten ook nog dezelfde ouder hebben. Dat is hier het geval, ze hebben beide als ouder span.buiten.

img: de <img> met de afbeelding.

De hele eerste selector in normale mensentaal: doe iets met de <img> die direct op span.pict en span.markeer volgt, maar alleen als over span.markeer wordt gehoverd (of als deze wordt aangeraakt).

De tweede selector, die na de komma:

.pict:focus: alle elementen met class="pict", maar alleen als die focus hebben. Dit zijn de lege <span>'s die voor gebruikers van de Tab-toets zijn aangebracht.

+: het element achter de + moet in de html direct volgen op het element voor de +. In dit geval gaat het een <img> die gelijk op span.pict volgt. Beide elementen moeten ook nog dezelfde ouder hebben. Dat is hier het geval, ze hebben beide als ouder span.buiten.

img: de <img> met de afbeelding.

De hele tweede selector in normale mensentaal: doe iets met de <img> die direct op span.pict volgt, maar alleen als span.pict focus heeft.

display: block;

Bij img is de <img> met display: none; verborgen. Nu wordt hij zichtbaar gemaakt.

css voor vensters minimaal 630 px hoog

@media screen and (min-height: 630px)

De css die hier tot nu toe staat, geldt voor alle browservensters.

De css die binnen deze media query staat, geldt alleen voor browservensters die minimaal 630 px hoog zijn. In deze hogere vensters wordt de afbeelding niet meer in het midden van het venster gezet, maar meer in de buurt van de bijbehorende tekst.

@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 bepaalde fysieke 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-height: 630px): het browservenster moet minimaal 630 px hoog zijn. Is het venster lager, dan wordt de css die binnen deze media-regel 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-height: 630px) { body {color: silver;} (...) rest van de css voor deze @media-regel (...) footer {color: gold;} }

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

Als je nou 'n mobieltje hebt met een resolutie van – ik roep maar wat – 1024 x 768 px, dan geldt deze media query soms toch niet voor dat mobieltje. Terwijl dat toch echt meer dan 630 px hoog 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 (’dots per inch’) 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 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.

.markeer:hover + span + img, .pict:focus + img

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.)

img {background: white; display: none; width: 119px; height: 106px; margin: -53px 0 0 -60px; border: black solid 1px; pointer-events: none; position: fixed; top: 50%; left: 50%; z-index: 100;}

.markeer:hover + span + img, .pict:focus + img {display: block;}

Deze selector werkt precies hetzelfde als die bij .markeer:hover + span + img, .pict:focus + img, waar een uitgebreidere beschrijving staat. Als over span.markeer (de <span>'s met de gemarkeerde tekst) wordt gehoverd of als deze wordt aangeraakt, of als span.pict focus heeft, doe dan iets met de daaropvolgende <img>.

display: inline;

Bij img is de <img> met display: none; verborgen. Nu wordt hij zichtbaar gemaakt.

De <img> wordt als een inline-element zichtbaar gemaakt. Daardoor wordt de <img> niet op een nieuwe regel gezet, wat met display: block; wel zou gebeuren. De <img> gedraagt zich nu min of meer als normale tekst.

De afbeelding was eerst verborgen met display: none;. Als die afbeelding nu opeens tussen de tekst wordt gezet, neemt die ruimte in. Daardoor zou een deel van de tekst moeten worden verplaats om ruimte te maken. Dat zou uiterst storend zijn. Bovendien wordt soms ook span.markeer verplaatst, de <span> die bij hoveren over en aanraken van de <span> de <img> zichtbaar maakt. Daardoor zouden ook hoveren en aanraken niet meer goed werken.

Je zou dit op kunnen lossen door de <img> absoluut te positioneren. Op die manier is het in de vorige versie opgelost. Maar dat heeft als nadeel dat de afbeelding makkelijk (gedeeltelijk) buiten het browservenster kan komen te staan. Met behulp van het relatief nieuwe position: sticky; kan dit grotendeels worden voorkomen, maar dan neemt de afbeelding wel ruimte in.

Het probleem van de ruimte wordt gelijk hieronder met behulp van negatieve marges opgelost. Hierdoor kunnen display: inline; én position: sticky; worden gebruikt en hebben we het beste uit twee werelden.

margin: -54px -61px -54px -60px;

Boven en onder een negatieve marge van 54 px, rechts van 61 px en links van 60 px.

Iets hoger wordt opgegeven dat de <img> als inline-element moet worden weergegeven. Een marge aan de boven- en onderkant heeft geen effect op inline-elementen zoals een <span>, <a>, <i>, en dergelijke. Ook een <img> is een inline-element en dus zouden marge aan boven- en onderkant geen effect hebben. Maar dat is niet zo.

Een <img> is een bijzonder soort inline-element: een 'replaced element'. De tag <img> wordt vervangen door iets anders: de afbeelding. Een marge aan boven- en onderkant werkt wel op een replaced element, ook als dit een inline-element is.

Zoals hierboven bij display: inline; beschreven is de <img> eerst verborgen en neemt dus geen ruimte in. Maar bij tonen neem de afbeelding opeens wel ruimte in, waardoor de tekst zou moet en opschuiven.

De afbeeldingen zijn 119 px breed en 106 px hoog. Daar komt aan alle kanten nog een border van 1 px bij, dus de breedte wordt 121 px en de hoogte 108 px.

Als aan een element een marge wordt gegeven, wordt het element daadwerkelijk van plaats veranderd. Als aan de bovenkant een negatieve marge van 54 px aan de <img> wordt gegeven, wordt de <img> daadwerkelijk 54 px naar boven verplaatst. Omdat de <img> daadwerkelijk wordt verplaatst, wordt tekst en dergelijke die onder de <img> staat, ook 54 px naar boven verplaatst.

Aan de onderkant wordt ook een negatieve marge van 54 px gegeven. Een negatieve marge aan de onderkant verplaatst alles eronder 54 px naar boven.

De <img> zelf wordt dus 54 px naar boven verplaatst, en alle tekst en dergelijke eronder ook. Samen is dag 2 x 54 = 108 px. Precies de hoogte van de <img> met border. Oftewel: de 108 px hoogte die de <img> bij verschijnen inneemt, worden gecorrigeerd door de negatieve marges. Het lijkt alsof de <img> geen hoogte inneemt.

Precies hetzelfde geldt voor de negatieve marges rechts en links. De marge links verplaatst de <img> 61 px naar links, en de marge rechts verplaatst de tekst rechts van de <img> nog 'ns 60 px naar links. Samen de breedte van de <img> met z'n border.

De <img> neemt dus wel degelijk gewoon ruimte in, maar daar zie je niets van, omdat de negatieve marges dat wegmoffelen.

position: relative;

Hier gelijk onder wordt position: sticky; gebruikt. UC browser op Windows en iOS9 en Internet Explorer ondersteunen dat niet. Daardoor zou het eerder bij img opgegeven position: fixed; van kracht blijven. Dat werkt daar goed, omdat ook top: 50%; en left: 50%; zijn opgegeven.

Iets hieronder worden echter top: 10px; en left: 10px; opgegeven. Dat betekent dat de <img> nu ergens in de linkerbovenhoek van het browservenster zou komen te staan. Daarom wordt hier een relatieve positie opgegeven. Browsers die position: sticky; niet ondersteunen gebruiken de hier opgegeven relatieve positie, en browsers die het wel ondersteunen gebruiken de position: sticky; hieronder, want die staat lager in de css.

(Iets hieronder worden niet alleen nieuwe waarden voor top en left opgegeven, maar ook right: 10px; en bottom: 10px;. In combinatie met position: fixed; is dat een onmogelijke opgave, daarom worden right en bottom iets hieronder genegeerd. Overigens worden die ook genegeerd bij deze relatieve positie, want je kunt een afbeelding niet gelijktijdig naar links én rechts én boven én onder verplaatsen. Althans: dat kan wel, maar dat levert een aantal forse scheuren op.)

position: -webkit-sticky; position: sticky;

Hier staat in feite twee keer hetzelfde: position: sticky;. Waarom dat zo is, staat bij De voorvoegsels -moz-, -ms- en -webkit-.

Dit is een relatief nieuwe eigenschap. Normaal genomen is dit hetzelfde als position: relative;. Hier gelijk onder worden top, right, bottom en left opgegeven, allemaal met 10 px. De <img> wordt dus 10 px naar onder, naar links, naar boven en naar rechts verplaatst. Dat kan natuurlijk niet, en daarom worden right en bottom genegeerd.

Voor een sticky positie is de eerste voorouder die een blok-element is van belang. Dat is de <p>, waar de <img> (en nog wat tekst) in staat. Zodra deze <p> door scrollen buiten het browservenster komt te staan, zorgt de sticky positie ervoor dat de <img> binnen het venster blijft staan. Althans: tot op zekere hoogte. Als je de <p> ver genoeg naar boven of naar beneden scrolt, zal uiteindelijk de <img> ook boven of onder het venster komen te staan.

Hier gelijk onder wordt opgegeven dat de <img> in principe altijd op minimaal 10 px van de boven-, rechter-, onder- en linkerkant van het venster van de browser moet komen te staan. In principe, want als je genoeg scrolt, zal de <img> uiteindelijk verdwijnen. Als je wilt dat de <img> altijd zichtbaar is, moet je een fixed positie gebruiken (zoals in dit voorbeeld bij vensters minder dan 630 px hoog inderdaad is gebruikt).

Hopelijk wordt dit wat duidelijker met behulp van onderstaande illustraties. De <p> waar de <img>'s bij horen heeft een gestippelde rand, zodat duidelijk is, hoe groot de <p> precies is. De vier <img>'s binnen de <p> op de illustratie zijn alle vier zichtbaar gemaakt. In werkelijkheid kan er steeds maar één zichtbaar zijn.

Aan de onderkant werkt dit precies hetzelfde. De <img> staat op z'n 'natuurlijke' hoogte. Zodra de <p> te laag wordt gescrold, komt de <img> op 10 px van de onderkant van het venster van de browser te staan. Als er laag genoeg wordt gescrold, zal de <img> uiteindelijk ook aan de onderkant verdwijnen.

Ook in de breedte werkt dit op dezelfde manier. <main> is 800 px breed, maar nooit breder dan 95% van de breedte van het browservenster.

top: 10px; right: 10px; bottom: 10px; left: 10px;

In principe de <img> altijd op 10 px vanaf alle kanten van het venster van de browser houden. Dit wordt iets hierboven bij position: sticky; veel uitgebreider beschreven.

JavaScript

Als je onderstaande code ergens aanraakt of ‑klikt, ga je rechtstreeks naar de bijbehorende uitleg.

Als je bovenstaande code ergens aanraakt of ‑klikt, ga je rechtstreeks naar de bijbehorende uitleg.

Dit script bestaat uit twee delen.

Het JavaScript voor iOS bestaat uit één simpele regel. Zonder deze regel worden de afbeeldingen op iOS alleen in Firefox, Opera Mini en Microsoft Edge getoond.

Het overige JavaScript is iets langer. Sommige mensen gebruiken niet de muis of aanraken om naar een link, tekstveld, en dergelijke te gaan, maar de Tab-toets. Bijvoorbeeld omdat ze moeite hebben een muis te gebruiken, maar soms is het gewoon ook veel sneller dan een muis.

Als een element met de Tab-toets wordt bezocht, heeft dat element focus. Dat wordt aangegeven door een kadertje rondom het element. Dat is belangrijk, want anders is niet duidelijk, welk element focus heeft. Bij focus wordt een link gevolgd door op Enter te drukken, in een tekstveld kan tekst worden ingevoerd, enzovoort.

In dit voorbeeld kunnen de afbeeldingen ook met behulp van de Tab-toets worden getoond.

Als iemand ergens op de pagina gemarkeerde tekst aanraakt of erover hovert, is duidelijk bij welke tekst de getoonde afbeelding hoort. Maar bij gebruik van de Tab-toets is dat onduidelijk. Daarom wordt bij .buiten:focus-within .markeer met behulp van :focus-within een kadertje getekend rondom de tekst, waarbij de getoonde afbeelding hoort.

Voor browsers die het relatief nieuwe :focus-within niet ondersteunen, wordt dat in dit script geïmiteerd.

Als dit script op meerdere pagina's wordt gebruikt, kan het ook als een extern script worden gebruikt: <script src="pad-naar-script/script.js"></script>

In dat geval moet <script> helemaal onderaan de pagina worden gezet, gelijk boven </body>. Het script zoekt namelijk elementen in de pagina op, en als die nog niet zijn gemaakt door de browser, gaat het mis. Bovendien stopt de opbouw van de pagina, zodra de browser een script ontmoet, omdat het script eerst wordt uitgevoerd. Het zou immers kunnen dat het script (heel) belangrijk is voor de weergave. Dat is hier niet het geval. Door het script onderaan de pagina te zetten, voorkom je ook die in dit geval overbodige vertraging.