Bestanden invoegen met behulp van <object> - uitleg
Laatst aangepast: .

Korte omschrijving
Een ander bestand invoegen met behulp van <object>. De ingevoegde bestanden zijn respectievelijk platte tekst, html, pdf en shtml.
BELANGRIJK
Deze uitleg hoort bij het voorbeeld dat in de download zit. Het voorbeeld uit de download verschilt iets van het voorbeeld hier op de site. In de download ontbreekt bijvoorbeeld de navigatie voor de site. Ook in de kopregels zit vaak wat verschil. Daarnaast kunnen er nog andere (meestal kleine) verschillen zijn.
Als je deze uitleg leest naast de broncode van het voorbeeld op de site, kan het dus bijvoorbeeld zijn dat 'n <h1> uit de css bij 'n <h2> uit de html hoort. Maar het gaat niet om hele grote, fundamentele afwijkingen.
Als je dit lastig vindt, kun je bovenaan de pagina de hele handel downloaden. In de download zit 'n voorbeeld dat wel naadloos aansluit op de uitleg in de download.
Alles op deze site kan vrij worden gebruikt, met twee beperkingen:
* Je gebruikt het materiaal op deze site volledig op eigen risico. Het kan prima zijn dat er fouten in de hier verstrekte info zitten. Voor eventuele schade die door gebruik van materiaal van deze site ontstaat, in welke vorm dan ook, zijn www.css-voorbeelden.nl en medewerkers daarvan op geen enkele manier verantwoordelijk.
* Deze uitleg wordt regelmatig bijgewerkt. Het is daarom niet toegestaan deze uitleg op welke manier dan ook te verspreiden, zonder daarbij duidelijk te vermelden dat de uitleg afkomstig is van www.css-voorbeelden.nl en dat daar altijd de nieuwste versie is te vinden. Dit is om te voorkomen dat er verouderde versies worden verspreid.
Een link naar www.css-voorbeelden.nl wordt trouwens altijd op prijs gesteld.
Alle code is geschreven in een afwijkende
lettersoort en -kleur. De code die te maken heeft met de basis van dit voorbeeld (essentiële code), is in de hele uitleg onderstippeld blauw
. Alle niet-essentiële code is bruin
. (In de inhoudsopgave staat alles vanwege de leesbaarheid in een gewone letter.)
Opmerkingen
- In één van de vier objecten wordt een pdf-bestand ingevoegd. Dit is vooral gedaan om te laten zien, waarom je op deze manier geen pdf moet invoegen: het is in veel browsers niet te lezen. Bij Bekende problemen (en oplossingen) is er meer over te vinden.
-
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
Soms kan het handig zijn een ander bestand in een pagina in te voegen. Dat kan op verschillende manieren.
Als bijvoorbeeld een menu op veel pagina's wordt herhaald, kan dat menu in een apart bestand worden opgeslagen. Het kan dan worden ingevoegd op de pagina's, waar dat menu nodig is. Voordeel is dat het menu maar op één plaats hoeft te worden gewijzigd, in plaats van op elke aparte pagina waar het wordt gebruikt.
Voor dit invoegen van bestanden wordt meestal PHP gebruikt, en ook wel SSI (Server Side Includes). In beide gevallen wordt het bestand al op de server ingevoegd, waardoor de browser gewoon één pagina met html ziet. Dat is bijvoorbeeld bij de vroeger gebruikte frames anders. Bij frames worden afzonderlijke bestanden gedownload en door de browser naast elkaar weergegeven.
Dat is een belangrijk verschil. Als de server bestanden samenvoegt, zijn die voor de browser echt één pagina. Daarmee zijn ze ook voor schermlezers, zoekmachines, en dergelijke één pagina.
Als de browser verschillende bestanden samenvoegt, blijven het verschillende bestanden. Op het scherm ziet het er misschien samenhangend uit, achter de schermen zijn het aparte bestanden die niets met elkaar te maken hebben. Dat levert enorme problemen op voor bijvoorbeeld schermlezers. Maar ook zoekmachines kunnen hier niet goed mee uit de voeten, omdat de samenhang tussen de diverse onderdelen onduidelijk is.
In het algemeen kan het invoegen van bestanden daarom het best met behulp van technieken als PHP of SSI worden gedaan. Maar soms moet er maar een klein bestandje worden ingevoegd, en dan is <object> ook bruikbaar.
Als je iets invoegt met behulp van PHP of SSI, moet de pagina als extensie 'php' of 'shtml' hebben. Een normale pagina eindigt op 'html'. Als bij een al bestaande pagina 'html' veranderd moet worden in 'php' of 'shtml', kan dat problemen opleveren met bijvoorbeeld links naar de pagina. Als het niet op de juiste manier gebeurt, kan het ook nadelig zijn voor de plaats in de zoekindex van zoekmachines.
Soms wordt als oplossing aangeraden om als extensie gewoon 'html' te houden, maar de server alles als PHP of shtml te laten bekijken. (Dat kan niet bij elke hoster, je hoster moet toestaan dat je iets als .htaccess gebruikt.)
Dit is een bijzonder slecht idee. De server gaat nu namelijk álle html-pagina's een soort extra behandeling geven, ook html waar helemaal geen PHP of SSI in aanwezig is. Dit is een extra belasting voor de server, waardoor de site (aanzienlijk) trager kan gaan werken. En als je gebruik maakt van gedeelde hosting, maak je ook je hoster er niet blij mee. Want als de server zwaarder wordt belast, heeft dat ook gevolgen voor andere sites op dezelfde server.
Een alternatief voor het veranderen van de extensie kan het gebruik van <object> zijn. Hiermee kun je ook andere bestanden invoegen. Voor grotere bestanden, menu's die op veel pagina's worden weergegeven, en dergelijke blijven PHP en SSI beter, maar voor kleine bestandjes, of als iets maar tijdelijk wordt ingevoegd, kan dit een goed alternatief zijn.
Bij gebruik van <object> in een bestaande html-pagina kan de extensie gewoon 'html' blijven. Het is zelfs mogelijk om phhp- en shtml-bestanden in te voegen, waarbij gebruik kan worden gemaakt van de mogelijkheden die die talen bieden, zoals het weergeven van een datum.
Ook aan deze methode zitten wat nadelen. Omdat de bestanden pas in de browser worden samengevoegd, zijn het – net als bij frames – aparte bestanden. Maar anders dan bij frames hebben schermlezers en zoekmachines hier geen moeite mee, omdat de bestanden op één specifieke plaats worden ingevoegd: exact waar <object> is opgenomen in de code.
Hier zijn twee uitzonderingen op. Een ingevoegd pdf-bestand levert zoveel problemen op, dat het feitelijk onbruikbaar is. Het is alleen opgenomen in dit voorbeeld om te laten zien, waarom je geen pdf moet invoegen op deze manier. (Meer hierover bij Bekende problemen (en oplossingen).
De tweede uitzondering is Bing, de zoekmachine van Microsoft. Als je de pagina ophaalt, zoals Bing die ziet, worden de ingevoegde bestanden genegeerd. Alleen de in de <object>'s zittende tekst wordt weergegeven. Er is dus een goede kans, dat Bing de ingevoegde bestanden niet indexeert. Dat is geen probleem voor bijvoorbeeld de flauwekul-gedichten die hier zijn gebruikt, maar voor belangrijker teksten kan het wel een probleem zijn.
In dit voorbeeld worden vier verschillende bestanden ingevoegd met behulp van <object>.
Omdat niet elke browser elk bestand kan weergeven, moet binnen <object> in principe een link naar het in te voegen bestand worden geplaatst. Als de browser het bestand niet weer kan geven, wordt dan – als het goed is – die link getoond, zodat de gebruiker het bestand in ieder geval kan downloaden of in een nieuw venster kan bekijken.
<object> moet altijd voldoende hoogte krijgen voor de inhoud ervan. Wat niet in <object> past, verdwijnt in sommige mobiele browsers gewoon spoorloos. Als de hoogte groot genoeg is, wordt dit voorkomen. Daarnaast krijgen desktopbrowsers, als geen hoogte wordt opgegeven bij <object>, altijd een scrollbalk, ook als dat niet nodig is.
(Op de desktop verschijnt overal netjes een scrollbalk als de inhoud te hoog is voor <object>, maar daar heb je weinig aan. Want in mobiele browsers verdwijnt het deel dat te hoog is spoorloos.)
Als je in de broncode kijkt, zie je alleen wat je zelf aan code hebt ingetypt. Om de ingevoegde bestanden te zien, moet je de Gegenereerde code bekijken.
Het eerste bestand is gewoon platte tekst. Dat is tekst zoals een simpele tekstverwerker die maakt. Programma's als Word of LibreOffice zijn hiervoor ongeschikt, omdat ze niet alleen tekst, maar hele regimenten extra codes maken. (Tenzij je het bestand expliciet als .txt-bestand opslaat.) Dit bestand wordt overal goed getoond, behalve op Windows Phone. Daar wordt de download-link getoond.
Het tweede bestand is een gewone pagina met html, inclusief doctype, <head>, enz. In de <head> staat css, en die wordt gewoon uitgevoerd. Op deze manier kun je dus de inhoud van <object> met behulp van css volledig aanpassen.
Het derde bestand is een pdf. Kort samengevat: volledig onbruikbaar voor weergave binnen <object>. Bij Bekende problemen (en oplossingen) staat een hele waslijst aan problemen.
Het vierde bestand is een hele leuke mogelijkheid. Het ingevoegde bestand heeft de extensie .shtml, wat bij Server Side Includes (SSI) hoort. Hierdoor behandelt de server het, alsof het een SSI-bestand is. Daardoor worden de in SSI beschikbare commando's ook uitgevoerd. Normaal genomen zou dat alleen gebeuren als, de hele pagina de extensie .shtml heeft, maar op deze manier kan dus SSI worden uitgevoerd binnen een normale html-pagina.
In dit voorbeeld worden het tijdstip van openen van de pagina en wat doorgestuurde informatie van de browser weergegeven. Voor beide worden SSI-commando's gebruikt. Daarnaast staan nog wat gewone html en tekst in het bestand.
SSI heeft veel minder mogelijkheden dan PHP, maar is voor simpele dingen best bruikbaar. Maar ook PHP kan op deze manier worden gebruikt. Geef het bestand dat wordt ingevoegd een php-extensie, en de server verwerkt het als PHP, ook al heeft de 'moederpagina' gewoon de extensie .html.
(Voor grotere bestanden, menu's die op veel pagina's voorkomen, en dergelijke blijft een echte php- of shtml-pagina een betere oplossing. Voor de kleine flauwekul-gedichten op deze pagina zijn <object>'s prima geschikt.)
Deze vierde mogelijkheid is alleen op een server te testen, omdat SSI nou eenmaal alleen op een server werkt. Je moet dat dus bij een hoster testen, of zelf een server installeren. Als je op internet zoekt naar LAMP (Linux), WAMP (Windows) of MAMP (OS X) vind je gratis te installeren servers.
Gegenereerde code
Het onderstaande geldt alleen voor desktopbrowsers. In browsers op mobiele systemen is het vaak ook mogelijk gegenereerde code te bekijken, maar dat is veel ingewikkelder. Bovendien verandert de manier, waarop dat kan, nogal snel.
Als je html schrijft, kan dat (hopelijk) in de browser worden weergegeven. Vanuit de browser kun je die html bekijken, precies zoals je hem hebt ingevoerd. Alsof je het in een editor ziet. In Firefox bijvoorbeeld kan dat door ergens op de pagina te rechtsklikken en te kiezen voor Paginabron bekijken, of door in het menu te kiezen voor Extra → Webontwikkelaar → Paginabron. (Of door de veel snellere sneltoets Ctrl+U.) Elke browser heeft dit soort mogelijkheden.
Wat je dan te zien krijgt, is exact de code, zoals jij die hebt ingetypt. Inclusief alle fouten, hoofd- en kleine letters, noem maar op. Als je zo slordig bent om een <p> niet af te sluiten, zit er niet plotsklaps een afsluitende </p> in de code. Als er css wordt gebruikt, html wordt ingevoegd via JavaScript, noem maar op, zie je daar niets van, want dat heb jij niet ingetypt.
Daar heb je dus eigenlijk vrij weinig aan, want die code kende je al. Die heb je zelf bloedig zitten intypen.
Wat de browser daadwerkelijk gebruikt, is iets totaal anders: de gegenereerde code. En die is veel interessanter, want die code blijkt (fors) af te wijken van wat jij heb ingetypt. De browser gebruikt een tijdelijke kopie van de door jou geschreven code, die zo is aangepast dat er voor de browser mee te werken is.
Elke browser heeft inmiddels mogelijkheden om de gegenereerde code te bekijken. In Firefox bijvoorbeeld in het menu Extra → Webontwikkelaar → Hulpmiddelen in-/uitschakelen. In Google Chrome in het menu onder Meer hulpprogramma's → Hulpprogramma's voor ontwikkelaars. In Internet Explorer open je dit door op F12 te drukken, en het kan vast ook via het menu.
Houdt er wel rekening mee dat elke browser de door jou ingetypte code iets zal aanpassen. In Firefox bijvoorbeeld wordt een <P> veranderd in een <p>. Als er 'n </p> mist, is die opeens wel aanwezig in de gegenereerde code. Wat elke browser precies aanpast, zal iets verschillen en kan ook nog veranderen. In het verleden veranderde Internet Explorer bijvoorbeeld een <p> juist in een <P>, nu is dat niet meer zo.
Als je met behulp van <object> bestanden invoegt, zijn de ingevoegde bestanden niet in alle browsers in de gegenereerde code te zien. Internet Explorer en Edge laten de ingevoegde bestanden niet zien, maar tonen gewoon de 'normale' broncode. Safari, Google Chrome en Firefox tonen wel de ingevoegde bestanden.
Afhankelijk van de browser en afhankelijk van het soort ingevoegde bestand, voegen deze drie browsers nog allerlei toeters en bellen toe. Soms wordt het ingevoegde bestand zelfs veranderd in een complete html-pagina, inclusief <head> en <body>. Waaruit ook weer duidelijk blijkt dat invoegen met behulp van <object> echt iets heel anders is, dan wanneer je rechtstreeks PHP of SSI invoegt, waarbij alles op de server tot één geheel wordt gemaakt.
Hoewel de gegenereerde code bij gebruik van <object> verwarrender is dan gegenereerde code zonder <object>, kan het mogelijk toch helpen om eventuele problemen op te sporen. En in ieder geval is het leerzaam om te zien, hoe verschillende browsers intern met exact dezelfde code omspringen.
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.
-
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
enborder
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
enborder
bínnen de breedte en hoogte van de inhoud te zetten met behulp vanbox-sizing
, als je dat handiger vindt. -
In plaats van een absolute eenheid als
px
kun je ook een relatieve eenheid gebruiken, met nameem
. Voordeel vanem
is dat een lettergrootte, regelhoogte, en dergelijke inem
in alle browsers kan worden veranderd. Nadeel is dat het de lay-out sneller kan verstoren dan bijvoorbeeldpx
. Dit moet je gewoon van geval tot geval bekijken. Voor weergave in mobiele apparaten zijn relatieve eenheden alsem
vrijwel altijd beter dan vaste eenheden alspx
.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. Zondertabindex
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 kantabindex
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 op toegankelijkheid laten controleren op 'n behoorlijk aantal sites, zoals:
lowvision.support: laat zien hoe een kleurenblinde de site ziet. Engelstalig.
wave.webaim.org: deze laat grafisch zien, hoe de toegankelijkheid is. Engelstalig. Deze tester is ook als extensie in Firefox en Google Chrome te installeren.
Op de pagina met links kun je onder Toegankelijkheid links naar meer tests en dergelijke vinden.
Specifiek voor dit voorbeeld
-
Van de geteste schermlezers leest alleen de combinatie NVDA/Firefox de pdf voor. Het is goed mogelijk dat NVDA in combinatie met bijvoorbeeld Internet Explorer de pdf niet voorleest, want Firefox heeft een ingebouwde pdf-lezer. Dit heb ik verder niet getest.
VoiceOver (iOS en OS X) en TalkBack (Android) lezen de pdf niet voor. Het op deze manier invoegen van een pdf maakt de pdf dus voor de meeste schermlezers volledig onbruikbaar.
Door de pdf als een download aan te bieden, kan de bezoeker een geschikt programma gebruiken, waarmee de pdf wel kan worden voorgelezen.
- Bij 'Fetchen als google' (ophalen zoals Google de pagina ziet), wordt de ingevoegde pdf genegeerd. Deze wordt dus vermoedelijk niet geïndexeerd door Google.
- Bij 'Als Bingbot ophalen' (ophalen zoals Bing de pagina ziet), worden de ingevoegde bestanden genegeerd. Alleen de in de <object>'s zittende tekst is zichtbaar. Vermoedelijk worden de ingevoegde bestanden dus niet geïndexeerd door Bing.
- Tekstbrowsers zoals Lynx en WebbIE tonen alleen de tekst binnen <object>, niet de inhoud van de bestanden.
- Zonder css werkt alles gewoon, alleen is de lay-out uiteraard wat chaotisch.
- Niet elke browser toont de ingevoegde pdf. Met JavaScript uit wordt de pdf in nog minder browsers getoond. Omdat een pdf invoegen via een <object> hoe dan ook een bijzonder slecht idee is, lijkt dit geen probleem.
Getest in
Laatst gecontroleerd op 18 januari 2016.
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. - Windows 10:
Firefox, UC Browser, Google Chrome, Internet Explorer 11, Edge, in meerdere resoluties. - 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.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, UC Browser, Firefox ( alle portret en landschap). - iPad Air met iOS 9.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, UC Browser, Firefox (alle 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 en 10 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.
Verticale scrollbalk in desktopbrowsers
Bij alle <object>'s moet een hoogte worden opgegeven. Als dat niet gebeurt, verschijnt in sommige desktopbrowsers een verticale scrollbalk, ook als dat helemaal niet nodig is.
Ingevoegd bestand wordt niet volledig weergegeven
Voor pdf staat hier gelijk onder een apart verhaal, dit geldt voor de ingevoegde platte tekst, html en shtml.
UC browser op Android, Android browser en alle browsers op iOS negeren inhoud, die niet binnen <object> past. Deze inhoud kan ook niet via scrollen worden bereikt. Daarom is het absoluut noodzakelijk aan <object> een hoogte te geven die groot genoeg is om de volledige inhoud weer te geven. Als tekst en dergelijke niet binnen <object> past, verdwijnt dit gewoon en is op geen enkele manier nog te bekijken.
Een breedte wordt in dit voorbeeld nergens opgegeven, omdat de ingevoegde bestanden erg smal zijn. Browsers geven een standaardbreedte aan een <object> zonder breedte, en die standaardbreedte is groot genoeg voor deze kleine bestandjes.
PDF wordt niet goed, niet volledig of helemaal niet getoond
Als je liever geen bezoekers hebt, is het invoegen van een pdf-bestand met behulp van <object> een prima hulpmiddel, om dat doel te bereiken. Het invoegen van een pdf op deze manier levert de meest uitbundige problemen op.
Als je een pdf-bestand wilt gebruiken, moet je dit als download beschikbaar stellen. Na downloaden kan de bezoeker het dan met een daarvoor geschikt programma lezen. Die speciale programma's lezen in de regel ook veel prettiger dan een pdf die in de browser wordt bekeken.
Een pdf is alleen in dit voorbeeld opgenomen om te laten zien, waarom je een pdf beslist níét op deze manier moet invoegen.
De problemen:
Android en Windows Phone
Op deze besturingssystemen kan geen van de geteste browsers een pdf weergeven. De in het object met de pdf opgenomen link om de pdf te downloaden, wordt wel netjes weergegeven. Na downloaden kan de pdf dan alsnog gelezen. Maar als je toch moet downloaden, kun je net zo goed dat hele <object> overslaan en gewoon rechtstreeks een fatsoenlijke download-link geven.
Als een bezoeker eerst een programma moet installeren om een deel van een site te kunnen lezen, is er een grote kans dat die bezoeker enthousiast de benen neemt naar een mensvriendelijker site.
iOS
Een heel kleine pdf wordt door alle browsers goed weergegeven. De in dit voorbeeld gebruikte pdf is extreem klein, dus dat gaat goed.
Zodra de pdf groter is dan de bij <object> opgegeven grootte, is het deel van de pdf dat buiten <object> valt gewoon verdwenen. Scrollen kan niet: wat niet binnen <object> past, is gewoon volledig verdwenen. Wat het nog erger maakt: op geen enkele manier is zichtbaar dat een deel van de pdf is verdwenen.
Er zijn al jaren klachten over scrollen binnen <object> (en <iframe>) op iOS, maar kennelijk wil of kan Apple dit niet repareren. Apple reageert vrijwel nooit op bugmeldingen. Hierdoor is het onduidelijk of dit niet kunnen scrollen opzettelijk is, of dat het om een bug gaat die ooit gerepareerd gaat worden.
Op internet zijn tientallen, zo niet honderden, oplossingen voor dit probleem te vinden. Als er zoveel oplossingen voor hetzelfde probleem zijn, betekent dat meestal dat geen enkele oplossing echt goed werkt. Dat is helaas ook hier het geval.
(Waarom er dan toch zoveel oplossingen zijn? Zijn die bedenkers zo vals? Nee. Vaak werkt 'n oplossing in één heel specifieke situatie en wordt vervolgens veel te snel aangenomen dat die oplossing altijd en overal voor iedereen werkt.)
Windows 7
Internet Explorer 9 en 10 hebben beide een plug-in nodig. Zonder plug-in wordt de in <object> opgenomen download-link getoond.
UC browser, Firefox en Google Chrome tonen de pdf met behulp van een ingebouwde pdf-lezer.
Windows 8
Voor de bureaublad-versie van Internet Explorer 11 is een plug-in nodig. Zonder plug-in wordt de in <object> opgenomen download-link getoond.
De startschermversie van Internet Explorer 11 kan helemaal geen pdf tonen, ook niet als een programma om pdf's te lezen is geïnstalleerd.
UC browser, Firefox en Google Chrome tonen de pdf met behulp van een ingebouwde pdf-lezer.
Windows 10
Internet Explorer 11 heeft een plug-in nodig om pdf te kunnen tonen.
Edge, UC browser, Firefox en Google Chrome tonen de pdf met behulp van een ingebouwde pdf-lezer.
Schermlezers
Van de geteste schermlezers leest alleen de combinatie NVDA/Firefox de pdf voor. VoiceOver en TalkBack negeren de pdf volledig.
Zoekmachines
Bij 'Fetchen als google' (ophalen zoals Google de pagina ziet), wordt de pdf volledig genegeerd.
Bij 'Als Bingbot ophalen' (ophalen zoals Bing de pagina ziet), wordt de pdf genegeerd. Bing negeert overigens ook de inhoud van de andere objecten.
Zoekmachines
Bij 'Fetchen als google' (ophalen zoals Google de pagina ziet), wordt de ingevoegde pdf genegeerd. Deze wordt dus vermoedelijk niet geïndexeerd door Google.
Bing
Bij 'Als Bingbot ophalen' (ophalen zoals Bing de pagina ziet), worden de ingevoegde bestanden genegeerd. Alleen de in de <object>'s zittende download-links zijn zichtbaar. Vermoedelijk worden de ingevoegde bestanden dus niet geïndexeerd door Bing.
Accenten in platte tekst veranderen in vreemde onzin
Tekst wordt in feite niet als tekst, maar als een soort codes opgeslagen. Tegenwoordig werkt elke browser en elke goede tekstverwerker met de codering utf-8. Platte tekst die je in een pagina wilt invoegen, moet worden opgeslagen in deze codering. Als je dat niet doet, is er een grote kans dat accenten en dergelijke in sommige browsers niet correct worden weergegeven.
Maar ook bij opslaan als utf-8 gaat het niet altijd goed. Kennelijk slaan niet alle programma's utf-8 helemaal foutloos op. Bij mij bijvoorbeeld slaat het simpele Medit accenten niet goed op, ook niet als wordt opgeslagen als utf-8. LibreOffice daarentegen doet het wel correct, als ik opsla als .txt-bestand.
Kortom: altijd testen of het goed wordt weergegeven.
(Dit probleem doet zich niet voor bij gewone westerse letters en cijfers zonder accenten en dergelijke, omdat deze in alle coderingen op dezelfde manier worden opgeslagen.)
Platte tekst op Windows Phone
UC browser en Internet Explorer op Windows Phone geven platte tekst niet weer. Wel wordt de download-link getoond.
Het shtml-bestand in de vierde <object> werkt niet
SSI (Server Side Includes) werkt alleen op een server, niet op de desktop. Je moet dit dus uitproberen op een server bij je hoster, of zelf een server installeren. Als je op internet zoekt naar LAMP (Linux), WAMP (Windows) of MAMP (OS X), vind je gratis te installeren servers.
Verder staan niet alle hosters het gebruik van SSI toe. Als je hoster het niet toestaat, heb je gewoon pech. Mogelijk kun je dan PHP in plaats van SSI gebruiken. PHP kan op precies dezelfde manier worden ingevoegd als SSI.
Wijzigingen
Alleen grotere wijzigingen worden hier vermeld, geen dingen als een link die is geüpdatet.
:
Nieuw opgenomen.
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.
tekst-108-dl.html: de pagina met het voorbeeld.
tekst-108.pdf: de uitleg (aangepast aan de inhoud van de download).
tekst-108-inhoud-download-en-licenties.txt: een kopie van de tekst onder dit kopje (Inhoud van de download en licenties).
108-css-dl:
tekst-108-dl.css: stylesheet voor tekst-108-dl.html.
108-files:
de in te voegen bestanden.
html.html: in te voegen html-bestand
pdf.pdf: in te voegen pdf-bestand
shtml.shtml: in te voegen shtml-bestand
tekst.txt: in te voegen tekst-bestand
De in de bestanden zittende gedichten mogen ongelimiteerd worden gebruikt. Ik ben ervan overtuigd dat deze literaire hoogtepunten bij een zorgvuldig geselecteerd, fijngevoelig publiek op literaire avonden zullen inslaan als een bom. Als ze niet inslaan als een bom, is het publiek kennelijk niet fijngevoelig en geselecteerd genoeg.
HTML
De code is geschreven in een afwijkende
lettersoort. De code die te maken heeft met de basis van dit voorbeeld (essentiële code), is in de hele uitleg onderstippeld blauw
. Alle niet-essentiële code is bruin
. (In de inhoudsopgave staat alles in een gewone letter vanwege de leesbaarheid.)
In de html hieronder wordt alleen de html besproken, waarover iets meer is te vertellen. Een <h1> bijvoorbeeld wordt in de regel niet genoemd, omdat daarover weinig interessants valt te melden. (Als bijvoorbeeld het uiterlijk van de <h1> wordt aangepast met behulp van css, staat dat verderop bij de bespreking van de css.)
Zaken als een doctype
en charset
hebben soms wat voor veel mensen onbekende effecten, dus daarover wordt hieronder wel een en ander geschreven.
Deze uitleg hoort bij het voorbeeld dat in de download zit. Het voorbeeld uit de download verschilt iets van het voorbeeld hier op de site. In de download ontbreekt bijvoorbeeld de navigatie voor de site. Ook in de kopregels zit vaak wat verschil. Daarnaast kunnen er nog andere (meestal kleine) verschillen zijn.
Als je deze uitleg leest naast de broncode van het voorbeeld op de site, kan het dus bijvoorbeeld zijn dat 'n <h1> uit de css bij 'n <h2> uit de html hoort. Maar het gaat niet om hele grote, fundamentele afwijkingen.
Als je dit lastig vindt, kun je bovenaan de pagina de hele handel downloaden. In de download zit 'n voorbeeld dat wel naadloos aansluit op de uitleg in de download.
<!DOCTYPE html>
Een document moet met een doctype beginnen om weergaveverschillen tussen browsers te voorkomen. Zonder doctype is de kans op verschillende (en soms volkomen verkeerde) weergave tussen verschillende browsers heel erg groot.
Geldige doctypes vind je op www.w3.org/QA/2002/04/valid-dtd-list.
Gebruik het volledige doctype, inclusief de eventuele url, anders werkt het niet goed.
Het hier gebruikte doctype is dat van html5. Dit kan zonder enig probleem worden gebruikt: het werkt zelfs in Internet Explorer 6.
<html lang="nl">
De toevoeging lang="nl"
bij <html> geeft aan dat de pagina in het Nederlands is. De taal is van belang voor schermlezers, automatisch afbreken, automatisch genereren van aanhalingstekens, juist gebruik van decimale punt of komma, en dergelijke.
<meta charset="utf-8">
Zorgt dat de browser letters met accenten en dergelijke goed kan weergeven.
utf-8 is de beste charset (tekenset), omdat deze alle talen van de wereld (en nog heel veel andere extra tekens) bestrijkt, maar toch niet meer ruimte inneemt voor de code, dan nodig is. Als je utf-8 gebruikt, hoef je veel minder entiteiten (ä
en dergelijke) te gebruiken, maar kun je bijvoorbeeld gewoon ä gebruiken.
Deze regel moet zo hoog mogelijk komen te staan, als eerste regel binnen de head, omdat hij anders door sommige browsers niet wordt gelezen.
In html5 hoeft deze regel niet langer te zijn, dan wat hier staat.
<meta name="viewport" content="width=device-width, initial-scale=1">
Mobiele apparaten variëren enorm in breedte. En dat is een probleem. Sites waren, in ieder geval tot voor kort, gemaakt voor desktopbrowsers. En die hebben, in vergelijking met bijvoorbeeld een smartphone, heel brede browservensters. Hoe moet je op 'n smartphone een pagina weergeven, die is gemaakt voor de breedte van een desktop? Je kunt natuurlijk wachten tot álle sites zijn omgebouwd voor smartphones, tablets, enz., maar dan moet je waarschijnlijk heel erg lang wachten.
Mobiele browsers gokken erop dat een pagina een bepaalde breedte heeft. Safari voor mobiel bijvoorbeeld gaat ervan uit dat een pagina 980 px breed is. De pagina wordt vervolgens zoveel versmald dat hij binnen het venster van het apparaat past. Op een iPhone wordt de pagina dus veel smaller dan op een iPad. Vervolgens kan de gebruiker inzoomen op het deel van de pagina dat hij of zij wil zien.
Dit betekent ook dat bij het openen van de pagina de tekst meestal heel erg klein wordt weergegeven. (Meestal, want niet alle browsers en apparaten doen het op dezelfde manier.) Niet erg fraai, maar bedenk maar 'ns 'n betere oplossing voor bestaande sites.
Nieuwe sites of pagina's kunnen echter wel rekening houden met de veel kleinere vensters van mobiele apparaten. Op deze pagina bijvoorbeeld wordt de breedte van de lijst aangepast aan de grootte van het venster, en ook de manier van openen van de officiële teksten wordt aangepast.
Maar die stomme mobiele browser weet dat niet, dus die gaat ervan uit dat ook deze pagina 980 px breed is, en verkleint die dan. Dat is ongeveer even behulpzaam als de gedienstige kelner die behulpzaam de stoel naar achteren trekt, net als jij wilt gaan zitten.
Om de door de browser aangeboden hulp vriendelijk maar beslist te weigeren, wordt deze tag gebruikt. Hiermee geef je aan dat de pagina is geoptimaliseerd voor mobiele apparaten.
Een iPad in portretstand bijvoorbeeld is 768 px breed. De kreet width=device-width
zegt tegen de mobiele browser dat de breedte van de weer te geven pagina gelijk is aan de breedte van het apparaat. Voor een iPad in portretstand dus 768 px.
Er staat nog een tweede deel in de tag: initial-scale=1
. Sommige mobiele apparaten zoomen een pagina gelijk in of uit. Ook weer in een poging behulpzaam te zijn. Ook dat is hier niet nodig. Er is ook een instructie om zoomen helemaal onmogelijk te maken, maar die gebruik ik niet. De bezoeker kan zelf nog gewoon zoomen, wat belangrijk is voor mensen die wat slechter zien.
<link rel="stylesheet" href="108-css-dl/tekst-108-dl.css">
Dit is een koppeling naar een externe stylesheet (stijlbestand), waarin de css staat. In html5 is de toevoeging type="text/css"
niet meer nodig, omdat dit standaard al zo staat ingesteld. Je moet uiteraard de naam van en het pad naar de stylesheet aanpassen aan de naam en plaats waar je eigen stylesheet staat.
Voordeel van een externe stylesheet is onder andere dat deze geldig is voor alle pagina's, waaraan deze is gelinkt. 'n Verandering in de lay-out hoef je dan maar in één enkele stylesheet aan te brengen, in plaats van in elke pagina apart. Op een grotere site kan dit ontzettend veel werk schelen. Bovendien hoeft de browser zo'n externe stylesheet maar één keer te downloaden, ongeacht hoeveel pagina's er gebruik van maken. Zou je de css in elke pagina opnieuw aanbrengen, dan worden de te downloaden bestanden veel groter.
In dit voorbeeld heeft een extern stylesheet eigenlijk nauwelijks nut, want er is maar één pagina. In dit geval kun je daarom de css beter in de <head> van de html-pagina zelf zetten.
Voor de omvang maakt het hier nauwelijks uit, want de css wordt hoe dan ook altijd precies één keer gedownload, en nooit vaker. Voor het onderhoud maakt het ook geen verschil, want je hoeft de css slechts op één plaats te wijzigen. Maar het scheelt wel een extra aanroep naar de server, omdat geen apart stylesheet hoeft te worden gedownload.
Dat opnemen in de <head> gaat heel simpel: je kopieert gewoon het hele stylesheet en zet die bovenin de <head> van het voorbeeld, tussen <style> en </style>:
<style>
body {color: black;}
(...) rest van de css (...)
div {color: red;}
</style>
Maar zodra een iets groter stylesheet op meerdere pagina's wordt gebruikt, wat meestal het geval zal zijn, is een extern stylesheet beter.
(De reden dat er toch een extern stylesheet is, terwijl ik hierboven omstandig beweer dat dat in dit voorbeeld eigenlijk geen nut heeft: overzichtelijkheid. Nu kun je html en css los van elkaar bekijken.)
<object data="108-files/tekst.txt" type="text/plain">
<a href="108-files/tekst.txt" download="Wonderschoon gedicht tekst.txt">Helaas, je browser ondersteunt geen weergave van gewone tekst in een object. Klik om dit wonderschone gedicht toch te kunnen genieten.</a>
</object>
Het ingevoegde bestand 'tekst.txt' is niet te zien in de gewone broncode. Om te zien hoe de browser dit bestand invoegt, moet je de Gegenereerde code bekijken.
Als op deze manier een bestand wordt ingevoegd, is het absoluut noodzakelijk de juiste css te gebruiken bij <object>. Zie hiervoor object. Zonder de juiste css kan (een deel van) het ingevoegde bestand volledig verdwijnen.
In dit <object> wordt een gewoon tekstbestand ingevoegd met de naam 'tekst.txt'. Een 'gewoon' tekstbestand bevat alleen tekst, zonder enige opmaakcode voor kleur, lettergrootte, of wat dan ook. Dit wordt ook wel 'platte tekst' genoemd.
Uitgebreide tekstverwerkers zoals LibreOffice of Word proppen een bestand helemaal vol met (onzichtbare) codes voor lettergrootte, kleur, tabellen, noem maar op. Dat soort teksten kan niet op deze manier worden weergegeven. Je kunt wel een tekstbestand maken met dit soort programma's, maar dan moet je het expliciet opslaan als tekstbestand, met de extensie '.txt'. Aan de extensie '.txt' herkennen programma's dat het hier om tekst zonder opmaak gaat.
Nieuwe regels en lege regels worden precies zo weergegeven, zoals ze in het tekstbestand zijn gemaakt. De inhoud van het hier gebruikte bestand 'text.txt' is:
ZEER GEVOELIG EN GOED LOPEND GEDICHT Als jij niet meer van mij houdt, heb ik het koud. O, wat deed ik fout? Is je hart dan écht van hout? Ik zal doen nooit meer stout, Omdat ik nog steeds van je houd.
Hoe deze tekst precies wordt weergegeven, wordt verder door de browser afgehandeld. Zelfs op de lettersoort heb je geen invloed.
De naam van het bestand wordt opgegeven met het attribuut data
. Daarin staan tussen aanhalingstekens pad naar en naam van het bestand: 108-files/tekst.txt
.
Hierachter wordt het soort bestand opgegeven. Dat doe je met een zogenaamd 'MIME-type': type="text/plain"
. Voor de schuine streep staat de hoofdsoort van het bestand, dat is hier 'text'. Achter de schuine streep staat de ondersoort. Dat is hier 'plain': gewone, simpele. ordinaire tekst zonder wat voor opmaak dan ook.
Als het ingevoegde bestand van een andere site afkomstig is, is het verstandig aan object het attribuut typeMustMatch
toe te voegen:
<object data="van-andere-site.txt" type="text/plain" typeMustMatch>
Dit attribuut controleert, of het soort bestand overeenkomt met het opgegeven type
, zodat er niet stiekem een script of zo kan worden uitgevoerd.
(Dit attribuut wordt nog nauwelijks ondersteund, maar het kan geen kwaad het al te gebruiken. Browsers die het niet kennen negeren het gewoon.)
Op Windows Phone kunnen UC browser en Internet Explorer op deze manier ingevoegde tekst niet weergeven. Als een browser het in data
opgegeven bestand niet kan tonen, wordt in principe de tekst die binnen <object> staat getoond. Dat is belangrijk, want niet elke browsers kan alle soorten bestanden tonen. Als hier niets wordt opgegeven, wordt niets getoond als het object niet kan worden weergegeven.
In dit geval staat er binnen <object> een download-link:
<a href="108-files/tekst.txt" download="Wonderschoon gedicht tekst.txt">Helaas, je browser ondersteunt geen weergave van gewone tekst in een object. Klik om dit wonderschone gedicht toch te kunnen genieten.</a>
Dit is een link naar het bestand. Hierdoor hebben gebruikers van Windows Phone de mogelijkheid om het bestand te downloaden, waarna ze het alsnog kunnen lezen. Althans: zo zou het moeten werken. In werkelijkheid tonen beide browsers na aanraken van de link de tekst gewoon in een nieuw venster. Maar hoe dan ook: het is, met 'n extra aanraking, te lezen.
download="Wonderschoon gedicht tekst.txt"
is een attribuut bij de link <a>. Als de browser dit attribuut al kent en daadwerkelijk gaat downloaden, wordt de naam die hier wordt opgegeven aan de download gegeven. In dit geval krijgt de download de naam 'Wonderschoon gedicht tekst.txt'. Zonder dit attribuut wordt de naam gewoon 'tekst.txt', wat een stuk minder duidelijk is. (Hoewel ik direct toegeef dat in dit geval de betiteling 'tekst' misschien een betere benaming is voor dit uit mijn hoogst persoonlijke dichtader voortgekomen gedrocht dan 'Wonderschoon gedicht'...)
<object data="108-files/html.html" type="text/html">
<a href="108-files/html.html">Helaas, je browser ondersteunt geen weergave van <abbr lang="en" title="HyperText Markup Language">html</abbr> in een object. Klik om dit wonderschone gedicht toch te kunnen genieten.</a>
</object>
Het ingevoegde bestand 'html.html' is niet te zien in de gewone broncode. Om te zien hoe de browser dit bestand invoegt, moet je de Gegenereerde code bekijken.
Als op deze manier een bestand wordt ingevoegd, is het absoluut noodzakelijk de juiste css te gebruiken bij <object>. Zie hiervoor object. Zonder de juiste css kan (een deel van) het ingevoegde bestand volledig verdwijnen.
In dit <object> wordt een gewoon html-bestand ingevoegd met de naam 'html.html'. Dit bestand staat op dezelfde site als het voorbeeld, maar dat hoeft niet: op deze manier kan ook een pagina van een andere site worden ingevoegd.
Het is een gewone html-pagina, dus alle normale html is aanwezig: <html>, <head>, <body>, enz. Voor de opmaak kan gewoon css worden gebruikt. Dat kan een <style> in de <head> zijn, maar ook een externe stylesheet. Precies zoals bij een gewone html-pagina.
De css van de 'hoofd'-pagina heeft geen invloed op de ingevoegde pagina, dus de ingevoegde html-pagina kan volledig zelfstandig worden opgemaakt.
Als in het ingevoegde html-bestand een link staat naar een andere pagina of site, wordt die link geopend in het object. De 'hoofd'-pagina blijft gewoon hetzelfde, alleen de inhoud van <object> veranderd.
Oftewel: de ingevoegde html-pagina heeft eigenlijk helemaal niets met de 'hoofd'-pagina te maken.
De inhoud van de hier ingevoegde html-pagina is:
<!DOCTYPE html> <html lang="nl"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <style> body {font-family: Arial, Helvetica, sans-serif; margin: 0; padding: 0;} h2 {font-size: 1.2em; font-weight: normal; text-align: center; margin: 5px 0;} p {text-align: center; margin: 5px 0 0;} </style> </head> <body> <h2>Van dezelfde begaafde dichter</h2> <p>Auwauwauwauwau<br> Die ellendige kou<br> Zonder jou<br> O, weerom kom toch gauw<br> Ik heb berouw<br> Waar blijf je nou</p> </body> </html>
De weergave van de ingevoegde pagina is in alle browsers (vrijwel) exact hetzelfde, omdat het uiterlijk met behulp van css in de ingevoegde pagina is bepaald.
De naam van het bestand wordt opgegeven met het attribuut data
. Daarin staan tussen aanhalingstekens pad naar en naam van het bestand: 108-files/html.html
.
Hierachter wordt het soort bestand opgegeven. Dat doe je met een zogenaamd 'MIME-type': type="text/html". Voor de schuine streep staat de hoofdsoort van het bestand, dat is hier 'text'. Achter de schuine streep staat de ondersoort. Dat is hier 'html': gewone, ambachtelijke html.
Als het ingevoegde bestand van een andere site afkomstig is, is het verstandig aan object het attribuut typeMustMatch
toe te voegen:
<object data="van-andere-site.html" type="text/html" typeMustMatch>
Dit attribuut controleert, of het soort bestand overeenkomt met het opgegeven type
, zodat er niet stiekem een script of zo kan worden uitgevoerd.
(Dit attribuut wordt nog nauwelijks ondersteund, maar het kan geen kwaad het al te gebruiken. Browsers die het niet kennen negeren het gewoon.)
In principe kunnen alle browsers met html binnen <object> goed uit de voeten. Maar voor het onwaarschijnlijke geval dat een browser (uit het stenen tijdperk of zo) niet met <object> overweg zou kunnen, wordt in <object> een link naar het ingevoegde html-bestand gezet. Als de browser de html-pagina niet weer kan geven, wordt nu deze link getoond.
Deze link hoort niet bij de ingevoegde html-pagina, maar is onderdeel van de <object> van de hoofdpagina. Daardoor wordt, bij klikken op deze link, de ingevoegde html-pagina in een nieuw venster geopend, precies zoals bij een gewone link.
Omdat geen enkele browser een ingevoegd html-bestand gaat downloaden, is het attribuut download
niet gebruikt in deze link.
<object id="drie" data="108-files/pdf.pdf" type="application/pdf">
<a href="108-files/pdf.pdf" download="Wonderschoon gedicht pdf.pdf">Helaas, je browser ondersteunt geen weergave van <abbr lang="en" title="Portable Document Format">pdf</abbr> in een een object. Klik om dit wonderschone gedicht toch te kunnen genieten.</a>
</object>
Het ingevoegde bestand 'pdf.pdf' is niet te zien in de gewone broncode. In sommige browsers is dit bestand, na enig zoeken, te zien in de Gegenereerde code bekijken. De meeste browsers geven het echter helemaal niet weer, ook niet in de gegenereerde code.
In de gegenereerde code van Firefox is het ingevoegde pdf-bestand wel te zien. Firefox heeft een ingebouwde pdf-viewer. In de gegenereerde code is die volledige pdf-viewer ook te zien, en diep daarbinnen begraven kun je de tekst van de pdf vinden.
Als het ingevoegde bestand van een andere site afkomstig is, is het verstandig aan object het attribuut typeMustMatch
toe te voegen:
<object data="van-andere-site.pdf" type="application/pdf" typeMustMatch>
Dit attribuut controleert, of het soort bestand overeenkomt met het opgegeven type
, zodat er niet stiekem een script of zo kan worden uitgevoerd.
(Dit attribuut wordt nog nauwelijks ondersteund, maar het kan geen kwaad het al te gebruiken. Browsers die het niet kennen negeren het gewoon.)
Omdat veel browsers een pdf onvolledig of helemaal niet weergeven, is dit absoluut geen goede manier om een pdf in te voegen. Daarom ga ik er niet verder op in. Waarom dit geen goede manier is, kun je vinden bij Bekende problemen (en oplossingen).
Voor de volledigheid vermeld ik wel nog even het MIME-type achter type
. De hoofdsoort is 'application', de ondersoort 'pdf'. 'application' betekent 'toepassing': er is een toepassing, een programma, nodig om het bestand weer te kunnen geven. Dit is ook gelijk de oorzaak van alle problemen: het weergeven van een pdf is niet ingebouwd in de browser. Zelfs in Firefox is het niet echt helemaal ingebouwd, ook daarin wordt een enorme berg extra JavaScript, html, css en wie weet wat nog meer aangeroepen om die paar flutregeltjes, pardon, dat wonderschone gedicht, weer te geven.
<object id="vier" data="108-files/shtml.shtml" type="text/html">
<abbr>SSI</abbr> werkt alleen vanaf een server. Je moet deze pagina dus bekijken op de server van je hoster, of zelf een server installeren.<br>
<a href="108-files/shtml.shtml">Klik hier om het bestand in een nieuw venster te openen (werkt ook alleen op een server).</a>
</object>
Het ingevoegde bestand is hier een shtml-bestand. De extensie 'shtml' hoort bij Server Side Includes (SSI). Dit soort bestanden moet eerst op een server worden verwerkt, waarna het resultaat van die bewerking naar de browser wordt gestuurd. De browser zelf kan niets met een shtml-bestand.
Als alle bestanden gewoon op een desktop staan, kan het shtml-bestand nooit worden getoond: er mist een server om de SSI te verwerken. Je krijgt dan altijd de in <object> zittende tekst te zien.
Om de inhoud van het shtml-bestand te zien, moet je de pagina openen op de server van je hoster. Je kunt ook zelf een server installeren. Als je zoekt naar LAMP (Linux), WAMP (Windows) of MAMP (OS X) vind je 'n gratis server.
Niet elke hoster staat het gebruik van SSI toe. Als je hoster het verbiedt, heb je pech gehad. In plaats van SSI kun je ook PHP gebruiken. Dat kan op precies dezelfde manier worden ingevoegd: alles wat hier over SSI en shtml wordt geschreven, geldt precies hetzelfde voor PHP en pagina's met als extensie 'php' in plaats van 'shtml'. (De commando's die worden uitgevoerd zijn natuurlijk wel verschillend, want het zijn twee totaal verschillende talen. Als je een Russisch commando aan een Chinees geeft, zal die dat meestal ook niet begrijpen.)
Ook als je de pagina op een server opent, is het ingevoegde bestand 'shtml.shtml' niet te zien in de gewone broncode. Om te zien hoe de browser dit bestand invoegt, moet je de Gegenereerde code bekijken.
Als op deze manier een bestand wordt ingevoegd, is het absoluut noodzakelijk de juiste css te gebruiken bij <object>. Zie hiervoor object. Zonder de juiste css kan (een deel van) het ingevoegde bestand volledig verdwijnen.
In dit <object> wordt een shtml-bestand ingevoegd met de naam 'shtml.shtml'. Dit bestand wordt op de server verwerkt, waarna de server gewone html naar de browser stuurt. De browser ziet dus alleen gewone html.
In principe kunnen alle browsers met html binnen <object> goed uit de voeten. Maar voor het onwaarschijnlijke geval dat een browser (uit het stenen tijdperk of zo) niet met <object> overweg zou kunnen, wordt in <object> een link naar het ingevoegde shtml-bestand gezet. Als de browser het shtml-bestand niet weer kan geven, wordt nu deze link getoond.
Deze link hoort niet bij het ingevoegde shtml-bestand, maar is onderdeel van de <object> van de hoofdpagina. Daardoor wordt, bij klikken op deze link, het ingevoegde shtml-bestand in een nieuw venster geopend, precies zoals bij een gewone link.
Omdat geen enkele browser een ingevoegd shtml-bestand gaat downloaden, is het attribuut download
niet gebruikt in deze link.
Als in het ingevoegde shtml-bestand een link staat naar een andere pagina of site, wordt die link geopend in het object. De 'hoofd'-pagina blijft gewoon hetzelfde, alleen de inhoud van <object> veranderd.
Oftewel: het ingevoegde shtml-bestand heeft eigenlijk helemaal niets met de 'hoofd'-pagina te maken.
De inhoud van het hier ingevoegde shtml-bestand is:
<!--#config timefmt="%H uur %M" --> Deze pagina is geopend om <!--#echo var="DATE_LOCAL" -->.<br> <hr> Je browser geeft de volgende identificatie door:<br> <!--#echo var="http_user_agent" -->
De weergave van de ingevoegde pagina is in alle browsers (vrijwel) exact hetzelfde, omdat dit door de server wordt omgezet naar gewone html.
De naam van het bestand wordt opgegeven met het attribuut data
. Daarin staan tussen aanhalingstekens pad naar en naam van het bestand: 108-files/shtml.shtml
.
Hierachter wordt het soort bestand opgegeven. Dat doe je met een zogenaamd 'MIME-type': type="text/html"
. Voor de schuine streep staat de hoofdsoort van het bestand, dat is hier 'text'. Achter de schuine streep staat de ondersoort. Dat is hier 'html': gewone, ambachtelijke html. Het is weliswaar een shtml-bestand, maar na de verwerking door de server is dat veranderd in gewone html. De browser heeft er geen enkel benul van dat het eigenlijk geen html, maar shtml is.
Als het ingevoegde bestand van een andere site afkomstig is, is het verstandig aan object het attribuut typeMustMatch
toe te voegen:
<object data="van-andere-site.shtml" type="text/html" typeMustMatch>
Dit attribuut controleert, of het soort bestand overeenkomt met het opgegeven type
, zodat er niet stiekem een script of zo kan worden uitgevoerd.
(Dit attribuut wordt nog nauwelijks ondersteund, maar het kan geen kwaad het al te gebruiken. Browsers die het niet kennen negeren het gewoon.)
Wat is nou het nut van het op deze manier invoegen van een bestand met daarin de meest gruwelijke wartaal?
Als je SSI wilt gebruiken, moet de pagina als extensie geen 'html', maar 'shtml' krijgen. Daardoor weet de server dat de pagina apart behandeld moet worden. Bij bestaande pagina's die op 'html' eindigen, kan dat problemen opleveren. Als je 'html' in 'shtml' verandert, moet je ook alle links naar die pagina aanpassen. Of je moet met ingewikkelde verwijzingen gaan werken.
Voor grote hoeveelheden SSI (of PHP, daarvoor geldt hetzelfde) is het verreweg het beste de extensie te veranderen. De server maakt er dan één gewone html-pagina van, en dat is voor zoekmachines, schermlezers, en dergelijke verreweg het beste. Omdat de server er één pagina van maakt, is het resultaat precies hetzelfde als wanneer één samenhangende html-pagina zou zijn gemaakt.
Het is ook makkelijker om problemen in de code op te sporen en de code te onderhouden, omdat de Gegenereerde code de complete code weergeeft, en niet alleen <object> of juist het omgekeerde: allerlei door de browser toegevoegde fantasie-html.
Maar voor kleinere stukjes SSI is dit wel bruikbaar. Door het shtml-bestand in te voegen met behulp van <object>, behandelt de server het ingevoegde shtml-bestand als SSI. Terwijl de hoofdpagina gewoon de extensie 'html' kan houden. SSI (en vooral PHP) hebben mogelijkheden die gewone html niet heeft. Op deze manier kunnen die extra mogelijkheden gebruikt worden, zonder dat een extensie veranderd hoeft te worden.
In het ingevoegde shtml-bestand zijn een paar SSI-commando's gebruikt. Dit is geen handleiding over SSI, dus andere commando's dan die hier zijn gebruikt komen niet aan de orde. En ook de gebruikte commando's worden niet uitgebreid besproken. Over SSI (en PHP) is meer te vinden op de pagina met links.
Nog één opmerking: bij SSI is een juist gebruik van spaties belangrijk. Als er bijvoorbeeld tussen <
en !
aan het begin van het commando een spatie staat, werkt het commando niet.
Het ingevoegde shtml-bestand regel voor regel:
<!--#config timefmt="%H uur %M" -->
Dit is een SSI-opdracht. In gewone mensentaal staat er dat timefmt (de manier waarop de tijd wordt getoond) moet worden geconfigureerd, aangepast. Hier wordt opgegeven dat het aantal uren in cijfers van 0 tot 23 moet worden weergegeven, gevolgd door ' uur ' (spatie uur spatie), gevolgd door het aantal minuten in cijfers.
Omdat hier alleen wordt opgegeven hoe het eruit gaat zien, is daar nog niets van te zien op het scherm. Dat wordt gelijk hieronder geregeld.
Bij SSI is een juist gebruik van spaties belangrijk. Als er bijvoorbeeld tussen <
en !
aan het begin van het commando een spatie staat, werkt het commando niet.
Deze pagina is geopend om <!--#echo var="DATE_LOCAL" -->.<br>
Letterlijke tekst wordt gewoon letterlijk getoond. 'Deze pagina is geopend om ' wordt precies zo op het venster gezet.
Daarachter wordt met behulp van echo
opdracht gegeven iets speciaals te tonen: de variabele DATE_LOCAL
. Dat is de lokale datum. (Je kunt ook de UTC, de wereldtijd weergeven. Vroeger heette die GMT, Greenwich Mean Time.)
De weergave van die datum is in de regel hierboven aangepast tot aantal uren, gevolgd door ' uur ', gevolgd door het aantal minuten. Omdat in de regel hierboven geen dag of zo is opgegeven, komt die niet in de datum voor.
(Overigens kun je met SSI namen van dagen en dergelijke alleen in het Engels weergeven. Het kán wel in een andere taal worden weergegeven, maar dat is veel extra werk. PHP heeft wat dat betreft veel meer mogelijkheden.)
Aan het eind van de regel staan nog een punt en <br>
. De punt wordt letterlijk getoond, de <br>
zorgt voor een nieuwe regel, net als in gewone html.
Het uiteindelijke resultaat van deze twee regels:
Deze pagina is geopend om 16 uur 31.
(Het tijdstip dat jij ziet is hoogstwaarschijnlijk natuurlijk niet precies 16 uur 31...)
Je kunt ook met behulp van een inline-stijl css gebruiken. Als je deze regel verandert in:
<span style="color: red;">Deze pagina is geopend om <!--#echo var="DATE_LOCAL" -->.</span><br>
wordt de tekst in rood weergegeven.
<hr>
Html in een shtml-bestand wordt door de browser gewoon uitgevoerd. Dit levert een horizontale regel op.
Je browser geeft de volgende identificatie door:<br>
Dit is weer letterlijke tekst, die precies zo wordt weergegeven. Aan het eind staat een <br>
, die voor een nieuwe regel zorgt.
<!--#echo var="http_user_agent" -->
Met behulp van echo
wordt opdracht gegeven de variabele http_user_agent
te tonen. Dat is de identificatiecode die je browser naar de server verstuurt. Deze is voor elke browser en elke besturingssysteem anders. In Firefox op Linux, waar ik het meest mee werk, is het bij mij:
Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:43.0) Gecko/20100101 Firefox/43.0
Het totaal ziet er als volgt uit (links Google Chrome op Linux, rechts Firefox op Linux):
Als je nog nooit zo'n 'user agent string' hebt gezien, ben je misschien wat verbaasd over de linker van Google Chrome. Die liegt zo'n beetje alles bij elkaar: Mozilla, AppleWebKit, KHTML en Safari. Dat doet echter vrijwel elke browser. Het zijn restanten uit de tijd dat browsers elkaar op leven en dood bevochten en sites vaak alleen maar voor één bepaalde browser toegankelijk waren. Door zich voor te doen als een andere browser, kon een site dan toch bekeken worden. Hoe het verder precies zit, weet ik eerlijk gezegd niet meer, want het gebruik van dit soort identificatiecodes is een volstrekt verouderde (en volstrekt onbetrouwbare) techniek.
CSS
De code is geschreven in een afwijkende
lettersoort. De code die te maken heeft met de basis van dit voorbeeld (essentiële code) is in de hele uitleg onderstippeld blauw
. Alle niet-essentiële code is bruin
. (In de inhoudsopgave staat alles in een gewone letter vanwege de leesbaarheid.)
Deze uitleg hoort bij het voorbeeld dat in de download zit. Het voorbeeld uit de download verschilt iets van het voorbeeld hier op de site. In de download ontbreekt bijvoorbeeld de navigatie voor de site. Ook in de kopregels zit vaak wat verschil. Daarnaast kunnen er nog andere (meestal kleine) verschillen zijn.
Als je deze uitleg leest naast de broncode van het voorbeeld op de site, kan het dus bijvoorbeeld zijn dat 'n <h1> uit de css bij 'n <h2> uit de html hoort. Maar het gaat niet om hele grote, fundamentele afwijkingen.
Als je dit lastig vindt, kun je bovenaan de pagina de hele handel downloaden. In de download zit 'n voorbeeld dat wel naadloos aansluit op de uitleg in de download.
Technisch gezien is er geen enkel bezwaar om de css in de stylesheet allemaal achter elkaar op één regel te zetten:
div#header-buiten {position: absolute; right: 16px; width: 100%; height: 120px; background: yellow;} div p {margin-left 16px; height: 120px; text-align: center;}
Maar als je dat doet, garandeer ik je hele grote problemen, omdat het volstrekt onoverzichtelijk is. Beter is het om de css netjes in te laten springen:
div#header-buiten {
position: absolute;
right: 16px;
width: 100%;
height: 120px;
background: yellow;
}
div p {
margin-left: 16px;
height: 120px;
text-align: center;
}
Hiernaast is het heel belangrijk voldoende commentaar (uitleg) in de stylesheet te schrijven. Op dit moment weet je waarschijnlijk (hopelijk...), waarom je iets doet. Maar over vijf jaar kan dat volstrekt onduidelijk zijn. Op deze site vind je nauwelijks commentaar in de stylesheets, maar dat heeft een simpele reden: deze uitleg is in feite één groot commentaar.
Op internet zelf is het goed, als de stylesheet juist zo klein mogelijk is. Dus voor het uploaden kun je normaal genomen het beste het commentaar weer verwijderen. Veel mensen halen zelfs alles wat overbodig is weg, voordat ze de stylesheet uploaden. Inspringingen bijvoorbeeld zijn voor mensen handig, een computer heeft ze niet nodig.
Je hebt dan eigenlijk twee stylesheets. De uitgebreide versie waarin je dingen uitprobeert, verandert, 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
/* tekst-108-dl.css */
Om vergissingen te voorkomen is het een goede gewoonte bovenaan het stijlbestand even de naam neer te zetten. Voor je het weet, zit je anders in het verkeerde bestand te werken.
body
Het element waarbinnen de hele pagina staat. Veel instellingen die hier worden opgegeven, worden geërfd door de nakomelingen van <body>. Ze gelden voor de hele pagina, tenzij ze later worden gewijzigd. Dit geldt bijvoorbeeld voor de lettersoort, de lettergrootte en de voorgrondkleur.
background: #ff9;
Achtergrondkleurtje.
color: black;
Voorgrondkleur zwart. Dit is onder andere de kleur van de tekst.
Hoewel dit de standaardkleur is, geef ik de kleur toch op. Hierboven heb ik 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.
max-width: 900px;
In bredere browservensters worden twee <object>'s naast elkaar gezet. Met het opgeven van een maximumbreedte wordt voorkomen dat deze op brede vensters onwijs ver uit elkaar komen te staan.
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).
margin: 0 auto;
Omdat voor onder en links geen waarde is opgegeven, krijgen die 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. <body> staat dus altijd horizontaal gecentreerd binnen z'n ouder, ongeacht de breedte van die ouder.
De ouder van <body> is <html>. <html> is het buitenste element. Omdat <html> geen breedte heeft gekregen, wordt <html> automatisch even breed als het venster van de browser. Omdat <body> horizontaal gecentreerd staat binnen <html>, staat <body> hierdoor automatisch horizontaal gecentreerd binnen het venster, ongeacht de breedte van het venster.
(Dit heeft uiteraard alleen effect in browservensters die breder zijn dan de even hierboven aan <body> gegeven maximumbreedte van 900 px. In smallere vensters vult <body> gewoon het hele venster.)
Deze manier van centreren van een blok-element werkt alleen, als het te centreren blok-element een breedte heeft.
Verschillende browsers hebben verschillende standaardinstellingen voor de marge bij <body>. Door de marge zelf op te geven, zijn deze verschillen ook gelijk weggewerkt.
padding: 0;
Verschillende browsers hebben verschillende standaard-instellingen hiervoor. Door ze gewoon op 0 te zetten, zijn ze overal hetzelfde.
h1, h2
Alle <h1>'s en <h2>'s.
Bovenaan de pagina staat een <h1> met de knop van de pagina.
Boven elk <object> staat een <h2> met de inhoud van het <object>.
font-size: 1em;
Standaard hebben <h1> en <h2> een (veel) grotere letter. Hier wordt dat veranderd in de standaardlettergrootte.
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.
h2
Voor deze elementen geldt ook de eerder bij h1, h2 opgegeven css.
Alle <h2>'s. Boven elk <object> staat een <h2> met de inhoud van het <object>.
margin-bottom: 0;
Standaard heeft een <h2> een marge aan boven- en onderkant. De marge aan de onderkant wordt hier verwijderd.
object
Alle <object>'s. Dat zijn er hier vier: één voor elk in te voegen bestand.
De ingevoegde bestanden zijn niet te zien in de gewone broncode. Afhankelijk van het soort bestand en de browser zijn ze soms te zien in de Gegenereerde code.
De inhoud van <object>, het ingevoegde bestand, staat los van de pagina, waarin <object> zit. Daardoor heeft de css die voor de pagina met de <object>'s wordt opgegeven geen enkele invloed op de weergave van het ingevoegde bestand.
Maar <object> zelf is wel een onderdeel van de pagina. <object> zelf kan daardoor wel gewoon met behulp van css worden aangepast.
(Bij de bestanden met html en SSI kun je de weergave van het ingevoegde bestand binnen <object> aanpassen met css. Die css staat gewoon binnen het ingevoegde bestand, of is daaraan gekoppeld. Hoe dat kan, staat bij <object data="108-files/html.html" type="text/html"> voor html en bij <object id="vier" data="108-files/shtml.shtml" type="text/html"> voor SSI.
Een pdf-bestand kan ook een eigen opmaak krijgen, maar dat heeft verder niets met css te maken. Bovendien is invoegen van een pdf op deze manier een slecht idee. Dus op pdf ga ik verder niet in.)
background: white;
Witte achtergrond. Dit is de achtergrondkleur van <object>.
Bij html en SSI kan het ingevoegde bestand een eigen achtergrondkleur krijgen. In dat geval 'wint' de achtergrondkleur van het ingevoegde bestand.
display: block;
Een <object> is van zichzelf een inline-element. Weliswaar een wat apart inline-element, net zoals bijvoorbeeld <img>, maar het blijft een inline-element. Daardoor kunnen sommige eigenschappen voor blok-elementen niet worden gebruikt. Door er een blok-element van te maken, kan dit soort eigenschappen wel worden gebruikt.
height: 10em;
Hoogte.
UC browser op Android, Android browser en alle browsers op iOS negeren inhoud, die niet binnen <object> past. Deze inhoud kan ook niet via scrollen worden bereikt. Daarom is het absoluut noodzakelijk aan <object> een hoogte te geven die groot genoeg is om de volledige inhoud weer te geven. Als tekst en dergelijke niet binnen de <object> past, verdwijnt dit gewoon en is op geen enkele manier nog te bekijken.
Een breedte wordt niet opgegeven, omdat browsers een standaardbreedte aan <object> geven, als geen breedte is opgegeven. Die standaardbreedte is hier in alle gevallen breed genoeg voor de ingevoegde bestanden, omdat die allemaal heel smal zijn.
margin: 0 auto;
Omdat voor onder en links geen waarde is opgegeven, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 0 auto 0 autoM
in de volgorde boven – rechts – onder – links. Boven en onder geen marge. Links en rechts auto
, wat hier hetzelfde betekent als evenveel.
De ouder van <object> is een <div>. Een <div> is een blok-element en wordt daardoor, tenzij anders is opgegeven, automatisch even breed als z'n ouder. De ouder van <div> is <body>, ook een blok-element. <body> wordt dus ook weer even breed als z'n ouder. De ouder van <body> is <html>. <html> is het buitenste element.
Omdat ook <html> geen breedte heeft gekregen, wordt <html> automatisch even breed als het venster van de browser. En daarmee <body> en <div> ook. Omdat <object> horizontaal gecentreerd staat binnen <div>, staat <object> hierdoor automatisch ook horizontaal gecentreerd binnen het venster, ongeacht de breedte van het venster.
Deze manier van centreren van een blok-element werkt alleen, als het te centreren blok-element een breedte heeft. <object> heeft geen breedte gekregen, dus zou dit niet werken. Maar omdat browsers aan <object> zonder breedte een standaardbreedte geven, werkt het het toch.
border: black solid 1px;
Zwart randje.
padding: 0 5px;

Omdat voor onder en links geen waarde is opgegeven, krijgen die automatisch dezelfde waarde als boven en rechts. Hier staat dus eigenlijk 0 5px 0 5px
in de volgorde boven – rechts – onder – links.
Deze padding staat los van een eventuele padding in het ingevoegde bestand. Op de afbeelding is de padding links en rechts even verhoogd tot 25 px, zodat het duidelijker is te zien. Het ingevoegde html-bestand heeft een rode achtergrondkleur gekregen.
Het rood op de afbeelding is even breed als het ingevoegde bestand, want in het ingevoegde html-bestand staat body {background: red;}
. Het rood geldt dus alleen voor de <body> van het ingevoegde bestand.
De witte strook links en rechts is de hierboven opgegeven padding. Deze zorgt alleen voor wat afstand tussen de buitenkant van <object> en het ingevoegde bestand. Er is geen enkele invloed op het ingevoegde bestand zelf.
#drie, #vier
Voor deze elementen geldt ook de eerder bij object opgegeven css, voor zover die hier niet wordt gewijzigd.
De elementen met id="drie" en id="vier". Dit zijn de derde en vierde <object>.
De ingevoegde bestanden zijn niet te zien in de gewone broncode. Afhankelijk van het soort bestand en de browser zijn ze soms te zien in de Gegenereerde code.
height: 13em;
Hier iets boven hebben de <object>'s een hoogte van 10 em gekregen. Dat is te weinig voor de bestanden die in het derde en vierde object worden ingevoegd. Daarom wordt die hoogte hier vergroot.
UC browser op Android, Android browser en alle browsers op iOS negeren inhoud, die niet binnen <object> past. Deze inhoud kan ook niet via scrollen worden bereikt. Daarom is het absoluut noodzakelijk aan <object> een hoogte te geven die groot genoeg is om de volledige inhoud weer te geven. Als tekst en dergelijke niet binnen de <object> past, verdwijnt dit gewoon en is op geen enkele manier nog te bekijken.
Een breedte wordt niet opgegeven, omdat browsers een standaardbreedte aan <object> geven, als geen breedte is opgegeven. Die standaardbreedte is hier in alle gevallen breed genoeg voor de ingevoegde bestanden, omdat die allemaal heel smal zijn.
css voor vensters minimaal 750 px breed
@media screen and (min-width: 750px)
De css die hier tot nu toe staat, geldt voor alle browservensters.
De css die binnen deze media query staat, geldt alleen voor vensters die minimaal 750 px breed zijn. In deze bredere vensters worden twee <object>'s naast elkaar gezet.
@media
: geeft aan dat het om css gaat, die alleen van toepassing is, als aan bepaalde voorwaarden wordt voldaan. Al langer bestond de mogelijkheid om met behulp van zo'n @media-regel css voor bijvoorbeeld printers op te geven. css3 heeft dat uitgebreid tot bepaalde fysieke eigenschappen, zoals de breedte en hoogte van het venster van de browser.
screen
: deze regel geldt alleen voor schermweergave.
and
: er komt nog een voorwaarde, waaraan moet worden voldaan.
(min-width: 750px)
: het venster moet minimaal 750 px breed zijn. Is het venster smaller, dan wordt de css die binnen deze media-regel staat, genegeerd.
Gelijk na deze regel komt een {
te staan, en aan het einde van de css die binnen deze regel valt een bijbehorende afsluitende }
. Die zijn in de regel hierboven weggevallen, maar het geheel ziet er zo uit:
@media screen and (min-width: 750px) {
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 }
.
div
Alle <div>'s. Elk <object> met bijbehorende <h2> staat binnen een <div>
width: 50%;
Breedte. Een breedte in procenten wordt altijd genomen ten opzichte van de ouder van het element. Dat is hier <body>. Elke <div> vult dus de halve breedte van <body>.
Bij object zijn de in de <div> zittende <object>'s met margin: 0 auto;
horizontaal gecentreerd binnen de <div>. Omdat elke <div> de helft van <body> vult, staan de <object>'s hierdoor netjes horizontaal over de pagina verdeeld.
float: left;
Een <div> is een blok-element, waardoor het normaal genomen op een nieuwe regel wordt neergezet. Door de <div>'s naar links te floaten, worden ze zo hoog mogelijk en dan zoveel mogelijk naar links neergezet.
Omdat hierboven aan de <div>'s een breedte van 50% is opgegeven, passen er altijd precies twee naast elkaar. Een derde <div> past niet meer op dezelfde regel, want dan zou de breedte 150% van de ouder bedragen, en dat kan niet. Je kunt je ligbad ook niet 150% van de breedte van je badkamer geven. Een derde <div> wordt dus gewoon op een nieuwe regel gezet.
h1, h2
Alle <h1>'s en <h2>'s.
Bovenaan de pagina staat een <h1> met de knop van de pagina.
Boven elk <object> staat een <h2> met de inhoud van het <object>
font-size: 1.3em;
<h1> en <h2> hebben van zichzelf een (veel) grotere letter. Eerder is die lettergrootte hetzelfde gemaakt als de standaardlettergrootte. Omdat in bredere browservensters meer ruimte is, wordt de lettergrootte hier weer iets 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.
font-weight: normal;
<h>'s zijn van zichzelf vet. Omdat deze pagina vrij leeg is, wekt een vette letter de indruk van de aankondiging van de Derde Wereldoorlog in De Telegraaf. Aangezien een Derde Wereldoorlog me niet zo leuk lijkt en ik De Telegraaf nog minder leuk vind, wordt de vette letter in een normale veranderd.