Wat is het beste doctype? En waarom is dat zo? En hoe is dat zo gekomen? En waarom...? Daarom!
Laatst aangepast: .
www.css-voorbeelden.nl
Op de pagina met links vind je mogelijk sites, die dieper op bepaalde onderwerpen ingaan.
Als je dit artikel afdrukt, wordt automatisch een printvriendelijke versie afgedrukt.
Dit artikel is van toepassing op alle browsers op alle systemen.
Links in dit artikel, vooral links naar andere sites, kunnen verouderd zijn. Op de pagina met links vind je steeds de meest recente links.
Tekst die tussen << en >> staat, is een link naar internet.
Tekst die omgeven is door een lijn (meestal een stippellijn), verwijst naar een andere plaats binnen het artikel. Op de site zijn dit ankers, maar dat werkt nou eenmaal niet op papier.
WAARSCHUWING
Als je gaat sleutelen aan het doctype van een bestaande pagina, kun je de weergave van de pagina volledig verpesten. In het ergste geval kan de pagina zelfs geheel of gedeeltelijk verdwijnen. Dit hoeft niet in elke browser te gebeuren, waardoor het nog riskanter wordt: in jouw browser is alles prima in orde, in een andere browser is de hele pagina verdwenen.
Als je een doctype wilt toevoegen of wijzigen, lees dan op z'n minst het eerste deel van onderstaande tekst. En test de gewijzigde pagina in zoveel mogelijk verschillende browsers en systemen.
Wat moet ik lezen?
Als je geïnteresseerd bent in de meer theoretische achtergronden, het ontstaan van het doctype, enz., kun je daar lager op de pagina bij Het hoe en waarom van een doctype meer over lezen. Als je alleen maar een doctype wilt kiezen, zou ik in ieder geval Waar is een doctype voor? en Welk doctype is geschikt? lezen.
Waar is een doctype voor?
Een doctype hoort op de allereerste regel van de html te staan. Héél kort samengevat: het zorgt er voor dat een pagina volgens de standaard wordt weergegeven. Meer niet. Er worden tal van wonderbaarlijke krachten toegedicht aan het doctype, zoals het weergeven volgens een bepaalde html-versie, maar die verhalen zijn onjuist. Het doctype heeft nooit meer gedaan, dan werken als een soort aan-uitschakelaar voor de weergave volgens de standaard of niet. Voor iets anders is het nooit bedoeld geweest.
Het doctype heeft ook helemaal niets met de gebruikte html of css te maken. Je kunt prima html 4.01 en css3 gebruiken, of html5 en css2. Je kunt zelfs, als je maar masochistisch genoeg bent, html2 met css3 gebruiken.
Voor een goede werking moet het volledige doctype worden gebruikt. Bij oudere doctypes staat in de tweede helft een url (internet-adres). Als je dat weglaat, werkt het doctype vaak niet of niet volledig. Maar zodra je een juist en volledig doctype bovenaan de pagina hebt staan, maakt het voor de weergave niets uit, welk doctype je gebruikt.
(Met uitzondering van de doctypes voor frames, maar frames zijn zwaar verouderd en worden al zo'n tien jaar afgeraden, dus daar ga ik verder niet op in. In html5 zijn ze gewoon helemaal verboden, dus frames zijn hoe dan ook een doodlopende weg.)
Welk doctype je gebruikt, is wel uitermate belangrijk voor het valideren van je code. Valideren is het nalopen op syntactische fouten in de code. Syntactische fouten zijn overtredingen van de syntaxis, de 'spellingregels', van de taal: een typefout in een tag, verkeerd nesten, dat soort dingen. Dat soort fouten kan voor de wildste problemen zorgen. Een fout bovenin de pagina kan zorgen voor het verdwijnen van iets onderaan de pagina, bijvoorbeeld. Die problemen hoeven ook nog 'ns niet in elke browser hetzelfde te zijn. Valideren is daarom enorm belangrijk.
Als je een doctype voor html 4.01 gebruikt, wordt volgens die versie van html gevalideerd. Elementen uit latere versies van html leveren dan een fout op.
Als je een doctype voor html5 (of later) gebruikt, worden allerlei dingen die bij bepaalde oudere versies nog waren toegestaan, nu als een fout aangemerkt.
Welk doctype is geschikt?
Welk doctype geschikt is, hangt er grotendeels vanaf, of het om een bestaande of om een nieuwe pagina gaat. Een 'pagina': je kunt verschillende pagina's in een site prima verschillende doctypes geven, daar is niets op tegen. Nieuwe pagina's die worden toegevoegd aan een bestaande site, kun je dus probleemloos het nieuwste doctype geven. Oudere pagina's kunnen dan gewoon een ouder doctype blijven gebruiken, als dat beter uitkomt.
Nieuwe pagina's
Voor een nieuwe pagina is eigenlijk nog maar één doctype zinvol:
<!doctype html>
Langer hoeft niet. Je mag dit in hoofd- of kleine letters schrijven, net wat je prettig vindt. Het doctype moet de allereerste regel van de code zijn.
In dit doctype staat geen versienummer van de html meer. Dat staat in oudere doctypes wel, maar dat slaat eigenlijk nergens op, omdat het doctype alleen als aan-uitschakelaar voor de standaardweergave werkt. Dit is het kortste doctype dat die werking ook heeft, zelfs in een gruwel als Internet Explorer 6.
Dit doctype maakt het mogelijk om alle nieuwigheden van html5 (en toekomstige versies) te gebruiken, voor zover de browser die heeft geïmplementeerd. Als de browser iets niet heeft geïmplementeerd, is er niets aan de hand: het wordt dan gewoon genegeerd.
Alle tags voor opmaak, zoals <font>, worden bij dit doctype door de validator als een fout aangemerkt. En terecht, want dat soort tags wordt al meer dan tien jaar afgeraden. Opmaak hoort met behulp van css te gebeuren. Dat is makkelijker, beter te onderhouden, toegankelijker voor schermlezers en zoekmachines, levert kleinere bestanden op, en nog 398 andere voordelen.
Bestaande pagina's die niet worden veranderd
Als een bestaande pagina goed werkt en je gaat er niets aan veranderen: in principe lekker zo laten. Waarom zou je aan een bestaande pagina gaan sleutelen, als het goed wordt weergegeven in alle browsers?
Als er een juist en volledig doctype aanwezig is, zullen alle browsers het volgens de standaard weergeven. Min of meer, want hoe ouder de browser, hoe meer bugs en afwijkingen van de standaard. (Dat speelt eigenlijk alleen voor oudere versies van Internet Explorer. Microsoft is de enige browsermaker die, om welke idiote reden dan ook, weigert z'n browsers bij te werken, op beveiligings-updates na.)
Als er geen doctype aanwezig is, is de pagina behoorlijk oud óf de pagina is volkomen amateuristisch gemaakt. Maar ook in dat geval is er geen reden iets te veranderen. Zonder doctype wordt de pagina gewoon niet volgens de standaard weergegeven, maar in de zogenaamde 'quirks modus' (Engels: 'quirks mode', 'rariteiten' mode). Deze modus is niet in alle browsers exact hetzelfde, maar in grote lijnen wel. Ga je een doctype toevoegen of wijzigen, dan wordt de pagina plotsklaps volgens de standaard weergegeven, waardoor de weergave volledig kan veranderen. Met soms rampzalige gevolgen.
Er zijn eigenlijk maar drie redenen om het doctype van een bestaande pagina toch te wijzigen: in één of meer browsers is de weergave niet goed, er worden frames gebruikt, of er zijn tabellen voor de opmaak gebruikt. (En natuurlijk als je de inhoud van de pagina meer dan marginaal wilt veranderen, maar dat spreekt vanzelf.)
- Als de pagina niet goed werkt in elke browser, is dat een goede reden een doctype aan te brengen. Daarover staat hieronder bij Bestaande pagina's die worden veranderd meer.
-
Frames worden al jaren afgeraden, en in html5 zijn ze gewoon helemaal niet meer toegestaan. Een pagina met frames komt als een aantal losse pagina's bij de browser aan. De browser zet ze op een bepaalde manier op het scherm, maar het blijven losse pagina's.
Hierdoor zijn het ook voor zoekmachines, schermlezers, en dergelijke losse pagina's: er zit geen logische samenhang in. Op het scherm is die samenhang er misschien wel, maar niet voor zoekmachines, schermlezers, en dergelijke. Frames leveren daardoor vaak een (veel) lagere plaats in zoekmachines op en zijn meestal volstrekt ontoegankelijk voor schermlezers en dergelijke.
Frames worden vaak gebruikt, om een onderdeel dat op elke pagina hetzelfde is in te voegen. Dat kan beter met PHP of SSI. Daarbij kun je ook invoegen, maar dat gebeurt al op de server, waardoor de browser één pagina krijgt. De browser, zoekmachines, schermlezers, en dergelijke merken op geen enkele manier dat de pagina eigenlijk uit meerdere delen bestaat.
- Ook tabellen leveren vaak een lagere plaats in zoekmachines op en zijn vaak ontoegankelijk voor schermlezers en dergelijke. Tabellen worden van links naar rechts gelezen, per cel. Het is enigszins vergelijkbaar met het horizontaal lezen van de krant: niet per kolom, maar per regel, of per blok tekst. Ook hier is de samenhang volledig zoek voor zoekmachines, schermlezers, en dergelijke. Tabellen zijn alleen geschikt voor tabulaire gegevens, niet voor gewone teksten en dergelijke.
Een betere toegankelijkheid voor zoekmachines, schermlezers, en dergelijke zou een reden kunnen zijn om de pagina aan te passen. En gelijk van het juiste doctype te voorzien. En als je dat doet, kom je automatisch hieronder aan, want dan wordt de bestaande pagina veranderd.
Bestaande pagina's die worden veranderd
Bij hele kleine veranderingen, zoals het toevoegen van enkele woorden, geldt eigenlijk hetzelfde, als wanneer je niets verandert. En is de tekst bij Bestaande pagina's die niet worden veranderd mogelijk meer van toepassing.
Bij grotere veranderingen is dit misschien hét moment om de hele pagina bij te werken.
Als de pagina geen doctype heeft, is dit ook het juiste moment om er eentje toe te voegen. Zonder doctype is het heel moeilijk de html te valideren, waardoor er een grote kans op syntactische fouten in de code bestaat. En dat kan tot de vreemdste problemen leiden. Waarbij het zelfs prima kan dat een pagina het in Firefox geweldig doet, maar dat in Internet Explorer een deel van de pagina gewoon verdwijnt. Of omgekeerd. Valideren is hier geen absolute garantie tegen, maar het helpt wel.
Bij elke wijziging van het doctype moet in zoveel mogelijk browsers worden getest, of de al bestaande inhoud nog goed wordt weergegeven. Zonder doctype wordt de opmaak vaak anders weergegeven dan met een correct doctype, en dat kan in sommige browsers tot enorme verschillen leiden. Tot en met het verdwijnen van (delen van) de pagina.
Als je de pagina grondig ombouwt, kun je het beste het nieuwste doctype nemen, zoals dat hierboven bij Nieuwe pagina's wordt beschreven. Dan zit je gelijk goed voor de toekomst.
Vaak is bij bestaande pagina's het doctype één van de twee onderstaande:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
of
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Bij het onderste doctype staat meestal achter <html> ook nog een heel verhaal.
Het onderste doctype kan beter niet meer worden gebruikt. Het hoort bij xhtml, een taal die erg op html lijkt. Tot 'n paar jaar terug leek het erop dat deze taal html ging vervangen, maar inmiddels wordt xhtml helemaal niet meer ontwikkeld als aparte taal. Het is min of meer een onderdeel van html5 geworden. Vandaar dat er ook nog maar één doctype is voor html5.
Beide doctypes zijn 'strict': er mogen geen tags en eigenschappen voor opmaak, zoals <font> en vspace
, zijn gebruikt. Beide doctypes kunnen probleemloos door het doctype voor html5 worden vervangen:
<!doctype html>
Er zijn kleine verschillen tussen html en xhtml, maar html5 kan met beide talen overweg. En door <!doctype html> te gebruiken, kun je ook valideren op de vele uitbreidingen die html5 brengt.
Het doctype moet de allereerste regel van de code zijn.
Tags en eigenschappen voor opmaak worden al meer dan tien jaar afgeraden. Opmaak hoort via css te gebeuren. Maar veel oudere pagina's, en helaas ook nog steeds behoorlijk wat slecht in elkaar zittende nieuwe pagina's, gebruiken dit soort tags en eigenschappen op grote schaal.
De meest gebruikte tags voor opmaak zijn <center> en <font>. De meest gebruikte eigenschappen voor opmaak zijn name
, align
, alink
, link
, vlink
, background
, bgcolor
, border
, hspace
, en vspace
.
Als je de pech hebt dat dit soort tags en eigenschappen in je pagina zit, heb je maar twee mogelijkheden:
- Je haalt al dit soort verouderde tags en eigenschappen uit de html en stapt over op css. Waarna je het doctype voor html5 kunt gebruiken: <!doctype html>. Nu kun je ook alle nieuwe dingen van html5 probleemloos gebruiken.
-
Je gebruikt het doctype voor pagina's die volgens de standaard moeten worden weergegeven, maar waarin verouderde tags en eigenschappen zitten:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Nu kun je de verouderde tags en eigenschappen laten staan, maar de nieuwe mogelijkheden van html5 blijven buiten bereik. Als je toch dingen uit html5 gaat gebruiken in combinatie met dit doctype, kan dat tot (grote) problemen in de weergave leiden.
Dit doctype is dus nadrukkelijk niet bedoeld voor nieuwe pagina's. Je kunt dat ook al zien aan het doctype zelf: 'transitional' betekent 'overgang'. Het wordt tot op de dag van vandaag voor nieuwe pagina's gebruikt, maar dat is dus gewoon ronduit fout.
Het doctype moet de allereerste regel van de code zijn.
(Terzijde: zodra je css voor opmaak gaat gebruiken, wint dit áltijd van een tag als <font>. Althans: dat is de theorie. Maar ik zou er geen cent om durven te verwedden dat dit in de praktijk ook echt altijd foutloos werkt.)
Het hoe en waarom van een doctype
Als je wat meer geïnteresseerd bent in de achtergronden van doctypes, vind je hieronder wat uitgebreidere en deels meer theoretische informatie.
In tegenstelling tot wat heel vaak wordt gedacht, heeft het versienummer in het doctype geen enkele invloed op de weergave van de pagina. Dat wil zeggen: als je een volledig correct doctype gebruikt.
Tot en met versie 4.01 van html werd in het doctype het versienummer van de html genoemd. Bij html5 is dat vervallen. Dit leidde tot enorme opwinding, zelfs bij ervaren sitebouwers, want hoe moest de browser nu weten welke versie van html moest worden weergegeven?
Het antwoord is heel simpel: zoals de browser dat altijd al deed.
Het versienummer in het doctype heeft nooit enige invloed gehad op hoe de html werd weergegeven. Daar is het nooit voor bedoeld geweest. Waar het dan wel voor is bedoeld, kun je hieronder lezen.
Opmaakmogelijkheden in de oudste versies van html
In een tijd lang, lang geleden, toen Rutte nog 'n échte liberaal was en Samsom nog principes had, kon je met html vrijwel alleen tekst weergeven. En tabellen. Zelfs simpele afbeeldingen konden niet worden weergegeven. Html is ontstaan als een taal voor wetenschappers, en die raken nou eenmaal meer opgewonden van E=mc² dan van Star Trek.
Voor normale stervelingen ligt dat anders. De gemiddelde bezoeker van een website houdt meer van een mooie foto van een zonsondergang, dan van de wiskundige beschrijving daarvan. En ook eindeloze tabellen met getallen leiden bij een gemiddelde bezoeker niet tot uitroepen van verrukking.
De eerste versie van html is door wetenschappers ontwikkeld en had dan ook vrijwel geen enkele mogelijkheid om de tekst van een pagina op te maken. Je had de kopregels <h1> tot en met <h6>, maar dat was het dan wel zo'n beetje. En die kopregels waren eigenlijk niet voor de opmaak, maar meer om een soort rangorde in onderwerpen aan te brengen.
Hyperlinks, in feite de kern van wat later internet werd, waren ook al aanwezig.
Deze elementaire elementen hebben tot de dag van vandaag vrijwel exact dezelfde semantische betekenis gehouden. Met 'semantisch' wordt bedoeld dat het soort element al enigszins iets zegt over de inhoud van het element. Een <a> is een link, een <h1> is de belangrijkste kopregel, een <h2> is een iets minder belangrijke kopregel, enz.
Maar specifiek voor de opmaak waren eigenlijk geen elementen aanwezig. Als je bijvoorbeeld 'n blok tekst wilde centreren, had je 'n probleem.
De eerste browser die iets fatsoenlijks met afbeeldingen kon doen, was Mosaic. Hieruit ontstond in 1994 Netscape Navigator, de eerste browser voor het grote publiek. Netscape Navigator was gratis voor niet-commercieel gebruik, wat mede de populariteit verklaarde.
Pas in 1995 kwam Microsoft met de eerste versie van Internet Explorer. Door de enorme verspreiding van Windows werd Internet Explorer al snel een geduchte concurrent voor Netscape.
Naast Netscape en Internet Explorer had je nog wat kleinere browsers, maar die speelden niet echt een grote rol. Apple maakte Safari, maar die draaide alleen op de Mac. Een andere kleine browser was Opera, maar die was in die tijd alleen gratis, als je advertenties in de browser toestond.
Browser war
Dit leidde tot de zogenaamde browser war tussen Netscape en Internet Explorer. Deze oorlog is overduidelijk gewonnen door Internet Explorer, mede doordat de laatste veel gebruikte versie van Netscape werkelijk stijf stond van de bugs en feitelijk onbruikbaar was (heb er nog wel 'ns nachtmerries van).
Navigator en Internet Explorer probeerden beide zoveel mogelijk gebruikers te krijgen. Dat deden ze door in een razend tempo nieuwe versies uit te brengen. En elke nieuwe versie had nieuwe mogelijkheden om pagina's leuk op te maken. Als de een knipperende tekst had bedacht, kwam de andere met rollende tekst. In die tijd moeten heel wat mensen schele hoofdpijn hebben gekregen van alleen al het argeloos bezoeken van sommige sites.
Netscape en Internet Explorer hadden beide hun eigen elementen en eigenschappen. Die helaas niet compatibel waren. Je had al wel standaarden, maar daar trokken beide zich weinig van aan. Daarom waren veel sites dubbel uitgevoerd: één versie voor Netscape en één versie voor Internet Explorer.
Sterker nog: veel sites hadden aangepaste pagina's per versie van deze browsers, omdat de verschillende versies van dezelfde browser vaak ook niet volledig compatibel waren. Safari en Opera hielden zich wel aan de standaarden, dus ook voor die browsers werd vaak een aparte versie gemaakt.
Sites die drie- of vierdubbel werden gemaakt, met binnen elke uitvoering nog kleinere aanpassingen voor een bepaalde versie van een browser, waren geen uitzondering. Met behulp van JavaScript werd aan 'browser sniffing' gedaan: er werd geprobeerd vast te stellen welke (versie van een) browser van welk besturingssysteem op bezoek kwam. Dat ging heel vaak mis, maar ja, wat moest je anders.
Een andere veel gebruikte 'oplossing' was een site die maar in één browser goed werkte. Andere browsers werden botweg geblokkeerd, of gaven een soort Chinese puzzel weer.
Twee dingen hadden deze sites meestal wel gemeenschappelijk: ze waren volstrekt ontoegankelijk voor schermlezers en dergelijke, en ze waren een nachtmerrie om te onderhouden. En omdat zoekmachines redelijk vergelijkbaar zijn met schermlezers, waren ze ook moeilijk goed te indexeren.
Als je meerdere versies van 'n site hebt, kun je makkelijk 'n versie vergeten bij te werken. En het bijwerken van meerdere versies is ook gewoon vreselijk veel extra en geestdodend werk. Bovendien veranderden de strings waarmee browsers zich identificeerden bij elke nieuwe versie, waardoor het JavaScript voor het browser sniffen ook constant moest worden bijgewerkt.
Nadat Internet Explorer de oorlog had gewonnen, verscheen er jarenlang geen nieuwe versie van Internet Explorer. Waardoor de ontwikkeling van internet behoorlijk bevroor. En omdat er nauwelijks nog concurrentie was, werden nogal wat sites alleen voor Internet Explorer gemaakt. Niet volgens de officiële standaard, maar volgens de de facto standaard van Microsoft. Microsoft was (en is) bepaald niet te beroerd, om grotelijks misbruik te maken van z'n bijna-monopolie.
Uit Netscape Navigator kwam, via een aantal tussenstappen, uiteindelijk Firefox voort. De eerste echte concurrentie voor Internet Explorer sinds jaren. Dit dwong Microsoft tot het overhaast uitbrengen van Internet Explorer 7. Overhaast, want het kreng was overduidelijk zo snel mogelijk in elkaar gehengst en stikte van de bugs, afwijkingen van de standaard en andere misplaatste grollen.
(Met ingang van Internet Explorer 9 houdt Microsoft zich eindelijk ook aan de standaarden. Helaas wordt Internet Explorer nooit geüpdatet, op veiligheids-updates na, waardoor elke versie van Internet Explorer feitelijk op de dag van verschijnen al is verouderd en onmiddellijk in een blok aan het been verandert. En tot op de dag van vandaag wordt hierdoor zelfs een totaal verouderde monstruositeit als Internet Explorer 6 nog volop gebruikt. Hopelijk gaat ook Microsoft ooit z'n browser op dezelfde manier updaten als alle andere browsermakers.)
Ontstaan van css
Er kwamen dan wel allerlei elementen voor opmaak, maar css bestond nog niet. Als je bijvoorbeeld 'n andere lettergrootte wilde, moest je dat bij élke verandering aangeven. Soms was dat op tientallen plaatsen binnen dezelfde pagina. Hetzelfde gold voor kleuren en noem maar op. Dat was echt hartstikke leuk, als er iets aan de opmaak veranderd moest worden...
De opmaakmogelijkheden waren ook nog steeds behoorlijk beperkt. Een stuk tekst of een afbeelding links of rechts positioneren, was niet mogelijk. Slimme ontwerpers ontdekten echter dat je prima tabellen kon gebruiken, om iets op een bepaalde plaats neer te zetten. En met geneste tabellen ging het nog beter. Soms werden tabellen tot wel meer dan tien niveaus diep genest.
Geneste tabellen zijn een nachtmerrie om te onderhouden. Als je rechtsboven een prijs toevoegt, verdwijnt linksonder je bankrekeningnummer. Zoiets.
Bovendien zijn tabellen die voor iets anders dan tabulaire gegevens worden gebruikt volstrekt ontoegankelijk voor schermlezers, zoekmachines, en dergelijke.
In de linearizer - er bestaat, voor zover ik weet, geen Nederlands woord voor - van w3c kun je een tabel bekijken op de manier, zoals een schermlezer, zoekmachine, e.d. de tabel zien. Dit maakt het probleem uiterst duidelijk: een tabel wordt van links naar rechts gelezen, en niet in kolommen. Probeer maar 'ns een krant te begrijpen, als je die min of meer regel voor regel leest, zonder al te veel op de kolommen te letten.
Ontoegankelijk en niet te onderhouden. En dan ook nog vaak meermalen dezelfde site in verschillende uitvoeringen voor verschillende browsers. Dat moest toch beter kunnen.
Om deze problemen op te lossen, werd gekozen voor een aparte taal voor de opmaak: css. Door de html alleen nog maar voor de inhoud te gebruiken, heb je geen tabellen en dergelijke meer nodig voor de opmaak. In principe kun je gewoon de tekst, kopregels, enz. invoeren, zoals ze op het scherm moeten komen. Hoe het eruitziet, regel je dan met css.
Als dan ook nog alle browsers zich aan de standaarden voor html en css houden, is het paradijs acuut uitgebroken en is één uitvoering van de site voldoende.
Dat 'aan de standaarden houden' had nogal wat voeten in de aarde. Omdat Internet Explorer de browseroorlog had gewonnen, waren er nogal wat sites die speciaal voor Internet Explorer waren gemaakt. Zonder daarbij al te veel op standaarden te letten. Microsoft had er daardoor niet al te veel belang bij, om zich aan standaarden te gaan houden. Dat gold trouwens niet alleen voor css en html, maar ook voor JavaScript en nog een aantal andere talen.
Door projecten als het Web Standards Project, gevormd door voornamelijk sitebouwers die er genoeg van hadden elke site ontoegankelijk in meerdere uitvoeringen te moeten maken, werd ook Microsoft gedwongen zich aan de standaarden te houden.
Toenemende concurrentie speelde hierbij ook een rol. Safari kwam ook beschikbaar voor Windows, Google Chrome verscheen, mobiele browsers werden steeds vaker gebruikt. Nieuwe sites werden hierdoor in toenemende mate volgens standaarden gemaakt. Je zou wel gek zijn dat niet te doen: minder werk, beter te onderhouden, toegankelijker voor schermlezers en dergelijke, beter te indexeren door zoekmachines, en je sluit niet een toenemend aantal bezoekers buiten.
Sinds een aantal jaren houdt elke browser zich min of meer aan standaarden, eindelijk.
Het doctype
Maar er is een groot aantal oudere sites dat zich niet aan de standaarden houdt. Ze stammen nog uit de tijd dat standaarden werden genegeerd. Als ze niet meer worden onderhouden, of als de eigenaar het te veel werk vindt de site te moderniseren, verandert dit ook niet meer. Die sites zijn vaak aangepast voor de weergave in oudere versies van Internet Explorer.
Als je die sites nou opeens volgens de standaard gaat weergeven, levert dat een volstrekte puinhoop op. En hier verschijnt het doctype. Een geniaal idee, bedacht door Todd Fahrner.
Als een pagina volgens de standaard is gemaakt, laat die pagina dan beginnen met een doctype. Pagina's die dat doctype niet hebben, zijn kennelijk niet volgens de standaard gemaakt en worden op een oudere manier weergegeven. Er bestaan een aantal oudere manieren, waarvan 'quirks mode' (eigenaardigheden modus, of rariteiten modus) de belangrijkste is.
Het doctype is dus niets meer dan een simpele aan-uitschakelaar voor 'standards mode' (standaard modus). Daarvoor moet wel het volledige doctype worden gebruikt. Sommige doctypes hebben een url als tweede deel, en ook dat moet worden ingevoerd. Doe je dat niet, dan werkt het doctype vaak niet of niet volledig. Het kan dan bijvoorbeeld voor weergave in 'almost standards mode' (bijna standaard modus) zorgen.
Vooral het verschil in weergave tussen standaard modus en quirks modus kan enorm zijn. Als je zonder meer een doctype weghaalt, toevoegt of verandert, kan de hele opmaak volkomen verstoord worden. Delen van de pagina, of de hele pagina, kunnen zelfs volledig verdwijnen in één of meer browsers.
Een volledig overzicht van doctypes en welke modus door een ontbrekend of onvolledig doctype wordt ingeschakeld, staat op hsivonen.fi/doctype.
Bij links onderaan deze pagina staat een aantal links naar overzichten van verschillen in weergave in de verschillende modi. Deze verschillen zijn niet bij alle browsers hetzelfde, wat nog 'n extra reden is om de standaard modus te gebruiken: deze is in principe in alle browsers hetzelfde.
Om maar gelijk een ander misverstand uit de wereld te helpen: het tweede deel van sommige doctypes, waarin een url staat die verwijst naar de site van w3c, staat daar om volstrekt onduidelijke redenen. Persoonlijk denk ik dat techneuten, zoals de bedenker van het doctype, gewoon dingen graag zo duidelijk mogelijk beschrijven.
Als je die url zou volgen, kom je bij een DTD. In een DTD staat exact beschreven aan welke eisen de – in dit geval – html of xhtml moet voldoen. Regelmatig wordt gedacht dat die DTD door de browser wordt opgehaald. Dat is dus niet zo. w3c zou vermoedelijk allang failliet zijn geweest, als voor elke pagina zo'n document zou moeten worden opgehaald. Die DTD is gewoon in de browser aanwezig, verwerkt in de regels over hoe een pagina moet worden weergegeven.
Het html5 doctype
w3c, de club die de standaard voor html onderhoudt, wilde eigenlijk van html af. Er werd niet meer aan gewerkt, 4.01 zou de laatste versie zijn. In plaats daarvan werd gewerkt aan xhtml, een soort strengere vorm van html, die een aantal voordelen had boven html. Uit die tijd stammen ook de, inmiddels verouderde, doctypes voor xhtml.
In eerste instantie ging dit goed. Heel veel sites, waaronder deze site, gingen van html over naar xhtml. Er waren maar kleine verschillen en xhtml had een aantal voordelen.
En toen kreeg w3c de geest en ging het grandioos mis.
w3c besloot een nieuwe versie van xhtml te ontwikkelen, die technisch perfect was. En daardoor niet meer te gebruiken door simpele particulieren zonder technische achtergrond. Bovendien was die nieuwe versie van xhtml niet terugwaarts compatibel. Als je dingen uit de nieuwe versie van xhtml wilde gebruiken, moest je je site volledig herschrijven.
Uit onvrede hiermee richtten Apple, Mozilla (Firefox) en Opera de WHATWG op. De techneuten van w3c konden dan wel naar technische perfectie streven, browsermakers zaten niet te wachten op een taal die alle bestaande sites zou slopen en waar tante Truus en Ome Joop nooit mee zouden kunnen werken.
WHATWG begon met de ontwikkeling van html5. En kreeg zoveel bijval, dat w3c uiteindelijk stopte met xhtml en verder ging met html5. html5 is grotendeels ontwikkeld door WHATWG en overgenomen door w3c, die de officiële standaard onderhoudt.
Na enige jaren van onmin tussen WHATWG en w3c, waarbij steeds meer verschillen tussen beide specificaties ontstonden, is medio 2019 gelukkig de vrede weer getekend. WHATWG houdt de zogenaamde 'Living Standard' bij, die voortdurend wordt vernieuwd. w3c komt eens in de zoveel tijd met een zogenaamde snapshot daarvan.
Bij het schrijven van de standaard voor html5 is WHATWG op een aantal punten heel pragmatisch te werk gegaan. Een van die punten is het doctype. Er is gekeken, wat het kortste doctype was dat in alle browsers de standaard modus aanzette. Nou ja, niet álle browsers. Heel oude browsers kennen helemaal geen standaard modus, dus die tellen niet mee. Dat kortste doctype bleek het simpele <!doctype html> te zijn. Zonder verdere poespas.
Al die andere rimram van versienummer, url, enz. is volslagen overbodig: dit doctype schakelt keurig de standaard modus in. Zelfs in Internet Explorer 6. En meer hoeft het doctype ook niet te doen.
Alle opwinding over het verdwijnen van het versienummer uit het doctype was volstrekt overbodig. Zoals de specificatie het doctype omschrijft:
Note: DOCTYPEs are required for legacy reasons. When omitted, browsers tend to use a different rendering mode that is incompatible with some specifications. Including the DOCTYPE in a document ensures that the browser makes a best-effort attempt at following the relevant specifications. html.spec.whatwg.org
Compatibiliteitsmodus van Internet Explorer
Los van wat hierboven staat, heeft Internet Explorer 10 maar liefst 11 (elf!) verschillende modi. Microsoft vond dit nodig om het gerotzooi met standaarden in oudere versies van Internet Explorer te repareren. Bovendien worden bugs in de weergave van Internet Explorer nooit gerepareerd.
Veel pagina's hebben aanpassingen speciaal voor één of meer versies van Internet Explorer. Als dat niet helemaal op de juiste wijze is gebeurd, kan zo'n pagina in nieuwere versies van Internet Explorer worden verknald. Door het, om welke vreemde reden dan ook, halsstarrig weigeren van een fatsoenlijk update-systeem voor Internet Explorer, is Microsoft min of meer gedwongen tot een wildgroei aan modi.
Als Microsoft op deze manier doorgaat, krijgt Internet Explorer 11 er weer een fors aantal modi bij. Waarmee deze modi meer overeenkomsten met het voortplantingsgedrag van konijnen beginnen te vertonen, dan met een hanteerbare manier om oudere websites weer te geven.
Een compatibiliteitsmodus kan worden aangezet door in de header een speciale tag voor Internet Explorer op te nemen. Ook kan Microsoft een site op een lijst hebben geplaatst, waardoor een speciale modus wordt aangezet. Ten slotte kan een gebruiker zelf een van de compatibiliteitsmodi inschakelen.
Aan de lijst van Microsoft en de knop van de gebruiker kun je weinig doen. Maar de speciale tag in de header zou ik niet gebruiken. Als je site alleen in een oudere versie van Internet Explorer goed werkt, zit het er dik in dat je site ook niet goed werkt in andere browsers. Je kunt je site dan beter aanpassen, zodat hij in alle browsers goed werkt.
Als er aanpassingen nodig zijn voor de vreemdigheden van een oudere versie van Internet Explorer, kun je beter conditional comments gebruiken. Dit is op een speciale manier aangebrachte code, die alleen werkt voor één of meer specifieke versies van Internet Explorer 9 of eerder.
Op hsivonen.fi/doctype staat een overzicht van de verschillende compatibiliteitsmodi en de tags waarmee je die kunt oproepen.
Valideren
Valideren is het laten controleren van je code door een programma. Er bestaan validators voor tal van talen. Een validator kan alleen controleren op syntactische fouten: overtredingen van de regels van de taal, zoals typefouten, verkeerd nesten, en dergelijke. Een css-validator zal waarschuwen voor een foutieve kleurcode, maar een afschuwelijke kleurencombinatie die 98,3% van je bezoekers acuut kleurenblind maakt, vindt de validator prima.
Een html-validator zal waarschuwen tegen verkeerd nesten, maar als je de hele tekst in een <h1> zet, wordt daar niet voor gewaarschuwd. Er is geen enkele regel die je verbiedt om een enorm lange <h1>-kopregel te maken. Terwijl je daar toch echt bezoekers mee wegjaagt en er 'n hele grote kans is dat zoekmachines je eruit gooien vanwege manipulatie van de zoekindex.
Voor het valideren van html is de soort doctype wel van belang. Hier is het meer dan een aan-uitschakelaar.
Als je een doctype voor html 4.01 gebruikt, worden alle nieuwe elementen en eigenschappen uit html5 niet herkend en daardoor als fout aangemerkt.
Als je een doctype voor html 4.01 strict of html5 gebruikt, worden alle elementen en eigenschappen voor opmaak zoals <font> en hspace
als fout aangemerkt.
In beide gevallen zie je zoveel fouten, dat valideren feitelijk onwerkbaar wordt. Daarom moet je voor valideren het juiste doctype gebruiken.
Als je doctype html5 is, kun je de html-validator ook laten valideren op WAI-ARIA, SVG, microdata, en nog een aantal andere nieuwe ontwikkelingen.
Valideren van html kan op validator.w3.org.
html5 is wat minder streng met een aantal dingen dan xhtml. Persoonlijk vind ik die wat strengere aanpak van xhtml prettiger. Daarom valideer ik ook altijd op HTMLHint. Daar kun je opgeven dat bijvoorbeeld elke <p> moet worden afgesloten met een </p>, iets wat in html eigenlijk niet verplicht is.
Omdat elke browser bugs heeft, en ook validators bugs hebben, kan valideren nooit het daadwerkelijk testen in verschillende browsers vervangen.
Css is heel sterk verweven met html, daarom geef ik voor de volledigheid ook de validator voor css: jigsaw.w3.org/css-validator. Op de pagina met links vind je voor verschillende andere talen, toegankelijkheid, enz. nog tal van andere validators.
Links
Links in dit artikel, vooral links naar andere sites, kunnen verouderd zijn. Op de pagina met links vind je steeds de meest recente links.
Tenzij anders vermeld, zijn onderstaande sites Engelstalig.
Doctype en modi
hsivonen.fi/doctype: uitgebreide info over doctypes, welk doctype welke modus inschakelt, compatibitliteitsmodi, enz.
jkorpela/quirks-mode: uitgebreid overzicht van verschillen tussen quirks modus en andere modi.
quirksmode.org/css/quirksmode: verschillen tussen quirks en standaard modus in verschillende browsers.
docs.microsoft.com/en-us/openspecs/ie_standards: afwijkingen bij weergave in quirks modus in Internet Explorer.
w3.org: lijst met geldige doctypes.
Hulpprogramma's en validators
linearizer: tabellen lineair weergeven.
jigsaw.w3.org/css-validator: css-validator van w3c.
validator.w3.org: html-validator van w3c.
Geschiedenis
en.wikipedia.org/wiki/History_of_the_web_browser: geschiedenis van de webbrowser.
en.wikipedia.org/wiki/Netscape_Navigator: geschiedenis van Netscape Navigator.
en.wikipedia.org/wiki/Cascading_Style_Sheets: pagina over css, met onder andere de geschiedenis ervan.
nl.wikipedia.org/wiki/Mozilla_Firefox: geschiedenis van Firefox. Nederlandstalig.
Standaarden
webstandards.org: Web Standards Project, een van de drijvende krachten achter het gebruik van standaarden.
quirks.spec.whatwg.org: poging quirks modus in de verschillende browsers meer hetzelfde te krijgen.
spec.whatwg.org: specificatie html (De 'Living Standard'), ook w3c verwijst hiernaar.
Diversen
msdn.microsoft.com: pagina van Microsoft over conditional comments.
Op de pagina met links vind je mogelijk sites, die dieper op bepaalde onderwerpen ingaan.
Wijzigingen
Alleen grotere wijzigingen worden hier vermeld, geen dingen als een link die is geüpdatet.
:
Eerste versie.
1 augustus 2019:
Tekst over conflict tussen WHATWG en w3c aangepast, omdat ze inmiddels weer vriendjes zijn.