Fronteers — vakvereniging voor front-end developers

Webrichtlijn 35: De DocType Declaratie

Elk HTML of XHTML document moet beginnen met een geldige DocType Declaratie. (R-pd.6.1)

Hoeveel waarde hecht jij aan de doctype? Is het niet gewoon een irritant ding dat we steeds maar weer kopiëren en plakken?

Waarom gebruiken we vanaf nu niet gewoon <!doctype html> wat hetzelfde effect heeft in browsers (standards mode triggeren)?

Zijn er, zoals de webrichtlijnen beweren, editors die de doctype gebruiken? En heb je daar wat aan tijdens het ontwikkelen van een site?

Reacties

1 Raph de Rooij op 21-05-2008 om 09:52 uur:
Op de pagina waar de link naar toe leidt staat: "A DOCTYPE is a mostly useless, but required, header. 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."

Volgens mij wordt hier enkel, geheel in Hixie-stijl, geredeneerd vanuit het perspectief wat een browser er mee doet: de juiste rendering mode bepalen. Da's niet geheel onbelangrijk, lijkt me. Terecht wordt gesteld dat <!doctype html> daarvoor al voldoende is.

Voor validators is het belang veel groter: aan de hand van de doctype wordt bepaald waartegen wordt gevalideerd. <!doctype html> is in dat geval onvoldoende; het leidt tot een foutmelding "No internal or external document type declaration subset; will parse without validation".
Met een onjuiste of ontbrekende doctype valt een belangrijk controlemiddel weg voor een opdrachtgever; krijgt-ie wel opgeleverd wat is overeengekomen?

Mijn conclusie: wel of geen doctypes gebruiken is een leuk discussie-onderwerp voor front-end developers, maar de rest van de wereld heeft er volgens mij weinig boodschap aan. Doctypes staan niet in de weg, zijn uiterst simpel in gebruik en zijn een heel geschikte manier om aan je opdrachtgever te laten zien dat je in staat bent code te produceren van hoog (syntactisch) niveau. Da's een hele mooie mogelijkheid om je als front-end ontwikkelaar te onderscheiden van de mindere broeders. Gewoon gebruiken dus, is mijn advies.
2 Krijn op 21-05-2008 om 10:12 uur:
Raph, is validator.nu niet nu al een betere validator dan wat je ooit met een DTD kunt bereiken? Waarom zouden opdrachtgevers die niet kunnen gebruiken?
3 Raph de Rooij op 21-05-2008 om 11:32 uur:
@Krijn:
Ik zou opdrachtgevers niet willen adviseren om deze validator te gebruiken, omdat ze dan geen goed beeld hebben waartegen wordt gevalideerd.

Waaraan code moet voldoen is vastgelegd. Er is momenteel keus uit twee smaken: HTML 4.01 Strict of XHTML 1.0 Strict. Of, hoe en wanneer dit lijstje wordt uitgebreid is afhankelijk van een aantal factoren, onder meer of een (nieuwe) specificatie in alle opzichten voldoet aan de eisen om als 'open standaard' te kunnen worden aangemerkt. Het gaat er dus niet zozeer om of je een voor- of tegenstander bent van bijvoorbeeld HTML5, maar of de ontwikkeling van de specificatie al voldoende gevorderd is om als 'open standaard' te kunnen worden erkend.

Gebruik van drafts en duurzaamheid staan op gespannen voet met elkaar. Dat hebben we in 2006 gemerkt, toen tijdens een debat over toegankelijkheid van websites in de Tweede Kamer doodleuk werd gesteld dat de Webrichtlijnen als norm ongeschikt waren, omdat ze waren gebaseerd op WCAG 2.0 - een draft specificatie - in plaats van WCAG 1.0, die de status van Recommendation heeft. De inhoudelijke discussie (WCAG 1.0 is op een aantal punten verouderd en onvolledig, zie ook http://wcagsamurai.org/) deed daarbij niet ter zake. Een norm heeft de belangrijke functie van 'ankerpunt' en een draft kan dat nooit zijn, zo simpel lag het.

De W3C validator 'does the job' omdat die prima overweg kan met de specificaties in de Webrichtlijnen. Dat validator.nu veel meer kan is een feit dat weinig gewicht in de schaal legt; belangrijker in dit verband is dat deze tool een paar tekortkomingen heeft bij validatie van HTML 4.01 Strict.

Dat neemt overigens niet weg dat validator.nu een heel interessant en nuttig instrument is; ik sta bekend als een 'validation nut' (zie ook http://annevankesteren.nl/2005/06/overheid-nl), dus ik ben al snel gecharmeerd van validators die bijzondere kwaliteiten bezitten.
Echter, 'persoonlijke voorkeur' en 'formeel beleid' liggen soms mijlenver uit elkaar; soms is het dan een kwestie van veel tijd (en geduld...) om die afstand te overbruggen ;-).
4 Kilian Valkhof op 21-05-2008 om 12:20 uur:
Hoewel het erg verleidelijk is om nu al <!doctype html> te gebruiken, blijf ik voorlopig toch gewoon bij xhtml 1.0 strict.

Dit gebaseerd op dezelfde argumenten als Raph. Volgens mij zijn je klanten beter af met een standaard met recommendation status, dan eentje in draft status. (theoretisch, althans ;) )
5 Anne van Kesteren op 21-05-2008 om 13:57 uur:
Raph, welke limitaties? Ik denk dat Henri zulke feedback wel kan gebruiken: http://bugzilla.validator.nu/
6 Raph de Rooij op 21-05-2008 om 14:27 uur:
@Anne
Hoe gaat-ie? Heb je vanochtend nog gekwoot ;-)

Voor wat betreft je vraag: zie http://about.validator.nu/#ideas. Wat daar staat is de bron voor mijn opmerking over de tekortkomingen bij validatie van HTML 4.01 Strict.
7 Wouter op 25-05-2008 om 16:35 uur:
Ikzelf gebruik het doctype statement ook consequent, alleen al als hulpmiddel voor mezelf. Omdat ik altijd uit wil gaan van 100% complient (en dus -en nog belangrijker-) browser-onafhankelijk, wil ik de XHTML en CSS altijd valideren met de w3c tools (validator.nu kende ik nog niet, ga ik eens bekijken).
Door die validatie haal ik evt. fouten eruit die mogelijk weer tot rare dingen in IE6 enzo kunnen leiden, dus ik vind het goed om ze op te nemen.

en ja, als er andere standaarden komen, dan moeten we maar weer zien wat er dan nog nuttig is.. sommige technische zaken hebben de neiging om vanzelf nutteloos te worden ;)
8 marc op 25-05-2008 om 23:19 uur:
@wouter: Ik gebruik ook altijd een goede DTD om de output te kunnen valideren. Het is echter een misvatting om 100% complient gelijk te stellen met browser-onafhankelijk. Het is helaas maar al te goed mogelijk om valide code te schrijven die totaal verschillende resultaten geeft in IE en FF. Validatie van (X)HTML en CSS kan op geen enkele wijze cross-browser tests vervangen.
Plaats een reactie