Bij hoveren over, aanraken van of tabben naar één van de thumbnails opent een grotere afbeelding met onderschrift - uitleg

Korte omschrijving

Als je met de cursor over een van de kleine thumbnails hovert, er eentje aanraakt of er met de Tab-toets naartoe gaat, opent rechts een grote afbeelding met bijbehorende tekst.

Opmerkingen

• De gebruikte afbeeldingen zijn afkomstig van PD Photo.org (zoeken naar 'insect').
• In theorie hoeven de afbeeldingen niet dezelfde maat te hebben. In de praktijk zou het ontzettend moeilijk zijn zoiets te maken met afbeeldingen die een verschillende maat hebben, omdat je voor elke maat aanpassingen zou moeten maken aan allerlei berekeningen en dergelijke. Daarom is hier maar één maat gebruikt. Of eigenlijk twee: eentje voor de liggende en eentje voor de staande afbeeldingen. De verhouding 4:3 (480 px x 360 px) is een vrij gebruikelijke.
• Dit is géén slideshow. Het is ook niet zo bedoeld. Je kunt 'n willekeurige thumbnail uitkiezen, waarvan je de vergroting wilt zien. Bij een slideshow zit je aan 'n bepaalde volgorde vast, hier niet. Beide vormen hebben hun eigen voor‑ en nadelen, je kunt ze niet zonder meer vergelijken.

• 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 mogelijkheden voor het simuleren van weergave op een kleiner scherm in de ontwikkelgereedschappen ingebouwd. Ook dit blijft een simulatie, maar geeft vaak wel een beter beeld dan zoomen.

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

Alles op deze site is gemaakt op een systeem met Linux (Kubuntu). Daarbij is vooral gebruik gemaakt van Komodo Edit, GIMP en Firefox met extensies. De pdf-bestanden zijn gemaakt met LibreOffice.

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

Achterliggend idee

Omdat oudere versies van Internet Explorer niet meer worden ondersteund, kon de code voor dit voorbeeld een heel stuk worden verbeterd.

Bij openen van de pagina zie je 34 kleine afbeeldingen, zogenaamde 'thumbnails'. (Een Nederlandse vertaling als 'miniatuur' is nooit echt in gebruik geraakt, dus ik blijf ook het algemeen gebruikte 'thumbnail' gebruiken.) 34 kleine afbeeldingen, dat zou betekenen dat er 34 aanroepen naar de server moeten worden gedaan. Iets wat tamelijk veel tijd kost.

In werkelijkheid zijn de 34 thumbnails dan ook geen 34 kleine afbeeldingen, maar is het één grote achtergrond-afbeelding, waarop 34 kleinere afbeeldingen zijn gemonteerd. Dat spaart 33 aanroepen naar de server uit. Bijkomend voordeel: de randjes rondom de thumbnails zijn ook al aanwezig, want dat is gewoon de achtergrond van de grote afbeelding, die door een kiertje zichtbaar is. Je wordt dus dubbel genept: geen thumbnails en geen randjes. Zo'n grote afbeelding die bestaat uit een aantal kleinere afbeeldingen, heet een 'sprite'.

De vier kolommen worden gevormd door vier <div>'s die naar links worden gefloat. Elke <div> vult horizontaal een kwart van de achtergrond-afbeelding. Binnen deze vier <div>'s staat weer een serie <div>'s, eentje voor elke zogenaamde thumbnail. Aan deze <div>'s is een counter gekoppeld, die voor de nummering wordt gebruikt. De nummers die je op de thumbnails ziet zitten dus niet in de html, ze worden met behulp van css automatisch gemaakt.

De 34 <div>'s zijn met behulp van :hover en :focus gevoelig gemaakt voor hoveren met de muis, klikken, aanraken en focus. Door het gebruik van tabindex kunnen ook gebruikers van de Tab-toets de grote afbeeldingen openen.

Op iOS is een miniem stukje JavaScript nodig, omdat aanraken daar anders geen effect heeft. Als JavaScript uit staat, heb je nauwelijks iets aan iOS. Dat daar wat JavaScript nodig is, zal dus geen probleem zijn.

Zodra een thumbnail (of eigenlijk: de <div> boven die thumbnail) op een van bovengenoemde manieren wordt benaderd, opent een grotere afbeelding van de thumbnail. Die grotere afbeelding is een achtergrond-afbeelding in een <span> met class="foto". De <span> wordt met behulp van display: none; verborgen, tot de thumbnail wordt benaderd.

Pas als :hover of :focus bij de <div> boven de thumbnail wordt geactiveerd, krijgt de <span> een achtergrond-afbeelding. Daardoor wordt de grotere afbeelding pas gedownload, als de <span> daadwerkelijk wordt getoond. Zou je de achtergrond-afbeelding op de normale manier aan de <span> geven, of als je <img> zou gebruiken in plaats van background-image, dan zouden alle grote afbeeldingen gelijk bij openen van de pagina worden gedownload, ook als je ze verbergt met behulp van display: none;. Nu worden alleen de grote afbeeldingen gedownload, die daadwerkelijk moeten worden getoond.

Bij gebruik van een muis is dit wel wat betrekkelijk, want om bij de binnenste thumbnails te komen zul je over de meer naar buiten gelegen thumbs moeten hoveren. Waardoor de bij die thumbs horende grote afbeeldingen ook worden gedownload, of je die nu wilt zien of niet. Maar hoveren met de muis zal meestal op een desktopcomputer of een laptop (met een touchpad) gebeuren, en daar zal dat downloaden niet zo'n probleem zijn. Op een smartphone en dergelijke kun je gelijk de goede thumbnail aanraken en hoef je niet de buitenste thumbnails te passeren, dus juist daar wordt onnodig downloaden voorkomen. En juist daar is dat belangrijk, omdat de internetverbinding (veel) slechter kan zijn.

Je zou dit ongewild openen bij het van meer naar buiten gelegen thumbnails waarschijnlijk kunnen oplossen door :hover pas na een kleine vertraging (transition-delay of zoiets) te laten werken, maar daarvoor vind ik dit niet belangrijk genoeg.

Op een hogeresolutiescherm is een veel betere kwaliteit afbeelding mogelijk. Daarom zijn van elke grote afbeelding twee stuks aanwezig: eentje van 480 x 360 px voor gewone beeldschermen en eentje van 960 x 720 px voor hogeresolutieschermen. Meer hierover is te lezen bij Hogeresolutieschermen.

In browservensters met een maximale breedte van 480 px wordt de grote afbeelding over de thumbnails gezet: de afbeelding vult zoveel mogelijk van het venster. Als dat nodig is, wordt de afbeelding verkleind, tot hij in het venster past.

In vensters met een breedte tussen 480 en 760 px gebeurt hetzelfde. De afbeelding wordt daarbij vergroot, tot zoveel mogelijk van het venster is gevuld. Als je de browser de afbeelding laat vergroten, levert dat vaak geen mooi resultaat op. Daarom wordt ook hier de afbeelding van 960 x 720 px gebruikt. Deze wordt dan verkleind, tot hij in het venster past. Verkleinen kan een browser wel goed, dus dat is geen probleem.

In vensters smaller dan 760 px wordt de omgeving van de grote afbeelding donker gemaakt, omdat de thumbnails anders nogal storend afleiden van de grote foto.

Bij browservensters breder dan 760 px is er voldoende ruimte om de grote afbeelding niet over, maar naast de thumbnails te zetten. Hier wordt op een gewoon beeldscherm altijd de afbeelding van 480 x 360 gebruikt, en op een hogeresolutiescherm altijd de afbeelding van 960 x 720 px. De afbeelding wordt nu altijd op een grootte van 480 x 360 px weergegeven.

De twee links onderaan de thumbs hebben geen speciale functie of zo. Ze laten alleen zien dat er meer mogelijk is dan alleen thumbnails. Er hadden ook gewoon nog twee staande foto's kunnen staan.

Als iets is verborgen met display: none; of visibility: hidden;, wordt dit genegeerd door schermlezers, zoals blinden die gebruiken. Bij een foto is dat niet zo'n probleem. Maar ook een blinde kan wat hebben aan de onderschriften bij een foto. Daarom worden die teksten niet verborgen met display: none; of visibility: hidden;. Ze worden niet verborgen, maar links buiten het scherm geparkeerd met behulp van left: -20000px;. Als de foto zichtbaar wordt, wordt de bijbehorende tekst binnen het scherm geplaatst en daardoor zichtbaar.

Het maakt voor een schermlezer niets uit, als iets buiten het scherm staat. Op deze manier kun je dus teksten en dergelijke voor een ziende verbergen, tot ze nodig zijn, terwijl een schermlezer ze gewoon kan voorlezen.

De plaats van de onderschriften is een verhaal op zich, omdat de grootte van het venster van de browser niet bekend is. Want daardoor is ook de grootte van de grote afbeelding niet bekend. En ook niet waar de onderkant van de grote afbeelding precies staat, zodat het niet altijd mogelijk is het onderschrift precies op die afbeelding te zetten aan te laten sluiten.

Met behulp van media query's, calc() en dergelijke wordt het onderschrift zo goed mogelijk neergezet, maar dat lukt niet altijd helemaal goed. Wanneer het onderschrift niet helemaal goed aansluit, worden daarom ronde hoekjes en dergelijke gebruikt, zodat het er beter uitziet.

(Als je de onderschriften altijd perfect wilt plaatsen, ontkom je niet aan JavaScript. Daarmee kun je de plaats van de grote afbeelding opvragen en dan aan de hand daarvan het onderschrift neerzetten. Maar deze site gaat nou eenmaal over css en html, en niet over JavaScript.)

Hieronder staan vier willekeurig gekozen voorbeelden van de plaatsing van het onderschrift. In smallere browservensters vullen onderschrift en grote afbeelding de volle breedte van het venster. In iets bredere liggende vensters heeft het onderschrift een andere breedte dan de grote afbeelding. Omdat dat minder mooi is, heeft het onderschrift hier afgeronde hoeken en een kadertje. In de breedste vensters is het onderschrift weer even breed als de grote afbeelding.

Dan zijn er verder nog wat aanpassingen nodig voor problemen, die zich specifiek in bepaalde browsers voordoen. Zo raakt bijvoorbeeld Internet Explorer op een touchscreen nogal van streek, als een verborgen afbeelding zichtbaar moet worden gemaakt. De ziel is alleen met pointer-events: none; weer tot rust te brengen. Dit soort dingen wordt bij de uitleg van de code besproken.

Hogeresolutie­schermen

Vaak wordt dit soort schermen Retina-schermen genoemd, maar Retina is gewoon de merknaam van Apple voor een hogeresolutiescherm.

Er komen steeds meer apparaten met een hogere resolutie, dan op de desktop gebruikelijk is: meer dpi, dots per inch. Van oudsher wordt helaas 'inch' gebruikt als eenheid. Een nieuwere eenheid is dpcm: dots per centimeter. De beste eenheid voor het meten van de resolutie van een computerscherm is dppx: dots per px unit, maar deze wordt nog lang niet overal ondersteund. 1 dppx is even groot als 96 dpi, de standaardresolutie van een gewone desktop monitor (Apple had een iets andere dpi).

Als je meer pixels in een inch stopt, waardoor de pixels dichter op elkaar staan, krijg je fijnere afbeeldingen. Vooral bij ronde lijnen en dergelijke is dit goed te merken. Een ronde lijn die wordt weergegeven met 72 px per inch is grover, dan diezelfde lijn die met 300 px per inch wordt weergegeven.

Een lijn die op een normale desktopmonitor 4 px breed is, zou op zo'n hogeresolutiescherm van 300 dpi maar 1 px breed zijn. Superduidelijk, dat wel, maar zonder vergrootglas niet te zien. Omdat de pixels vier keer zo dicht op elkaar staan. Bestaande sites die vier (of meer) keer zo klein worden weergegeven, als waar ze voor bedoeld zijn, maken alleen opticiens vrolijk.

Althans: je zou die kleinere weergave op een hogeresolutiescherm verwachten. Maar gelukkig wordt dat voorkomen. Apparaten met een hogeresolutiescherm geven een 'valse' resolutie op. Een iPad met een hogeresolutiescherm geeft niet het aantal 'schermpixels' op, maar het aantal 'css-pixels'. En dat is hetzelfde als bij een 'normale' desktopmonitor. Hierdoor ziet een site er op een iPad hetzelfde uit als op een desktopmonitor.

Niet alleen de iPad heeft dit handigheidje, alle hogeresolutieschermen doen dit. Anders zouden ze volstrekt onbruikbaar zijn voor heel veel sites.

Met behulp van media query's kun je testen op onder andere de resolutie. Dit geeft de mogelijkheid naar hogeresolutieschermen afbeeldingen van een hogere kwaliteit te sturen, terwijl je voor gewone beeldschermen afbeeldingen van mindere kwaliteit kunt gebruiken. Dat is belangrijk, omdat die afbeeldingen van hogere kwaliteit (veel) groter zijn in omvang. Door te testen op resolutie, kun je naar een gewoon beeldscherm de veel kleinere afbeeldingen van mindere kwaliteit sturen.

Helaas zijn er nogal wat sites die dit testen op resolutie doen op een manier, die alleen werkt op een iPad/iPhone en in Safari. Door dat te doen werk je mee aan de kans op net zo'n monopolie, als Internet Explorer ooit had. Dat heeft ons jarenlang grote ellende opgeleverd. Het lijkt me niet handig om dat nog eens te gaan herhalen met Apple, temeer niet omdat Apple zich steeds meer als een gediplomeerd patenttrol begint te gedragen en veelbelovende pogingen doet Microsoft van de troon te stoten als meest onsympathiek bedrijf in de ICT.

In de vorige versie van dit voorbeeld zat bij elke thumbnail maar één grote afbeelding. Hier zijn dat er twee: eentje van 480 x 360 px (of 360 x 480 px voor een staande afbeelding) en eentje van 960 x 720 px (of 720 x 960 px voor een staande afbeelding). Beide afbeeldingen zijn volledig hetzelfde, alleen de afmetingen verschillen. De grotere afbeeldingen eindigen allemaal op '-2x.jpg', de kleinere missen het '-2x' en eindigen op '.jpg'.

Het verhaal hieronder is een stuk simpeler, dan het in werkelijkheid is. Dat heeft twee redenen: ik wil het niet te ingewikkeld maken, en ik ben zelf ook geen expert op het gebied van afbeeldingen. Dingen als (lossless) comprimeren, anti-aliasing en subpixels bijvoorbeeld, laat ik buiten beschouwing. Kennis daarvan is ook niet echt nodig voor dit voorbeeld.

Een jpg-afbeelding – het hier gebruikte formaat – is een zogenaamde bitmap-afbeelding. Wat voor het oog mooie, in elkaar overlopende kleuren en soepele rondingen zijn, bestaat in feite helemaal niet. Het zijn kleine blokjes, die alleen maar zo soepel en vervloeiend zijn, omdat ogen makkelijk voor de gek te houden zijn.

Hieronder staat een stukje van een detail van een vleugel op de zevende foto, vijftien keer vergroot. Dat mooie ronde adertje (of hoe dat ook heet bij 'n insect) blijkt opgebouwd te zijn uit 'n verzameling rotsblokken, waar Stonehenge nog iets van kan leren. Maar als je deze rotspartij niet vergroot, blijkt het er op een beeldscherm prima uit te zien. Omdat mensenogen gewoon niet zo goed zijn.

Althans: tot voor niet zo heel lang geleden zag het er overal mooi uit.

Bij een gewoon beeldscherm komt één blokje op de afbeelding hierboven ongeveer overeen met één dot op de monitor. En omdat je oog zo makkelijk kan worden genept, lijkt dit 'n echte weergave van de werkelijkheid en zie je de aparte dots niet.

Een gewoon beeldscherm heeft meestal 96 dots per inch, oftewel 96 dpi. Een Apple-beeldscherm heeft er 72 per inch.

(Op papier is je oog trouwens minder goed voor de gek te houden, daarom zijn voor een afdruk ruwweg vier keer zoveel dots nodig voor een enigszins acceptabele kwaliteit. Daardoor zijn veel afbeeldingen op internet eigenlijk niet af te drukken: ze bevatten gewoon te weinig pixels voor een kwalitatief goede papieren afdruk.)

En toen kwamen er hogeresolutieschermen. Een hogeresolutiescherm heeft meer dpi, meer dots per inch. Meestal is dat nu nog niet meer dan twee keer zoveel als een gewoon beeldscherm, maar er zijn ook nog hogere resoluties.

Als een scherm een resolutie, een dichtheid, van bijvoorbeeld 200 dpi heeft, is dat ongeveer twee keer zoveel als de resolutie van een gewoon beeldscherm. De dots staan twee keer zo dicht op elkaar, waardoor je veel fijnere details kunt weergeven. Maar die arme afbeelding kan dat helemaal niet aan, want die is bedoeld voor een gewoon beeldscherm met 96 dpi. Op zo'n gewoon beeldscherm zit in de afbeelding voor elke dot op het beeldscherm ongeveer 'n eigen pixel in de afbeelding, waardoor beeldscherm en afbeelding goed op elkaar aansluiten en samen een gelukkige relatie hebben. Op een hogeresolutiescherm merkt de tot dan gelukkige afbeelding opeens dat hij te weinig pixels heeft om het hogeresolutiescherm tevreden te stellen, waardoor de relatie tussen afbeelding en beeldscherm opeens een stuk minder goed wordt. En de weergave van de afbeelding slechter.

Je zou dit kunnen oplossen door de afbeelding twee (of bij nog hogere resoluties drie, vier, ...) keer zo klein weer te geven. Dan vallen de pixels binnen de afbeelding weer gelijk met de dots op het beeldscherm. Dat heeft alleen één niet geheel onbelangrijk nadeel: de afbeelding is weliswaar mooi scherp, maar wel twee (drie, vier, ...) keer zo klein, omdat de pixels dichter bij elkaar staan. Want het aantal pixel in de afbeelding neemt niet op wonderbaarlijke wijze toe.

Als alle afbeeldingen opeens twee (drie, vier, ...) keer zo klein zouden worden op een hogeresolutiescherm, zou dat een ramp zijn voor alle bestaande websites. Geen foto zou nog zonder vergrootglas te bekijken zijn. En hogeresolutieschermen zouden niet verkocht worden, want wat heb je aan zo'n fantastisch scherm, als je 'n vergrootglas nodig hebt om iets te kunnen zien.

Daarom is voor een andere oplossing gekozen: de afbeelding wordt even groot weergegeven als op een gewoon beeldscherm. Waardoor bij een resolutie van 200 dpi van het beeldscherm en een resolutie van 96 dpi van de afbeelding gewoon de helft van de pixels ontbreekt. Die bestaat gewoon niet. De browser probeert die missende pixels zelf aan te vullen. Dat gaat nog niet eens zo slecht, maar het eindresultaat is toch merkbaar slechter, dan wanneer de afbeelding zelf een hogere resolutie zou hebben.

De browser zet als het ware tussen elke twee pixel van de afbeelding één nieuwe pixel, waarbij zo goed mogelijk wordt geraden welke kleur die pixel moet hebben. Maar als een detail heel fijn is, zoals iets hieronder op de afbeelding bij de adertjes in de vleugel, kan de browser die heel fijne details niet spontaan fabriceren. Omdat die hele fijne adertjes stomweg ontbreken in de afbeelding.

Je kunt dit probleem oplossen door alleen nog hogeresolutie-afbeeldingen te gebruiken. Maar daar maak je je niet populair mee, want dan downloadt een piepkleine smartphone een joekel van een afbeelding in superkwaliteit, geschikt voor een breedbeeldbeeldscherm .

De oplossing bestaat uit het gebruiken van meerdere afbeeldingen. Dat is iets meer werk, maar ook weer niet zoveel, omdat het om 'n vrij simpele handeling gaat, die je zelfs kunt automatiseren voor 'n hele serie afbeeldingen.

De afbeeldingen die eindigen op -2x.jpg hebben een afmeting van 960 x 720 px. De andere afbeeldingen hebben een afmeting van 480 x 360 px. Afgezien van de afmetingen, zijn ze verder precies hetzelfde. Als je nou een afbeelding van 960 px breed weergeeft op een breedte van 480 px, dan heb je opeens twee keer zoveel px op dezelfde ruimte. Oftewel: ongeveer dezelfde resolutie als een hogeresolutiescherm van 200 dpi.

Op de afbeelding hiernaast is het enige verschil tussen de afbeeldingen de afmeting. Als je ze niet zou vergroten of verkleinen, is de rechterafbeelding twee keer zo groot als de linker. De rechterafbeelding is echter wel verkleind, waardoor deze een hogere resolutie, meer dpi, heeft gekregen. Het verschil in kwaliteit is duidelijk zichtbaar: op de linkerafbeelding zijn de fijnere lijntjes binnen de vleugel stomweg afwezig. En wat niet aanwezig is, kan ook niet worden weergegeven door de browser, ook al doet deze nog zo haar best.

Voor een gewoon beeldscherm is de kwaliteit van de linkerafbeelding goed genoeg, want dat beeldscherm is toch niet in staat de fijne lijntjes weer te geven. Een hogeresolutiescherm kan dat wel.

Als je op een hogeresolutiescherm een afbeelding van 960 x 720 px en een afbeelding van 480 x 360 px naast elkaar op een breedte van 480 px bekijkt, zie je duidelijk verschil in kwaliteit. Beide afbeeldingen worden op een grootte van 480x360 px weergegeven, dus de grote afbeelding heeft in hoogte en breedte twee keer zoveel pixel ter beschikking en kan dus beter details weergeven. Die alleen op een hogeresolutiescherm te zien zijn, omdat een gewoon scherm stomweg te grof is om die details weer te geven. Het verschil in kwaliteit komt ruwweg overeen met het verschil in beide afbeeldingen iets hierboven.

Je kunt je afvragen, waarom dan niet altijd de beste kwaliteit afbeelding wordt gebruikt. Dat heeft te maken met de grootte van de bestanden. Elke pixel in een afbeelding is opgebouwd uit drie kleuren: rood, groen en blauw. Elk van die drie kleuren kan 256 mogelijke waarden hebben: van volledig ontbrekend tot volledig aanwezig (knalrood bijvoorbeeld). Samen kunnen deze drie kleuren op 256 x 256 x 256 = 16.777.216 manieren worden gecombineerd. Dat levert 16.777.216 mogelijke kleuren op, ruim voldoende voor het menselijk oog. Van volledig wit (drie keer nul) tot volledig zwart (drie keer 255. 255, want een computer begint bij nul te tellen).

Voor elke pixel in de afbeelding zijn drie bytes nodig: eentje voor elke kleur. Een afbeelding van 100 x 100 px heeft daardoor een bestandsgrootte van 3 x 100 x 100 = 30.000 byte, oftewel 30 kB (kilobyte).

Een afbeelding van 200 x 200 px, twee keer zo groot als een afbeelding van 100 x 100 px, heeft een bestandsgrootte van 3 x 200 x 200 = 120.000 byte, 120 kB. Dat is vier keer zoveel. En dat moet allemaal worden gedownload. Als de monitor toch niet in staat is die kwalitatief betere afbeelding goed weer te geven, is het zinloos die te downloaden en kun je beter de kwaliteit downloaden die bij de monitor past. Dat gaat (veel) sneller en is, als je moet betalen voor de bandbreedte, (veel) goedkoper.

(Als iemand dit nou gaat uitproberen met twee afbeeldingen, dan blijkt bovenstaande niet te kloppen. Door slimme compressiemethoden is een bestand uiteindelijk (veel) kleiner, dan je zou verwachten. Als je bijvoorbeeld een effen blauw vlak van 30 x 30 px hebt, is een regel als 'geef een blauw vlak weer van daar naar daar' veel efficiënter dan het opslaan van 30 x 30 x 3 = 2700 byte.)

In dit voorbeeld wordt met behulp van media query's opgevraagd, wat voor soort scherm de computer heeft. Als dat een hogeresolutiescherm is, wordt de grote afbeelding gedownload (en heel gedetailleerd twee keer verkleind weergegeven op een grootte van 480 x 360 px). Bij een gewoon beeldscherm wordt de kleinere afbeelding van 480 x 360 px gedownload.

Eigenlijk zou ook de achtergrond-afbeelding met de thumbnails op een hogeresolutiescherm twee keer zo groot moeten zijn als op een gewoon scherm. Ik heb dat niet gedaan, omdat het maar om 'n soort voorvertoning van de grote afbeelding gaat. Omdat die thumbnails zo klein zijn, kun je toch geen details zien, hoge resolutie of niet.

Als het browservenster tussen de 480 en 760 px breed is, worden de grote afbeeldingen met behulp van css breder dan 480 px weergegeven. Als je een afbeelding van 480 px gaat vergroten tot een breedte van meer dan 480 px, loop je tegen hetzelfde probleem aan als op een hogeresolutiescherm: er missen pixels. De browser probeert die weer aan te vullen, maar dat gaat niet echt heel goed. Om dit aanvullen te voorkomen, wordt bij een vensterbreedte tussen 480 en 760 px ook de grote afbeelding van 960 px breed gedownload. Die hoeft niet vergroot te worden. De afbeelding moet wel worden verkleind, maar dat gaat veel beter dan vergroten.

Voor smartphones met een venster van bijvoorbeeld slechts 320 px breed zou je nog 'n derde maat foto's kunnen opnemen, zodat daarvoor geen te brede afbeelding van 480 px breed wordt gedownload. Dat zou een kleinere bestandsgrootte opleveren, maar dat verschil in bestandsgrootte is hier zo klein, dat dat volgens mij de moeite van het extra werk niet waard is.

In de (niet al te verre?) toekomst kan de css trouwens 'n heel stuk worden ingekort, omdat je dan gelijk bij background-image zelf kunt opgeven, welke afbeelding moet worden gedownload. Hiervoor zijn dan geen media query's meer nodig. In één van de ontwerpspecificaties voor css wordt hiervoor image-set gebruikt, maar dit wordt helaas nog nauwelijks ondersteund door browsers.

Als je beslist image-set al wilt gebruiken, kun je op internet zoeken naar een zogenaamde 'polyfill' voor image-set. Een polyfill is een JavaScript dat zorgt dat een bepaalde eigenschap ook werkt in browsers die de eigenschap nog niet ondersteunen. Zo'n polyfill moet heel grondig getest worden, want er is nogal verschil in kwaliteit. Daarom beperk ik het gebruik van polyfills tot wat echt absoluut noodzakelijk is. En wordt er hier geen gebruik van gemaakt.

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, 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 inmiddels Blink, inclusief het daar nog in gebruikte -webkit-. Hierdoor is het tot voor kort door Opera gebruikte voorvoegsel -o- niet meer nodig.)

Internet Explorer: -ms-, naar de maker: Microsoft.

In dit voorbeeld worden -webkit-min-device-pixel-ratio en hyphens gebruikt.

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.

Tabindex

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

Normaal genomen wordt focus aangegeven door een kadertje rondom het element dat focus heeft. In het algemeen is het een bijzonder slecht idee om dat kadertje te verwijderen, omdat gebruikers van de Tab-toets dan niet meer kunnen zien, waar ze zijn aangekomen met de Tab-toets. Als je het kadertje verwijdert met behulp van css, moet je het daarom normaal genomen vervangen door iets anders. In dit geval heb ik het gewoon laten staan. Je zou het ook kunnen weghalen, want als met de Tab-toets een bepaalde thumbnail (eigenlijk een daarboven staande <div>) wordt bereikt, opent de bijbehorende grote afbeelding. Waardoor je dus prima kunt zien waar je bent.

In een vorige versie was dit kadertje weggehaald, maar de voornaamste reden daarvoor was het afschuwelijke onwijs dikke knalblauwe kadertje, waarmee Opera focus meende te moeten verontreinigen. Alle andere browsers hebben bescheidener kadertjes.

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 attribuut tabindex: <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.

Om :hover en :focus werkend te krijgen op iOS, is een minieme hoeveelheid JavaScript nodig. Meer daarover bij JavaScript.

De code aanpassen aan je eigen ontwerp

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

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

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

  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 natuurlijk ook een goed gratis programma gebruiken. Links naar dat soort programma's vind je op de pagina met links onder Gereedschap → wysiwyg-editor.

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

• 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 doctype voor html5 is uiterst simpel: <!DOCTYPE html>.

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

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

• Als tweede voer je de charset in. 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 ikzelf op test. Ook van Internet Explorer kun je meerdere versies naast elkaar draaien. Op de pagina met links staan onder de kopjes Gereedschap → Meerdere versies van Internet Explorer draaien en Gereedschap → Weergave testen 'n aantal links die daarbij kunnen helpen. De compatibiliteitsweergave in Internet Explorer is niet geschikt om te testen, omdat deze enigszins verschilt van de weergave in échte browsers.
• 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 enz., tot ze de juiste hoogte hebben. Het is handig om aan het einde even iets toe te voegen als 'laatste', zodat je zeker weet dat er niet 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 einde (en hier ook aan 't begin) 'n herkenningsteken te maken, zodat je zeker weet dat je de hele tekst ziet.

• Zolang je in grotere dingen zoals 'n lay-out aan 't wijzigen bent, zou ik je aanraden de verschillende delen een achtergrondkleur te geven. Je ziet dan goed, waar 'n deel precies staat. Een achtergrondkleur heeft – anders dan bijvoorbeeld een border – verder geen invloed op de lay-out, dus die is hier heel geschikt voor.
• Als je instellingen verandert in de style, 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 margin, padding en border bínnen de breedte en hoogte van de inhoud te zetten met behulp van box-sizing, als je dat handiger vindt.

• In plaats van een absolute eenheid als px kun je ook een relatieve eenheid gebruiken, met name em. Voordeel van em is dat een lettergrootte, regelhoogte, en dergelijke in em 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 vrijwel altijd beter dan vaste eenheden als px.

  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.

  Je kunt je css en html zowel valideren, als 't online staat, als wanneer 't nog in je computer staat.

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

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

  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.

  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.

Toegankelijkheid en zoekmachines

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

Toegankelijkheid (accessibility in het Engels) is belangrijk voor bijvoorbeeld blinden die een 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 bij een link niet duidelijk blijkt, 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.

  Voor mij redenen om accesskeys (vrijwel) niet te gebruiken. Ik kan me wel voorstellen dat ze op sites die gericht zijn op 'n specifieke groep gebruikers nog enig nut kunnen hebben, maar voor algemene sites zou ik zeggen: 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 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.

• 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 andere mogelijkheid is een zogenaamde skip-link: een link die je buiten het scherm parkeert met behulp van css, zodat hij normaal genomen niet te zien is. Zo'n link is wel zichtbaar in speciale programma's zoals tekstbrowsers en schermlezers, want die kijken gewoon naar wat er in de broncode staat.

  Zo'n link staat boven menu, header, en dergelijke en linkt naar de eigenlijke inhoud van de pagina, zodat mensen met één toetsaanslag naar de eigenlijke inhoud van de pagina kunnen gaan.

  Een skip-link is ook 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.

• 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. Zoekmachines zijn ook niet dol op een oerwoud van inline-stijlen (dat zijn stijlen in de tag zelf: <div style="...">.)

• Breng een logische structuur aan in je document. Gebruik een <h1> voor de belangrijkste kop, een <h2> voor een subkop, enz. 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 'n lagere plaats in een zoekmachine.

• Frames zijn 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 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 of SSI. Dan wordt de pagina niet 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.

• Geef de taal van het document aan, en bij woorden en dergelijke die afwijken van die taal de afwijkende taal met behulp van lang="..". Ik doe dat op mijn eigen site maar af en toe, omdat de tekst (en vooral de code) een mengsel is van Engels, Nederlands en eigengemaakte namen. Dit soort teksten is gewoon niet goed in te delen in een taal. 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.

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

  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.

• Ten slotte kun je je pagina nog online laten controleren op 'n behoorlijk aantal sites. Ik noem er hier enkele.

  toptal.com/designers/colorfilter Laat zien hoe een kleurenblinde de site ziet. Engelstalig.

  wave.webaim.org Deze laat grafisch zien hoe de toegankelijkheid is. Engelstalig.

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

Specifiek voor dit voorbeeld

• Voor iOS is een minieme hoeveelheid JavaScript nodig, anders worden de grote afbeeldingen daar niet getoond. Dat zal geen probleem zijn, want een iPad en dergelijke waarin JavaScript uit staat, is weinig meer dan een duur en groot uitgevallen horloge. Verder is JavaScript nergens nodig.
• Door het toevoegen van tabindex="0" aan elke <div> boven een thumbnail, kunnen de grote foto's ook worden geopend door gebruikers van de Tab-toets.
• Als na deze constructie elders op de pagina nog tekst of zo staat, is het goed een zogenaamde skip-link aan te brengen, zodat mensen in één keer deze hele constructie kunnen passeren. Gebruikers van de Tab-toets hoeven dan niet 36 keer de Tab-toets in te drukken om eerst alle afbeeldingen en dergelijke te passeren.
• De <span>'s met de onderschriften zijn niet verborgen met display: none;, maar links buiten het scherm geparkeerd. Hierdoor worden ze gewoon voorgelezen door schermlezers, ook al zijn ze niet zichtbaar op het scherm.

• In een tekstbrowser zoals Lynx zie je – om voor de hand liggende redenen – geen afbeeldingen. Alleen de tekst rechts van de thumbnails, de onderschriften bij de grote afbeeldingen en de links rechtsonder de thumbnails zijn zichtbaar.

  Dit geldt ook voor schermlezers, maar hier worden ook de volgnummers op de thumbnails voorgelezen.

• Zonder css zie je alleen de tekst rechts van de thumbnails, de onderschriften onder de grote afbeeldingen en de links rechtsonder de thumbnails.

Getest in

Laatst gecontroleerd op 18 oktober 2015.

Onder dit kopje staat alleen maar, hoe en waarin is getest. Eventuele problemen, ook die met betrekking tot zoomen en lettergroottes, staan 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!

Eventuele opmerkingen over de toegankelijkheid specifiek voor dit voorbeeld staan hierboven bij Toegankelijkheid en zoekmachines onder het kopje Specifiek voor dit voorbeeld.

Dit voorbeeld is getest op de volgende systemen:

• Windows 7:
  Firefox, UC Browser, Google Chrome, Internet Explorer 9 en 10, in meerdere resoluties.
• Windows 8.1:
  Bureaublad-versie: Firefox, UC Browser, Google Chrome en Internet Explorer 11, in meerdere resoluties.
  Startscherm-versie: Internet Explorer 11.
• OS X:
  Firefox, Safari en Google Chrome, in meerdere resoluties. In Safari is, voor zover relevant, ook de Reader-weergave getest.
• Linux:
  Firefox en Google Chrome, in meerdere resoluties.
• Windows Phone 8.1 in een resolutie van 800x480 (Nokia Lumia 520):
  Internet Explorer (portret en landschap).
  UC Browser (portret en landschap).
• iPad met iOS 9.0.2 in een resolutie van 1024x768 (device-pixel-ratio: 1)(MC979NF):
  Safari (portret en landschap, voor zover relevant ook de reader-weergave).
  Chrome for iOS (portret en landschap).
  UC Browser (portret en landschap).
• iPad Air met iOS 9.0.2 in een resolutie van 2048 x 1536 (retina, device-pixel-ratio: 2) (MD785HC/B):
  Safari (portret en landschap, voor zover relevant ook de reader-weergave).
  Chrome for iOS (portret en landschap).
  UC Browser (portret en landschap).
• Android 4.1.2 in een resolutie van 800x480 (Samsung Galaxy Core i8620):
  Chrome, Android browser, UC Browser en Firefox (alle portret en landschap).
• Android 4.4.2 in een resolutie van 1280x800 (resolutie: 90-99 dpi) (Samsung Galaxy Tab 3 GT-P521):
  Android browser, UC Browser, Firefox en Chrome (alle portret en landschap).
• Android 4.4.2 in een resolutie van 2560x1600 (hoge resolutie: 190-199 dpi) (Samsung Galaxy Tab PRO (T520):
  Android browser, UC Browser, Firefox en Chrome (alle portret en landschap).

Er is steeds getest met de laatste versie van de browsers op de aan het begin van dit hoofdstukje genoemde controledatum, omdat ik geen zin heb om rekening te houden met mensen die met zwaar verouderde browsers surfen. Dat is trouwens vragen om ellende, want updates van browsers hebben heel vaak met beveiligingsproblemen te maken.

Ook op Windows XP kunnen mensen surfen met Firefox, Opera of Google Chrome, dus ook daar zijn mensen niet afhankelijk van Internet Explorer 8. Ik maak één uitzondering: Android browser. Omdat Android vaak niet geüpdatet kan worden, test ik ook nog in oudere versies van Android browser.

In resoluties groter dan 800x600 is ook in- en uitzoomen en – voor zover de browser dat kan – een kleinere en grotere letter 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 de iPad, Android en Windows Phone, waar een touchscreen is gebruikt. Op Windows 8.1 is getest met een touchscreen, met een combinatie van toetsenbord en touchpad, en met een combinatie van toetsenbord en muis.

Op de desktop is ook getest, als JavaScript uitstaat. Eventuele problemen staan hierboven bij Toegankelijkheid en zoekmachines onder het kopje Specifiek voor dit voorbeeld. (Op iOS, Android en Windows Phone 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.)

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

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

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

TalkBack is een in Android ingebouwde schermlezer. Er is getest in combinatie met Chrome.

VoiceOver is een in iOS en OS X ingebouwde schermlezer. Er is getest in combinatie met Safari op iOS en OSX.

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 opmerkingen over de toegankelijkheid specifiek voor dit voorbeeld staan hierboven bij Toegankelijkheid en zoekmachines onder het kopje Specifiek voor dit voorbeeld.

Alleen op de hierboven genoemde systemen en browsers is getest. Er is dus niet getest op bijvoorbeeld 'n Blackberry. De kans is (heel erg) groot dat dit voorbeeld niet (volledig) werkt op niet-geteste systemen en apparaten. Om het wel (volledig) werkend te krijgen, zul je vaak (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 Android browser 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 eigenlijk 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 test ik pas, als ze uit het bèta-stadium zijn, omdat er anders 'n redelijke kans is dat ik 'n bug zit te omzeilen, die voor de uiteindelijke versie nog gerepareerd wordt. Dit voorbeeld is alleen getest in de hierboven met name genoemde browsers. Vragen over niet-geteste browsers kan ik niet beantwoorden, en het melden van fouten in niet-geteste browsers heeft ook geen enkel nut. (Melden van fouten, problemen, enz. in wel geteste browsers: graag!)

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.

Wijzigingen

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

26 december 2007:

Nieuw opgenomen.

12 augustus 2011:

De code is volledig herschreven. De zichtbare gevolgen daarvan:

• Alle eerdere wijzigingen weggehaald, want die zijn niet meer van toepassing.
• Dit voorbeeld is op geen enkele manier meer getest in Internet Explorer 6.
• De Tab-toets werkt nu ook in Safari en Google Chrome.
• De nummers boven de thumbs zijn duidelijker.
• De thumb die focus heeft wordt gemarkeerd.
• De css is tot ongeveer de helft teruggebracht (voor het een groot deel doordat Internet Explorer 6 wordt genegeerd).
• Ongeacht welke link focus heeft en welke grote afbeelding zichtbaar is, hoveren 'wint' altijd van focus.
• Achtergrondkleur van de links rechtsonder veranderd, zodat het contrast nu voldoet aan de vereisten voor toegankelijkheid van de WCAG.

18 oktober 2015

• Alleen de hele grote aanpassingen staan hier, anders is er geen beginnen aan.
• Alle aanpassingen en dergelijke voor Internet Explorer 7 en 8 verwijderd. In deze browsers wordt niet meer getest.
• Alle aanpassingen en dergelijke voor Opera verwijderd. Opera gebruikt inmiddels dezelfde weergave-machine als Google Chrome, waarmee apart testen – mede gezien het uiterst geringe gebruik – redelijk nutteloos is geworden.
• Werkt nu ook op touchscreens.
• Voor hogeresolutieschermen zijn grotere afbeeldingen toegevoegd.
• Tig kleinere aanpassingen in de tekst. Er zijn enkele nieuwe hoofdstukken toegevoegd, voornamelijk over touchscreens en hogeresolutieschermen.
• De 34 thumbnails zijn samengevoegd tot één grote achtergrond-afbeelding.
• Omdat oudere versies van Internet Explorer niet meer worden ondersteund, hoefden thumbnails, bijbehorende grote afbeelding, enz. niet meer in een <a> te staan. Alles staat nu in gewone <div>'s en <span>'s.
• De volgnummers op de thumbnails zijn niet meer hard gecodeerd in de html, maar worden gegenereerd met behulp van counter.
• Omdat de thumbs en dergelijke niet meer in 'n <a> staan, is de achter die <a> liggende pagina niet meer aanwezig. Dat was eigenlijk 'n soort extraatje, omdat het vanwege Internet Explorer nou eenmaal toch in 'n <a> moest staan.

11 maart 2020:

Ook background-images worden nu meestal, net als gewone <img>’s, gelijk bij openen van de pagina gedownload. Bovenaan Achterliggend idee is een korte correctie toegevoegd.

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

afbeelding-016-dl.html: de pagina met het voorbeeld.

afbeelding-016.pdf: deze uitleg (aangepast aan de inhoud van de download).

afbeelding-016-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:

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, enz., 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. Als je op internet zoekt naar 'css' en 'compress' of 'comprimeren', vind je tal van sites, waar je dat automatisch kunt laten doen.

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

css voor alle vensters

/* afbeelding-016-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.

counter-reset: volgnummer;

Voor het nummeren van de thumbnails wordt een zogenaamde css-counter, een teller, gebruikt. Bij elke <div> boven een thumbnail wordt die teller met 1 verhoogd, waarna dat nummer op de thumb wordt gezet.

Met behulp van counter-reset wordt de beginstand van de teller opgegeven. Als nog geen teller met de hier gebruikte naam bestaat, zoals hier het geval is, wordt deze aangemaakt. Dat gebeurt hier: de teller krijgt de fantastisch creatieve naam 'volgnummer'.

Je kunt ook een beginwaarde aangeven. Omdat hier alleen een naam en geen beginwaarde is opgegeven, begint de teller bij 0. Bij de eerste <div> wordt die dan verhoogd tot 1, waarna die 1 wordt getoond. Bij de tweede <div> wordt het 2, enz.

background: #002;

Donkerblauwe achtergrondkleur.

Normaal genomen zou ik bij een achtergrondkleur ook altijd color opgeven. Dat bepaalt de voorgrondkleur, waaronder de tekstkleur. Sommige mensen hebben zelf de kleur en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

In dit geval doe ik dat niet, omdat op deze pagina alleen tekst staat in elementen die zelf al een achtergrond- en voorgrondkleur krijgen. Waarmee het risico op te weinig contrast dus niet bestaat op deze pagina.

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

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

font-size: 110%;

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

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;

Verschillende browsers hebben verschillende standaard-instellingen hiervoor. Door ze gewoon op 0 te zetten, zijn ze overal hetzelfde.

#inleiding

Het element met id="inleiding". De <div> waarin de tekst staat, die wordt getoond in browservensters met een minimale breedte van 760 px.

display: none;

Verbergen. In vensters met een minimale breedte van 760 px wordt hij later weer zichtbaar gemaakt.

#thumbs

Het element met id="thumbs". De <div> waar, op div#inleiding na, alles in zit.

background: url(../016-pics/thumbnails.jpg);

Achtergrond-afbeelding met de thumbnails.

In een vorige versie, waarin oudere versies van Internet Explorer nog werden ondersteund, was er niet één achtergrond-afbeelding, maar waren er 34 afzonderlijke kleine thumbnails. Waarvoor 34 aanroepen naar de server nodig waren.

Door de thumbnails te monteren op één grote achtergrond-afbeelding, is nu nog maar één aanroep naar de server nodig, wat veel sneller werkt. Bovendien zijn de randjes rondom de thumbnails ook al aanwezig: dat is gewoon de achtergrondkleur van de achtergrond-afbeelding, die zichtbaar is door de kiertjes tussen thumbnails.

width: 245px; height: 450px;

Breedte en hoogte van deze <div> zijn precies hetzelfde als de afmetingen van de achtergrond-afbeelding.

Normaal genomen wordt een blok-element zoals een <div> even breed als z'n ouder. Dat is hier <body>. En normaal genomen wordt een <div> automatisch precies hoog genoeg, om de inhoud ervan weer te kunnen geven. Soms is dat is echter niet zo, bijvoorbeeld als die inhoud wordt gefloat.

Binnen div#thumbs staan vier <div>'s, voor elke kolom met thumbnails eentje. Deze vier <div>'s worden naar links gefloat. Hierdoor krijgt div#thumbs geen breedte en hoogte. En zonder breedte en hoogte zou je niets van de achtergrond-afbeelding zien,

want een achtergrond-afbeelding heeft zelf geen hoogte en breedte. Die vult alleen maar het element waar de achtergrond-afbeelding in zit.

Op de afbeelding zijn breedte en hoogte weggelaten. Alles werkt nog steeds, de nummering van de thumbnails is aanwezig, enz. Maar omdat #thumbs geen breedte en hoogte heeft, ontbreekt de achtergrond-afbeelding. Wat het mogelijk 'n tikkeltje lastig maakt om te kiezen, welke grote afbeelding je wilt zien. Daarom worden breedte en hoogte in dit geval handmatig opgegeven. Dan heeft de <div> een breedte en hoogte en kan de achtergrond-afbeelding worden getoond.

margin: 6px 0 0 6px;

Kleine afstand tot de zijkant van het browservenster aan boven- en linkerkant.

#thumbs > div

De <div>'s binnen het element met id="thumbs". Dit zijn de vier <div>'s waarbinnen de vier kolommen boven de thumbnails staan.

Er staan meer <div>'s binnen #thumbs. Boven elke thumbnail staat ook weer een eigen <div>. Deze css heeft alleen betrekking op de vier <div>'s met de kolommen. Daarom wordt aan de selector het teken > toegevoegd. Nu geldt deze regel alleen voor <div>'s die een direct kind van #thumbs zijn, niet voor dieper geneste <div>'s.

Onderstaande (sterk ingekorte) html hoort bij de vierde kolom:

<div id="thumbs"> <div> <div id="thumb-27" tabindex="0"> (...) <div id="thumb-34" tabindex="0"> (...) </div> </div>

De css bij deze selector geldt wel voor de <div> die gelijk onder <div id="thumbs"> staat, want dat is een direct kind van div#thumbs. Maar niet voor div#thumb-27 en div#thumb-34, want die zijn geen directe kinderen van div#thumbs.

float: left;

Zo hoog mogelijk en zo ver mogelijk naar links neerzetten.

Normaal genomen wordt een <div> op een nieuwe regel gezet. Daardoor zouden de vier <div>'s met kolommen niet onder, maar naast elkaar komen te staan. Door ze naar links te floaten, komen ze naast elkaar te staan.

width: 60px;

Met deze breedte zijn ze precies even breed als een thumbnail.

height: 450px;

Met deze hoogte bestrijken ze precies een kolom met thumbnails.

margin-left: 1px;

Tussen de op de achtergrond-afbeelding gemonteerde thumbnails zit een kier van 1 px, waardoor de achtergrondkleur van de achtergrond-afbeelding zichtbaar is. Door links een marge van 1 px te geven, komen de kolommen niet boven deze kier te staan.

Je zou de <div>'s ook 1 px breder kunnen maken, dan staan ze ook op de goede plaats. Maar binnen deze vier <div>'s voor de kolommen komen de <div>'s die bij de thumbnails horen. Als je over één van die <div>'s hovert, openen de bijbehorende grote afbeelding en onderschrift. Die <div>'s worden even breed als de <div> voor de kolom, waar ze in zitten.

Als je de <div> voor de kolom 61 px breed maakt, wordt ook de bij de thumbnail horende <div> 61 px breed. Daardoor zou hoveren ook werken boven de kier tussen de thumbnails. Als je in plaats daarvan de breedte 60 px maakt en een marge van 1 px gebruikt, werkt hoveren boven de kier tussen de thumbnails niet, omdat hoveren niet werkt boven een marge.

Het gaat hier maar om een kier van 1 px, maar het is een goede gewoonte dingen enigszins op dezelfde manier te doen, zodat het een soort automatisme is. Bij een kier van 10 px zou het wel verwarrend zijn, als hoveren over die kier een grote afbeelding opent.

div[id^="thumb-"]

Als deze selector in stukjes wordt gehakt, wordt het wat minder ingewikkeld, dan het mogelijk op het eerste oog lijkt. De css bij deze selector moet voor alle 34 <div>' boven een thumbnail gelden, maar niet voor andere <div>'s. Je zou die 34 <div>'s een class kunnen geven, maar dit werkt ook.

div: alle <div>'s. Maar omdat er nog wat achteraan komt, geldt dit toch niet voor álle <div>'s.

[]: als een element een bepaalde eigenschap, attribuut, id, of zoiets moet hebben, geef je dat aan door die eigenschap, attribuut, id, en dergelijke tussen twee teksthaken te zetten.

id="thumb-": (de ^ voor de = komt gelijk hieronder aan de beurt). Tussen de twee teksthaken staat deze voorwaarde. Daarom geldt deze selector alleen voor een <div> met id="thumb-". Uiteraard zou je dan simpeler gewoon #thumb- of div#thumb- kunnen gebruiken, want er is maar één element met deze id op de pagina. En hier komt de ^ om de hoek kijken:

id^="thumb-": voor de = staat een ^. Alleen een = wil zeggen: precies gelijk aan. Maar de combinatie ^= geeft aan, dat de id alleen moet beginnen met 'thumb-'. Er mag van alles op volgen. Dat komt goed uit, want de 34 <div>'s die bereikt moeten worden, hebben allemaal als begin van hun id 'thumb-', gevolgd door een eigen volgnummer. Maar ook id='thumb-sinterklaas' of 'thumb-o-wat-is-mijn-grote-teen-toch-mooi' voldoen aan deze selector.

div[id^="thumb-"]: de hele selector in normale taal: <div>'s die een id hebben die begint met 'thumb-'.

height: 45px;

De thumbnails zijn 45 px hoog. De bijbehorende <div> krijgt dezelfde hoogte.

Een breedte hoeft niet opgegeven te worden, want normaal genomen wordt een blok-element zoals een <div> automatisch even breed als z'n ouder. Dat is hier één van de <div>'s voor de kolommen, die bij #thumbs > div een breedte van 60 px hebben gekregen. Daardoor krijgen deze <div>'s diezelfde breedte: even breed als de thumbnails.

margin-top: 1px;

Tussen de thumbnails zit een kier van 1 px, waardoor de achtergrondkleur van de achtergrond-afbeelding zichtbaar is. Door aan de bovenkant een marge van 1 px te geven, komen de <div>'s niet boven deze kier te staan.

Je zou de <div>'s ook 1 px hoger kunnen maken, dan staan ze ook op de goede plaats. Maar als je over een van de <div>'s hovert, openen de bijbehorende grote afbeelding en onderschrift. Zou je de <div>'s 46 px hoog maken, dan staan ze wel op de goede plaats, maar dan werkt hoveren ook boven die kier. Als je in plaats daarvan de hoogte 45 px maakt en een marge van 1 px gebruikt, werkt hoveren boven de kier tussen de thumbnails niet, omdat hoveren niet werkt boven een marge.

Het gaat hier maar om een kier van 1 px, maar het is een goede gewoonte dingen enigszins op dezelfde manier te doen, zodat het een soort automatisme is. Bij een kier van 10 px zou het wel verwarrend zijn, als hoveren over die kier een grote afbeelding opent.

div[id^="thumb-"]::before

div[id^="thumb-"]: alle <div>'s die een id hebben die begint met 'thumb-'. Dat zijn de 34 <div>'s boven de thumbnails. Hoe dit deel van de selector precies werkt, wordt iets hierboven bij div[id^="thumb-"] besproken.

Met behulp van ::before wordt bij de <div>'s een pseudo-element gemaakt, waarmee het volgnummer van de thumbnail op de thumb wordt gezet.

content: counter(volgnummer);

De inhoud van het met behulp van ::before aangemaakte pseudo-element. Dat is hier een teller ('counter') met de naam 'volgnummer'. Die teller moet al zijn aangemaakt, voor hij kan worden gebruikt. Dat is bij body gebeurd met counter-reset: volgnummer;.

counter-increment: volgnummer;

Verhoog de teller met de naam 'volgnummer'. Omdat geen waarde is opgegeven, waarmee verhoogd moet worden, wordt met 1 verhoogd. Bij het aanmaken van de teller heeft deze de waarde 0 gekregen. Bij de eerste <div> wordt dit veranderd in 1, bij de tweede <div> in 2, enz.

background: rgba(0, 0, 0, 0.3);

Meestal wordt voor 'n kleur de hexadecimale notatie gebruikt, iets als color: #33ab01;. Daarbij worden niet alleen cijfers, maar ook letters gebruikt. 0 tot en met 9 werken precies hetzelfde als altijd, maar na de 9 komen nog A, B, C, D, E en F.

Als je telt, is 't dus: 0 1 2 3 4 5 6 7 8 9 A B C D E F 10 11 12, enz. Daarbij is A gelijk aan het tientallige 10, B aan 11, enz. Op deze manier kun je met twee cijfers en/of letters 256 mogelijkheden aangeven: van 00 tot en met FF.

De eerste drie getallen bij rgba() geven de kleur aan. Deze lopen van 0 tot en met 255, dus ook hiermee kun je 256 mogelijkheden aangeven. En omdat er drie getallen zijn levert dat 256 x 256 x 256 = 16.777.216 mogelijke kleuren op, net iets meer dan het aantal kleurpotloden in de gemiddelde kleurdoos van 'n kind.

De notatie bij rgba() geeft dus precies evenveel mogelijkheden als de hexadecimale.

Het eerste getal staat voor rood, het tweede voor groen en het derde voor blauw (feitelijk de Engelse namen, maar de eerste letter is toevallig in het Nederlands hetzelfde). Uit deze drie kleuren zijn alle kleuren op een monitor opgebouwd.

255 wil zeggen volledig aanwezig, 0 wil zeggen helemaal ontbrekend.

255, 255, 255 levert wit op, 0 , 0 , 0 zwart.

In plaats van getallen mag je ook percentages gebruiken, bijvoorbeeld: rgba(10%, 20%, 100%, 0.3).

Omdat in dit voorbeeld drie keer 0 is opgegeven, levert dit een zwarte kleur op.

Het vierde getal staat voor het alfa-kanaal. Hiermee wordt de doorzichtigheid aangegeven. Dit getal loopt van 0 naar 1. Volledig doorzichtig is 0, volledig ondoorzichtig is 1.

Het getal voor het alfa-kanaal wordt als decimale breuk aangegeven, dus bijvoorbeeld 0.5 wil zeggen halfdoorzichtig. Let erop dat je 'n punt gebruikt, de Amerikaanse manier om breuken aan te geven. Als je 'n komma gebruikt, denkt de browser dat er twee verschillende getallen staan.

In dit voorbeeld is deze achtergrondkleur behoorlijk doorzichtig: 0.3. Hierdoor zie je de thumbs nog enigszins door de achtergrond heen, maar zijn de volgnummers toch altijd goed zichtbaar, ook op lichtere thumbs.

color: #ffffcf;

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

border-radius: 4px;

Ronde hoekjes. Er is hier geen border, maar dit werkt ook voor de achtergrondkleur.

padding: 0 2px;

Omdat voor onder en links geen waarde is opgegeven, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 0 2px 0 2px in de volgorde boven – rechts – onder – links. Boven en onder geen padding, links en rechts 2 px.

De achtergrondkleur loopt door onder de padding. Een klein beetje achtergrondkleur rondom de getallen voorkomt dat een getal moeilijk zichtbaar wordt, doordat het precies aan een lichter stukje van de thumbnail grenst. 2 px links en rechts is voldoende.

Boven en onder is geen padding nodig, omdat de regelhoogte toch al altijd iets hoger is dan de tekst, dus daar is al wat achtergrondkleur aanwezig.

div.staand

Voor deze elementen geldt ook de eerder bij div[id^="thumb-"] opgegeven css, voor zover die hier niet wordt gewijzigd.

De <div>'s met class="staand". Dit zijn de twee <div>'s die boven een staande thumbnail zitten.

height: 80px;

De staande thumbnails zijn 80 px hoog, dus deze <div>'s moeten ook die hoogte krijgen.

.foto

De elementen met class="foto". De <span>'s waarbinnen de grote afbeelding zit.

background-color: rgba(100, 100, 100, 0.9);

Achtergrondkleur. Een uitleg over rgba() is te vinden bij background: rgba(0, 0, 0, 0.3);.

Drie keer het getal 100 levert een gemiddeld grijs op. Een doorzichtigheid van 0.9 laat de grote afbeelding duidelijk uitkomen, terwijl de thumbnails nog 'n heel klein beetje door de achtergrond heen te zien zijn.

Deze achtergrondkleur wordt alleen gebruikt in kleinere browservensters, waar de grote afbeelding bij gebrek aan ruimte boven de thumbnails wordt gezet. Als de thumbnails duidelijk zichtbaar zouden blijven, is dat heel storend.

background-position: 50%;

De grote afbeelding is een achtergrond-afbeelding. Deze moet zowel horizontaal als verticaal in het midden van de <span> worden gezet. Omdat de <span> zelf in kleinere browservensters het hele venster vult, staat de afbeelding hierdoor altijd midden in het venster.

background-repeat: no-repeat;

Een achtergrond-afbeelding wordt normaal genomen herhaald, tot de hele achtergrond van het element is gevuld. Hoewel hier heel mooie foto's bij zitten, is één foto toch wel genoeg.

background-size: contain;

Een van de nieuwere css-eigenschappen.

Een afbeelding heeft een bepaalde verhouding. Bij de hier gebruikte afbeeldingen is die 4 x 3 (bij de staande 3 x 4): de breedte is een derde meer dan de hoogte. 480 px breed, 360 px hoog (de staande 360 px breed en 480 px hoog).

De maten van het venster van de browser hebben hoogst waarschijnlijk niet precies dezelfde verhouding. Als je de afbeelding gewoon het venster zou laten vullen, zou de hoogte daardoor meer of minder toe‑ of afnemen dan de breedte. Wat een lachspiegeleffect zou opleveren, of er zouden delen van de afbeelding wegvallen.

Deze eigenschap zorgt ervoor dat de afbeelding zo groot mogelijk wordt weergegeven, maar zonder vervorming. Zodra de hoogte óf de breedte niet meer past, wordt de afbeelding niet verder vergroot, waardoor vervorming wordt voorkomen.

Op de afbeelding staat twee keer dezelfde afbeelding in twee keer een venster van dezelfde grootte met vrijwel dezelfde css. Rechts staat de afbeelding, zoals die hoort te zijn. Links is alleen background-size: contain; weggelaten, wat een veel grotere bij (hommel?) oplevert, maar het arme beestje is wel de helft van z'n vleugels en voelsprieten kwijtgeraakt, want die pasten niet meer in het venster.

display: none;

De <span>'s verbergen. Zodra dat nodig is, worden ze zichtbaar gemaakt.

pointer-events: none;

Deze css-eigenschap moet niet worden verward met pointer-events uit JavaScript, die iets heel anders zijn.

Dit is nodig voor Internet Explorer 11 op een touchscreen en UC browser op Windows Phone. Deze browsers gaan zich uiterst vreemd gedragen, als op een touchscreen een <span> wordt geopend, die eerst met display: none; was verborgen. Maar alleen als in die <span> een afbeelding zit. En dat is precies wat hier het geval is bij span.foto.

Als je het scherm aanraakt op de plaats waar, na opening, de <span> met de afbeelding komt te staan, verschijnt de afbeelding in Internet Explorer 11 pas na een langdurige aanraking. In UC browser op Windows Phone verschijnt de afbeelding helemaal niet. Als je het scherm buiten die plaats aanraakt, werkt het normaal en blijven de afbeeldingen gelijk geopend.

Hetzelfde geldt bij aanraking op de plaats waar, na opening, de <span> met het onderschrift komt te staan. Dat de <span> met de afbeelding met display: none; is verborgen en dat de <span> met het onderschrift links buiten het scherm zijn geparkeerd, voorkomt dit vreemde gedrag niet. Terwijl in beide gevallen de <span> gewoon afwezig hoort te zijn en dus ook geen invloed zou moeten hebben.

Deze eigenschap voorkomt deze vreemde bug. Het zorgt ervoor dat een klik, een aanraking, hoveren, en dergelijke boven .foto volledig worden genegeerd, maar worden doorgegeven aan het onder .foto liggende element. Als je een geopende grote foto of een geopend onderschrift boven de thumbnails aanraakt, kun je dit goed zien: de bij de aangeraakte thumbnail horende grote afbeelding opent. Zonder pointer-events: none; zou de aanraking, klik, hover en dergelijke de onder de grote afbeelding liggende thumbnail niet bereiken, maar worden afgevangen door span.foto of span.tekst.

Dat is ook waar deze eigenschap voor is bedoeld: zorgen dat 'n element hoveren en dergelijke negeert. Normaal genomen zou ik hem niet gebruiken hier, maar het neutraliseert op wonderbaarlijke wijze deze bug.

position: fixed;

De positie van de <span> koppelen aan het venster van de browser. De afbeeldingen worden altijd op dezelfde plaats getoond, ook als wordt gescrold.

Dit is van belang in lage vensters. Als je daarin de thumbnails naar boven scrolt, omdat ze niet allemaal zichtbaar zijn, zou de afbeelding bij gebruik van bijvoorbeeld position: absolute; in plaats van position: fixed; te hoog worden neergezet. Waardoor aan de bovenkant een deel van de afbeelding wegvalt, zoals op de afbeelding is te zien.

De <span> waarin de achtergrond-afbeelding staat, is verder helemaal leeg. Daarom heeft die <span> geen grootte. En is er dus ook geen achtergrond om te vullen met een achtergrond-afbeelding. Daarom wordt hieronder met behulp van top, right, bottom en left een grootte aan de <span> gegeven.

top: 0; right: 0;

Altijd aan de boven- en rechterkant van het browservenster neerzetten.

Het gaat hier om de positie van de <span>. De afbeelding zelf is een achtergrond-afbeelding, die iets hoger met background-position: 50%; horizontaal en verticaal binnen deze <span> is gecentreerd. Ook als de <span> breder of hoger is dan de afbeelding, komt de afbeelding hierdoor toch altijd in het midden te staan.

bottom: 3rem;

Aan de onderkant van de <span> met de grote foto moet ruimte blijven voor een onderschrift.

In hogere browservensters is dat geen probleem, omdat er dan altijd wel ruimte aan de onderkant leeg blijft. Maar in lagere vensters bestaat de kans, dat een deel van de grote afbeelding onder het onderschrift komt te staan en daardoor niet te zien is, zoals op de linkerafbeelding.

Daarom wordt aan de onderkant van de <span> een ruimte van 3 rem vrijgelaten. Dat betekent wel, dat in deze ruimte ook geen achtergrondkleur is, waardoor de thumbnails in deze ruimte hinderlijk zichtbaar zouden zijn. Want het onderschrift vult niet in alle maten vensters deze ruimte volledig. Dit probleem wordt gelijk hieronder bij .foto::after opgelost.

Als eenheid is rem gebruikt, een tamelijk onbekende eenheid. De afkorting rem staat voor root em: de relatieve eenheid em, maar dan ten opzichte van de 'root', de basis van het document. Bij een pagina op een site is de 'root' altijd het <html>-element.

De grootte van een em is gebaseerd op de lettergrootte. Bij een grotere lettergrootte is de em groter dan bij een kleinere lettergrootte. Een normale em is afhankelijk van al z'n voorouders. Als een van die voorouders de lettergrootte vergroot of verkleint, geldt dat ook voor de nakomelingen van die voorouder.

De rem is altijd ten opzichte van de lettergrootte in <html>, ongeacht wat de voorouders van het element er onderweg van <html> naar het uiteindelijke element mee hebben gedaan.

De hoogte van de <span> met het onderschrift is ook 3 rem. Omdat hier hetzelfde voor geldt, zijn de lege ruimte onder de <span> en de hoogte van de <span> met het onderschrift altijd hetzelfde, ongeacht wat er in welke voorouder dan ook met de lettergrootte is gebeurd.

De tekst van de onderschriften paste in kleinere browservensters niet binnen de <span> die daarvoor was bedoeld. Daarom is de lettergrootte verkleind tot 0,75 em. Als voor de hoogte van de <span> voor de onderschriften em was gebruikt als eenheid, zou die hoogte mee veranderen en niet meer hetzelfde zijn als de ruimte onder de grote afbeelding.

Door voor de hoogte rem te gebruiken, kan de lettergrootte van het onderschrift worden veranderd, terwijl de hoogte toch hetzelfde blijft, want die is nu gebaseerd op de grootte van de em bij de root, bij <html>. En is dus nog even groot als de lege ruimte onder de grote afbeelding.

Je zou ook een eenheid als px kunnen gebruiken voor de hoogte van de <span> met de tekst en de ruimte onder de afbeelding. Maar een px is een absolute eenheid. De rem is een relatieve eenheid. Als het browservenster kleiner is, zoals op een smartphone, is de rem kleiner dan in een groter venster, zoals een desktop. En als de gebruiker de lettergrootte in de browser aanpast, verandert de rem mee. Een grotere letter levert een grotere rem op, terwijl een px voor de hoogte gewoon een px blijft en niet mee verandert.

left: 0;

De <span> helemaal aan de linkerkant van het venster van de browser laten beginnen.

.foto::after

Met behulp van ::after wordt bij de elementen met class="foto" – dat zijn de <span>'s met de grote afbeelding – een pseudo-element gemaakt, waarmee een mogelijke kier onder het onderschrift wordt gedicht.

De <span> met de grote afbeelding heeft bij .foto een grijze achtergrond gekregen, die de thumbnails afdekt. Onder de <span> is ruimte vrijgelaten voor een onderschrift. Dat onderschrift staat echter, afhankelijk van de maat van het venster van de browser, niet altijd precies in die vrijgelaten ruimte. Op de afbeelding staat het in een tamelijk smal en hoog venster gelijk onder de grote afbeelding, waarbij onder het onderschrift de thumbnails hinderlijk zichtbaar blijven.

Dit pseudo-element is bedoeld om die ruimte te vullen met dezelfde achtergrondkleur als de rest van het venster.

(Het op de afbeelding gebruikte venster is opzettelijk héél smal gemaakt. Normaal genomen zul je niet snel in een venster van deze afmeting foto's gaan bekijken.)

content: "";

Ook als er geen tekst of zo in het met behulp van ::after pseudo-element staat, moet content worden gebruikt. Dat er verder niets in staat, geef je aan door de ruimte tussen de aanhalingstekens leeg te laten.

background: rgba(100, 100, 100, 0.9);

Achtergrondkleur. Een uitleg over rgba() is te vinden bij background: rgba(0, 0, 0, 0.3);. Drie keer het getal 100 levert een gemiddeld grijs op. Een doorzichtigheid van 0.9 laat de grote afbeelding duidelijk uitkomen, terwijl de thumbnails nog 'n heel klein beetje door de achtergrond heen te zien zijn. Dit is dezelfde achtergrondkleur als de <span> met de grote afbeelding bij .foto heeft gekregen.

width: 100%;

Volle breedte van het venster van de browser vullen.

Een breedte in procenten wordt altijd genomen ten opzichte van de ouder van het element. Dit pseudo-element hoort bij de <span> met de grote afbeelding. Die <span> vult de volle breedte van het venster, dus dit pseudo-element ook.

height: 200px;

Hieronder bij bottom: -200px; wordt het pseudo-element 200 px beneden de <span> met de grote afbeelding neergezet. Door het een hoogte van 200 px te geven, wordt een ruimte van 200 px onder de <span> met de grote afbeelding gevuld met de achtergrondkleur.

Omdat dit alleen in (heel) kleine browservensters speelt, zou dit voor elke situatie voldoende moeten zijn.

(Omdat alleen bottom wordt opgegeven en geen top, wordt de hoogte van 200 px gemeten vanaf de onderkant van het pseudo-element.)

position: absolute;

Om het pseudo-element op de juiste plaats neer te kunnen zetten. Er wordt gepositioneerd ten opzichte van de eerste voorouder die zelf is gepositioneerd. Dat is hier span.foto, de <span> waar dit pseudo-element bij hoort.

Een pseudo-element is van zichzelf een inline-element. Dat betekent onder andere dat je eigenschappen als hoogte en breedte niet kunt gebruiken. Door het absoluut te positioneren verandert het in een soort blok-element, waardoor je dit soort eigenschappen wel kunt gebruiken.

bottom: -200px;

200 px onder de <span> met de grote afbeelding neerzetten.

.tekst

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

color: black;

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

Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hieronder bij div[id^="thumb-"]:hover .tekst, div[id^="thumb-"]:focus .tekst wordt een achtergrondkleur opgegeven. Sommige mensen hebben zelf de kleur en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

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

box-sizing: border-box;

In smallere browservensters moet de <span> met het onderschrift de volle breedte van het browservenster vullen. Als je margin, border of padding gebruikt, wordt dat standaard bij die breedte opgeteld. Waardoor het onderschrift dus de breedte van het venster zou krijgen plus daarbij nog een eventuele marge en dergelijke

In dit geval is het makkelijker om de <span> met het onderschrift even breed te maken als het venster van de browser, maar de marge en dergelijke bínnen die breedte te zetten. Dan kan de <span> nooit breder worden dan het venster, waardoor er delen zouden kunnen verdwijnen buiten het venster.

height: 3rem;

Een hoogte van 3 rem. Een rem is een em, maar dan ten opzichte van de 'root', hier het <html>-element. Daardoor is deze 3 rem altijd exact hetzelfde als de kier van 3 rem onder span.foto, ongeacht de lettergrootte.

Een uitgebreider verhaal over het waarom van deze wat onbekende eenheid is hierboven bij .foto te vinden onder bottom: 3rem;.

font-size: 0.75em;

Iets kleinere letter. Voor grotere browservensters wordt de lettergrootte later weer vergroot.

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.

padding: 3px 5px;

Kleine afstand tussen tekst en buitenkant van de <span>.

Omdat voor onder en links geen waarde is ingevuld, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 3px 5px 3px 5px in de volgorde boven – rechts – onder – links.

pointer-events: none;

Deze eigenschap is nodig voor een bug in Internet Explorer 11 op touchscreens en UC browser op Windows phone. Het zorgt ervoor dat aanrakingen, klikken, hoveren, en dergelijke op deze <span>'s volledig wordt genegeerd. Een uitgebreidere uitleg is hierboven bij .foto onder pointer-events: none;.

position: fixed;

De positie van de <span> koppelen aan het venster van de browser. De onderschriften staan altijd op dezelfde plaats, ook als wordt gescrold.

Dit is van belang in lage vensters. Als je daarin de thumbnails naar boven scrolt, omdat ze niet allemaal zichtbaar zijn, zou het onderschrift bij gebruik van bijvoorbeeld position: absolute; in plaats van position: fixed; te hoog worden neergezet. Hierdoor zou het onderschrift soms niet onder, maar over de grote afbeelding worden geplaatst, zoals op de afbeelding is te zien.

top: calc(50% + 37.5vw – 24px);

Ik zou hier nu graag in een gloedvol betoog willen uitdragen dat ik begrijp wat hier gebeurt. En dat hier Einsteiniaanse hogere wiskunde achter zit van een wonderschone genialiteit.

Helaas.

Ik heb werkelijk geen flauw idee, waarom deze berekening werkt. Althans: sommige dingen begrijp ik. Maar waar die 37.5 vw vandaan komt???

Bovenstaande toverspreuk zorgt ervoor dat in vensters in portretstand het onderschrift precies onder de grote afbeelding komt te staan. In landschapsstand kan het onderschrift smaller zijn dan de afbeelding en is dat foeilelijk. Voor landschapsstand staat verderop bij .tekst andere css. In browservensters breder dan 759 px geldt dit ook niet, want daar is de hele weergave anders. Dat wordt verderop bij css voor vensters minimaal 760 px breed geregeld. De css hier heeft dus alleen betrekking op vensters in portretstand smaller dan 760 px.

Goed, de toverformule.

De plaatsing en grootte van de grote afbeelding is afhankelijk van stand en grootte van het browservenster. Daardoor staat de onderkant van de grote afbeelding niet op een vaste plaats. Maar het zou leuk zijn, als het onderschrift toch altijd gelijk onder de grote afbeelding komt te staan.

Daarvoor ben ik uitgebreid aan het spelen gegaan. Op een gegeven moment had ik 'n soort formule met wel tien getallen, die bleek te werken. Door vereenvoudigen is daar uiteindelijk bovenstaande berekening uit overgebleven. Zo stond er een versie eerder bijvoorbeeld (100vw / 2.66). Dat kun je ook zelf uitrekenen en dan blijkt dat gewoon hetzelfde te zijn als 37,5 vw.

Helaas heb ik die uitgebreide formule per ongeluk niet bewaard. En aangezien ik niet weet, wat ik heb gedaan – wat trouwens wel vaker gebeurt –, kan ik die ook niet reconstrueren. Jammer, want iemand met enigszins wiskundige aanleg zou mogelijk kunnen uitleggen, waarom dit werkt.

Bij een andere grootte van de grote afbeeldingen, waarbij de plaatsing van de grote afbeelding dus verandert en daardoor ook de plaats van de onderkant van de grote foto, zou je met de waarden 37.5vw en 24px moeten gaan experimenteren om nieuwe juiste waarden te vinden.

top: gewoon de positie vanaf de bovenkant.

calc(): met behulp van calc() kun je allerlei berekeningen uitvoeren, zelfs met waarden die verschillende eenheden gebruiken. In deze berekening bijvoorbeeld worden de waarden %, vw en px gebruikt. De uiteindelijke eenheid is afhankelijk van een aantal dingen, waaronder de eigenschap waarvoor calc() wordt gebruikt. Hier is de uiteindelijke eenheid px.

Het deel tussen de haakjes wordt berekend. Hierbij gelden de normale voorrangsregels, zoals die ook bij gewoon rekenen gelden.

50%: zet de <span> verticaal halverwege het venster van de browser neer. Als je het onderschrift daar laat staan, komt het uiteraard midden op de grote afbeelding te staan. Daarom wordt het een eindje omlaag verplaatst:

+ 37.5vw: 1 vw is 1% van de hoogte van het venster van de browser. Ongeacht hoe hoog dat venster is. 37.5vw is dus altijd gelijk aan 37,5% van de volle hoogte van het venster. Ongeacht hoe hoog of hoe laag tussenliggende voorouders van deze <span> zijn.

Deze hoeveelheid wordt opgeteld bij de 50% die gelijk hierboven is gebruikt. Het onderschrift staat nu dus op 50% + 37,5 vw van de bovenkant van het venster. Omdat twee relatieve eenheden zijn gebruikt, past deze plaats zich automatisch aan de hoogte van het venster aan. 50% is altijd de helft, hoe hoog of hoe laag het venster ook is. En 1 vw is 1%, dus die eenheid past zich ook aan de hoogte van het venster aan.

Die 37,5 vw heb ik gewoon door uitproberen gevonden. Nu blijkt echter dat het onderschrift iets te laag staat. En eigenaardig genoeg staat het altijd dezelfde hoeveelheid te laag: 24 px:

– 24px: zet het onderschrift weer 24 px naar boven. Dit is een absolute eenheid: 24 px is altijd 24 px, hoe hoog of hoe laag het browservenster ook is. Waarom nou precies deze hoeveelheid px, een absolute eenheid, werkt in combinatie met de relatieve 50% en 37,5 vw: ik heb geen flauw idee.

Ongetwijfeld is dit door iemand met voldoende wiskundige kennis te verklaren, maar ik had de pest aan mijn wiskundeleraar en hij aan mij, dus helaas.

right: 0;

De <span> met het onderschrift moet in smallere browservensters helemaal tot de rechterkant van het venster staan. Voor bredere vensters wordt dat later aangepast.

Hier iets onder wordt de linkerkant van de <span> met left: -20000px; links buiten het scherm geparkeerd. Omdat de linkerkant 20000px links buiten het scherm staat, is redelijk zeker dat alle tekst in de <span> ook buiten het scherm staat, en dus onzichtbaar is. Een regel tekst die (meer dan) 20000 px lang is, is wat onwaarschijnlijk.

Dat geldt echter niet voor de achtergrondkleur van de <span>. De <span> loopt van left: -20000px; tot right: 0; en bestrijkt dus de volle breedte van het venster van de browser. Inclusief achtergrondkleur. Daarom wordt aan de <span> pas een achtergrondkleur gegeven bij div[id^="thumb-"]:hover .tekst, div[id^="thumb-"]:focus .tekst, als het onderschrift getoond moet worden.

bottom: 0;

Tot aan de onderkant van het browservenster laten doorlopen.

Iets hierboven is met top ook een positie ten opzichte van de bovenkant van het venster opgegeven. En er is een hoogte van 3 rem opgegeven.

Deze drie eigenschappen botsen met elkaar. Als je top en een hoogte opgeeft, staat bottom ook al vast. In dat geval winnen top en height en wordt bottom genegeerd.

De enige reden om hier al bottom op te geven: ik vind het overzichtelijker om zoveel mogelijk eigenschappen op één plaats toe te voegen. Maar daar kun je anders over denken.

Bij vensters in landschapsstand die maximaal 759 px breed zijn, en bij staande foto's in portretstand, wordt later speciaal voor die vensters top: auto; toegevoegd. Daarmee wordt top uitgeschakeld en wordt bottom: 0; wel effectief. De hoogte van 3 rem geldt dan vanaf de onderkant van het browservenster.

left: -20000px;

Linkerkant van de <span> met het onderschrift links buiten het scherm parkeren, zodat het onderschrift in de <span> links buiten het browservenster staat en dus onzichtbaar is.

Je zou de hele <span>, en dus ook de tekst daarin, ook kunnen verbergen met display: none;, maar dan zouden schermlezers de tekst ook negeren. Nu wordt het onderschrift gewoon voorgelezen, ook al staat het buiten het scherm. Hierdoor kunnen blinden, als je goede onderschriften gebruikt, toch een beschrijving van de afbeelding horen.

.link

De elementen met class="link". De twee <span>'s linksonder de thumbnails met links.

background: #ffffcf;

Achtergrondkleurtje.

display: block;

Een <span> is een inline-element. Daardoor zijn eigenschappen als breedte niet te gebruiken. Door er een blok-element van te maken, kan dit soort eigenschappen wel worden gebruikt.

width: 59px;

Breedte.

De vakjes met de links moeten even breed zijn als de thumbnails erboven, anders is het geen gezicht. Die thumbnails zijn 60 px breed, plus een kier ertussen van 1 px. Dat maakt 61 px. En hier staat 59 px. Ik word soms zo moe...

Hieronder wordt een border aan de linkerkant opgegeven van 1 px. Dat maakt 59 + 1 = 60 px. Maar met behulp van margin-left: -1px; wordt dat weer ongedaan gemaakt. Dus weer 59 px en ik blijf moe.

Hier komt de oplossing: hieronder wordt ook links en rechts een padding van 1 px opgegeven. Dat maakt het totaal 1 + 59 + 1 = 61 px.

min-height: 80px;

Minimale hoogte 80 px. 80 px is ook de hoogte van een staande thumbnail. Dit vult de overgebleven ruimte precies op.

Een blok-element (de <span> is iets hierboven veranderd in een blok-element) wordt normaal genomen automatisch groot genoeg om de inhoud ervan weer te geven. Ook als die inhoud er niet in past. Dan zie je in ieder geval alles, al wordt de lay-out mogelijk wordt verstoord.

Maar het element zelf groeit niet echt: alleen de inhoud – hier de links – wordt weergegeven. Maar geen achtergrondkleur, want die hoort bij het element. Als je geen height maar min-height gebruikt, groeit het element zelf mee en dus ook de daarin zittende achtergrondkleur.

Omdat de ruimte voor de links heel klein is, staan de links bij een grotere lettergrootte snel buiten de <span>'s. Door de hele <span> en daarmee de achtergrondkleur mee te laten groeien, blijven de links toch leesbaar.

font-size: 0.7em;

Kleine letter, anders past het er niet in.

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.

text-align: center;

Tekst horizontaal centreren.

-moz-hyphens: auto; -ms-hyphens: auto; -webkit-hyphens: auto; hyphens: auto;

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

De ruimte, waarin de tekst van de links moet worden weergegeven, is erg smal. Daarom wordt automatisch afbreken aangezet. Een woord als 'pagina' past anders, als de letters vergroot worden, niet meer binnen de <span>. Op de afbeelding iets hierboven is te zien, dat sommige woorden worden afgebroken bij een grotere lettergrootte.

margin-left: -1px;

De <span>'s met de links 1 px naar links zetten.

De <div>'s voor de kolommen met thumbnails krijgen bij #thumbs > div links een marge van 1 px, waardoor ze precies boven de thumbnails komen te staan. (Tussen de thumbnails zit ook een kier van 1 px, waardoor de achtergrond van div#thumbs zichtbaar is.)

Hier gelijk onder krijgen de <span>'s links een border van 1 px.

De linker van deze twee <span>'s komt gelijk naast de tweede <div> met 'n kolom te staan. De zwarte linkerborder van de <span> staat nu 1 px te veel naar links, waardoor hij niet onder de 'kier' tussen de thumbnails komt te staan. Om dat te corrigeren, wordt hij 1 px naar links gezet.

Voor de <span> aan de rechterkant geldt ongeveer hetzelfde, maar nu ten opzichte van de <span> links. Dus ook deze moet 1 px naar links worden geschoven.

border-left: black solid 1px;

Links een randje, dat precies aansluit op de kier tussen de thumbnails.

padding: 2px 1px 0;

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

Boven een kleine padding van 2px, links en rechts 1px en onderaan geen.

div[id^="thumb-"]:hover .foto, div[id^="thumb-"]:focus .foto

div[id^="thumb-"]: alle <div>'s die een id hebben die begint met 'thumb-'. Dat zijn de 34 <div>'s boven de thumbnails. Hoe dit deel van de selector precies werkt, wordt bij div[id^="thumb-"] besproken.

Als over één van deze <div>'s wordt gehoverd, of als één van deze <div>'s focus heeft, doe dan iets met de in die <div> zittende elementen met class="foto". Dat is er in elke <div> maar eentje: de <span> waarin de grote afbeelding wordt getoond.

display: block;

Bij .foto zijn deze <span>'s met behulp van display: none; verborgen. Nu worden ze zichtbaar gemaakt, waardoor ook de erin zittende grote afbeelding zichtbaar kan worden.

div[id^="thumb-"]:hover .foto, div[id^="thumb-"]:hover .tekst

Voor de eerste selector, die voor de komma, geldt ook de eerder bij div[id^="thumb-"]:hover .foto, div[id^="thumb-"]:focus .foto opgegeven css.

div[id^="thumb-"]: alle <div>'s die een id hebben die begint met 'thumb-'. Dat zijn de 34 <div>'s boven de thumbnails. Hoe dit deel van de selector precies werkt, wordt bij div[id^="thumb-"] besproken.

Als over één van deze <div>'s wordt gehoverd, doe dan iets met de daarin zittende elementen met class="foto" en class="tekst". In elke <div> zit maar één zo'n element: span.foto waarin de grote afbeelding wordt getoond en span.tekst waarin het onderschrift zit.

z-index: 10;

Dit is alleen van belang, als met de muis wordt gewerkt.

Als één van de 34 <div>'s boven de thumbnails focus heeft, worden bijbehorende grote afbeelding en onderschrift getoond. Als je nu tegelijkertijd met de muis over een andere thumbnail hovert, wordt ook die geopend. Er zijn dan dus twee grote afbeeldingen met twee onderschriften geopend.

Stel dat de tiende afbeelding is geopend, omdat de bijbehorende tiende <div> focus heeft. Als je nu over een eerdere <div> hovert, dus de eerste tot en met de negende, gebeurt er niets. Althans: je ziet niets. Door het hoveren openen nóg een grote afbeelding en onderschrift, maar die zie je niet, omdat de tiende <div> in de html na de eerste tot en met de negende <div> komen. Daardoor staan de tiende grote afbeelding en onderschrift altijd boven die van een hoger in de html staande <div>.

Maar als je over de elfde of latere <div> hovert, zie je wel de bij die <div> horende grote afbeelding en onderschrift. Want die staan lager in de html, en 'winnen' dus van de tiende <div>.

Ietwat verwarrend: als een <div> focus heeft, zie je de ene keer wel iets bij hoveren, en de andere keer niet.

Door bij hoveren aan de <div> waarover wordt gehoverd een hogere z-index te geven, worden de bij deze <div> horende grote afbeelding en onderschrift altijd getoond, ongeacht de volgorde in de html.

Een z-index werkt alleen, als het element voldoet aan één of meer voorwaarden. Eén van die voorwaarden is een absolute of fixed positie. span.foto en span.tekst zijn fixed gepositioneerd. Voor bredere browservensters wordt dat later veranderd in een absolute positie. In beide gevallen is dus aan één van de voorwaarden voldaan en zal z-index werken.

div[id^="thumb-"]:hover .tekst, div[id^="thumb-"]:focus .tekst

Voor de eerste selector (voor de komma) geldt ook de eerder bij div[id^="thumb-"]:hover .foto, div[id^="thumb-"]:hover .tekst opgegeven css.

div[id^="thumb-"]: alle <div>'s die een id hebben die begint met 'thumb-'. Dat zijn de 34 <div>'s boven de thumbnails. Hoe dit deel van de selector precies werkt, wordt bij div[id^="thumb-"] besproken.

Als over één van deze <div>'s wordt gehoverd, of als één van deze <div>'s focus heeft, doe dan iets met de daarin zittende elementen met class="tekst". In elke <div> zit maar één zo'n element: de <span> met het onderschrift.

background: #ffffcf;

Achtergrondkleurtje.

Normaal genomen zou ik dat hebben opgegeven bij .tekst, waar de rest van de css voor deze <span>'s ook is opgegeven. Dat kan echter niet, omdat de <span> al op het scherm staat. Je ziet hem niet, maar hij is er wel. Als daar al een achtergrondkleur zou worden gegeven, zou je de <span> wel zien. Vandaar dat in dit geval pas een achtergrondkleur wordt gegeven, als het onderschrift getoond moet worden.

Het is een goede gewoonte om bij een achtergrondkleur ook een voorgrondkleur op te geven. De voorgrondkleur is onder andere de kleur van de tekst. Sommige mensen hebben zelf de kleur en/of achtergrondkleur veranderd, bijvoorbeeld omdat ze slecht kleuren kunnen onderscheiden. Als ik nu de achtergrondkleur verander, maar niet de voorgrondkleur, loop ik het risico dat tekstkleur en achtergrondkleur te veel op elkaar gaan lijken.

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

In dit geval is de voorgrondkleur al bij .tekst opgegeven, zodat ook dit is geregeld.

left: 0;

Bij .tekst zijn de <span>'s fixed gepositioneerd. Er wordt dus gepositioneerd ten opzichte van het venster van de browser, ongeacht hoe breed dit is.

Bij .tekst is de linkerkant van de <span> met left: -20000px; links buiten het scherm geparkeerd. Hierdoor staat ook de tekst van het in deze <span> zittende onderschrift links buiten het scherm en is dus niet zichtbaar.

Met left: 0; wordt de linkerkant van de <span> links in het venster van de browser gezet, waardoor het in de <span> zittende onderschrift ook binnen het venster komt te staan en zichtbaar wordt.

#thumb-1:hover .foto, #thumb-1:focus .foto

Voor dit element geldt ook de eerder bij div[id^="thumb-"]:hover .foto, div[id^="thumb-"]:focus .foto en div[id^="thumb-"]:hover .foto, div[id^="thumb-"]:hover .tekst opgegeven css.

Als over het element met id="thumb-1" wordt gehoverd, of als dit focus heeft, doe dan iets met de daarin zittende elementen met class="foto". Dat is hier maar één element: de <span> voor de grote afbeelding.

De <div> met id="thumb-1" hoort bij de eerste thumbnail. De daarin zittende span.foto hoort – volgt schokkende onthulling – bij de eerste grote foto. Wat kan het leven simpel en overzichtelijk zijn!

background-image: url(../016-pics/foto-01.jpg);

Achtergrond-afbeelding invoegen.

In heel veel situaties kan een afbeelding gewoon met <img> worden ingevoegd en worden verborgen met iets als display: none;. Dat zou hier ook kunnen, maar het heeft één heel groot nadeel: alle afbeeldingen worden bij openen van de pagina gedownload, ook als ze zijn verborgen en helemaal niet worden bekeken.

Datzelfde geldt voor 'gewone' achtergrond-afbeeldingen:

#thumb-1 {background-image: url(../016-pics/foto-01.jpg);

wordt altijd gedownload, of het nou wordt bekeken of niet.

Met 34 afbeeldingen kan dat nogal bezwaarlijk zijn op bijvoorbeeld een mobiele verbinding.

Door de achtergrond-afbeelding pas in te voegen, als daadwerkelijk over de <div> bij die afbeelding wordt gehoverd, of als deze focus heeft, wordt de afbeelding pas gedownload, als hij echt wordt bekeken. Als je geen enkele afbeelding zou bekijken, zou zelfs geen enkele afbeelding worden gedownload. (Behalve natuurlijk de afbeelding met de thumbnails, maar die heeft hier niets mee te maken.)

#thumb-2:hover .foto, #thumb-2:focus .foto

{background-image: url(../016-pics/foto-02.jpg);}

tot en met

#thumb-34:hover .foto, #thumb-34:focus .foto

{background-image: url(../016-pics/foto-34.jpg);}

De elementen met id="thumb-2" tot en met id="thumb-34". Dit zijn de <div>'s die bij de tweede tot en met 34^e thumbnail horen. De namen van de achtergrond-afbeeldingen horen bij de bijbehorende grote afbeeldingen.

De css is exact hetzelfde als gelijk hierboven bij #thumb-1:hover .foto, #thumb-1:focus .foto, alleen het volgnummer van de <div> en het volgnummer van de achtergrond-afbeelding veranderen.

css voor vensters in portretstand

@media screen and (orientation: portrait)

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

De css die binnen deze media query staat, geldt alleen voor vensters in portretstand. In deze vensters wordt voor staande foto's een deel van de css aangepast.

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

(orientation: portrait): het scherm moet in portretstand zijn.

Een scherm kent twee standen: landscape (landschap, liggend) en portrait (portret, staand). (Allerlei andere standen, zoals bijvoorbeeld lezend in bed, tellen hier niet mee. Liggend of staand, dat is het, al hang je met je tablet ondersteboven heen en weer te zwaaien aan de trapeze.)

Dit is bedoeld voor tablets, smartphones, en dergelijke Voor desktop monitors zal de stand meestal niet echt van belang zijn. Maar in veel browsers werkt dit ook op de desktop. Als je de grootte van het browservenster verandert, zodat het de hoogte groter wordt dan de breedte (portretstand) wordt, werkt dit vaak ook op de desktop.

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

@media screen and (orientation: portrait) { 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 }.

.staand .tekst

De elementen met class="tekst" die binnen een element met class="staand" zitten. De <div>'s die bij de twee staande foto's horen, hebben een extra class 'staand' gekregen. Binnen deze <div>'s zit maar één element met class="tekst": de <span> met het onderschrift. Deze selector heeft dus betrekking op de onderschriften bij de staande foto's.

top: auto;

Bij .tekst wordt de plaats van het onderschrift bij top berekend met een formule: calc(50% + 37.5vw - 24px). Deze is formule is door mijzelf bedacht en zo geniaal, dat ik er zelf niets van begrijp. Maar 't kreng werkt, en daar gaat het om.

Althans, het werkt bij liggende afbeeldingen. Bij een staande afbeelding werkt het dus niet, zoals op de afbeelding is te zien.

Bij .tekst is, naast top, ook bottom: 0; en height: 3rem; opgegeven. Die combinatie kan natuurlijk niet: bij een bepaalde top met een bepaalde height staat automatisch ook bottom vast. Omdat dit met elkaar botst, wordt bottom daar genegeerd.

Hier wordt top ingesteld op de standaardwaarde: auto. Nu blijven alleen bottom: 0; en height: 3rem; over. En dat kan wel: een hoogte van 3 rem vanaf de onderkant van het browservenster.

(Omdat span.tekst bij .tekst fixed is gepositioneerd, geldt bottom: 0; ten opzichte van het venster, hoe hoog of laag dit ook is.)

css voor vensters in landschapsstand en maximaal 759 px breed

@media screen and (orientation: landscape) and (max-width: 759px)

De opbouw van deze regel staat beschreven bij media screen and (orientation: portrait). Er zijn twee verschillen: de stand moet hier landschapsstand zijn, en er is een extra voorwaarde: het browservenster mag niet breder dan 759 px zijn (max-width: 759px).

De css binnen deze media query corrigeert de plaats van het onderschrift in deze vensters.

.tekst

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

In een liggend venster kan het onderschrift breder of smaller worden dan de grote afbeelding, waar het onderschrift onder komt te staan. Dit geldt niet voor browservensters breder dan 759 px, want daarvoor wordt verderop de weergave volledig aangepast.

In portretstand vult de grote afbeelding altijd de volle breedte van het venster van de browser. Het onderschrift mag daar ook de volle breedte vullen, omdat het netjes aansluit op de grote foto.

In landschapsstand ligt dat anders: het onderschrift kan hier (veel) breder of smaller worden dan de grote afbeelding. Daarom wordt het uiterlijk van het onderschrift aangepast. Zou dat niet gebeuren, dan zou het een rechthoekig blok blijven, wat niet echt fraai is.

Bovendien werkt de formule die bij .tekst is opgegeven voor top niet meer, waardoor het onderschrift te hoog kan komen te staan, over de afbeelding heen.

Daarom worden hier plaats en uiterlijk van de <span>'s met het onderschrift aangepast voor deze vensters.

width: 80%;

Breedte. Een breedte in procenten wordt altijd genomen ten opzichte van de ouder van het element. Dat is hier één van de 34 <div>'s die boven de thumbnails staan. Deze <div>'s zijn even breed als het venster van de browser. De <span> met het onderschrift krijgt dus een breedte van 80% van het venster van de browser.

max-width: 480px;

De css hier is geldig voor vensters met een maximumbreedte van 759 px. Tot die breedte kan de grote afbeelding de volle breedte van het venster van de browser vullen. Dat zou hele lange regels opleveren, die daardoor slecht leesbaar zijn. Daarom wordt de breedte beperkt tot maximaal 480 px.

Dat is trouwens dezelfde breedte als het onderschrift in vensters breder dan 759 px krijgt, dus dat zou wat de hoeveelheid tekst in het onderschrift betreft geen probleem moeten zijn.

margin: 0 auto;

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

Boven en onder geen marge, links en rechts auto, wat hier hetzelfde betekent als evenveel. De <span> met het onderschrift staat dus altijd horizontaal gecentreerd, ongeacht de breedte van het venster van de browser. Deze manier van centreren van een blok-element kan alleen, als het te centreren element een breedte heeft.

Hier doet zich een eigenaardig verschijnsel voor. Bij .tekst zijn de <span>'s fixed gepositioneerd. Normaal genomen kan een element dat absoluut of fixed is gepositioneerd, niet horizontaal worden gecentreerd met behulp van het handige margin: 0 auto;.

Bij .tekst is echter ook right: 0; opgegeven. En bij hoveren over of focus op de <div> waar de <span> in zit, wordt bij div[id^="thumb-";]hover .tekst, div[id^="thumb-"]:focus .tekst aan de <span> left: 0; opgegeven.

Daardoor staat hier right: 0; én left: 0; én een maximumbreedte. Dat bijt elkaar natuurlijk. De maximumbreedte is 480 px, dus als het venster van de browser breder is dan 480 px, kan deze <span> onmogelijk gelijktijdig van helemaal links tot helemaal rechts lopen.

De browser raakt hier dermate van in de war, dat right: 0; en left: 0; gewoon worden genegeerd en margin: 0 auto; werkt. Oftewel: bij een absolute of fixed positie werkt margin: 0 auto; niet, tenzij je ook left: 0; en right: 0; opgeeft. (Een eigenaardigheid die trouwens nauwelijks bekend is en ikzelf zojuist ook pas voor het eerst heb ontdekt.)

border: black solid 1px;

Zwart randje.

border-radius: 10px 10px 0 0;

Linksboven en rechtsboven ronde hoek.

top: auto;

Bij .tekst wordt top berekend met behulp van top: calc(50% + 37.5vw – 24px);. Die formule werkt alleen bij vensters in portretstand. Daarom wordt hier de standaardinstelling aan top gegeven: auto. Waarmee het is uitgeschakeld.

Bij .tekst is ook bottom: 0; opgegeven, en ook een hoogte van 3 rem. Deze combinatie van top, hoogte en bottom kan niet. Als je een top opgeeft én een bepaalde hoogte, dan is bottom ook al bekend. Bij zo'n botsing wordt bottom gewoon genegeerd.

Nu is top uitgeschakeld en zijn alleen bottom: 0; en height: 3rem; over. En dat kan wel. Onderaan het venster van de browser neerzetten en vanaf daar 3 rem hoog maken. (Omdat bij .tekst een fixed positie aan de <span> is gegeven, wordt deze gepositioneerd ten opzichte van het venster van de browser.)

JavaScript

Dit is gewone html: het zijn de openings- en sluittag voor het script. In html5 is de toevoeging type="text/javascript" niet meer nodig.

In feite wordt hier gewoon gezegd: als het scherm wordt aangeraakt, blijf dan niet dom tot het jaar 3017 wachten op wat er verder gebeurt, maar reageer gelijk. Zonder dit stukje JavaScript openen de grote afbeeldingen en onderschriften niet, omdat de browser blijft wachten op het vervolg van de aanraking.

Bij de uitleg van deze code zijn allerlei haakjes en dergelijke weggelaten, want dat voert hier te ver. Als je je in dat soort dingen wilt verdiepen, kun je beter naar sites gaan die meer voor JavaScript zijn bedoeld.