Fronteers — vakvereniging voor front-end developers

Front-end vraagstukken: Doctype

In het kader van front-end vragen uit de vereniging (vragen blijven welkom) stuurde Rommert van der Marel de volgende vraag in: Fix Your Site With the Right DOCTYPE! Maar welke DOCTYPE vinden jullie het beste? Of misschien nog beter: het meest gebruikersvriendelijk?

Reacties

1 Sander v L. op 20-04-2009 om 22:33 uur:
Allereerst: Zie ook de discussie die hierover is gevoerd in het kader van de webrichtlijnen.

Zoals ik het zie is er slechts één echt belangrijke keuze die er toe doet bij het bepalen van een doctype, en vervolgens aan de hand daarvan kan je je meer- of minder mooie syntax kiezen.

De keuze die er toe doet is: standards mode of geen standards mode. Standards mode gedraagt zich veel voorspelbaarder en logischer dan quirks mode (is "gebruiksvriendelijker" voor ons front-end ontwikkelaars), en voor mij is dat in 100% van de gevallen dan ook de mode die ik kies.

Vervolgens zijn er een aantal verschillende doctypes die dit zouden triggeren, waarbij de voornaamste zijn: HTML 4.01 Strict, XHTML 1.0 Strict en HTML 5.
Een HTML 5 doctype is gewoon te onthouden: <!doctype html> en zou daardoor de voorkeur hebben; maar helaas heeft Microsoft de 'belofte' gedaan dat waar een HTML5 doctype nu hun beste rendering mode garandeert, ze dit zullen bevriezen wanneer meer dan een bepaald percentage aan sites er gebruik van maakt en er mee op IE bugs vertrouwt. Aangezien IE8 nog lang niet goed genoeg is dat ik dat op dat punt gedrag bevroren wil zien vermijd ik het gebruik van de HTML5 doctype nog voor niet-persoonlijke sites, daarmee hopend dat het ook in IE9 de beste mode zal blijven geven (Microsoft's filosofie wat betreft versioning zuigt echt enorm); ik ben van plan dit in ieder geval te blijven doen tot HTML5 last call in gaat, en waarschijnlijk ook wel tot Candidate Recommendation.

Een XHTML doctype is een leugen zolang de juiste mimetype niet wordt meegestuurd, en zelfs al werkt je eigen XHTML volledig als XML, mensen die het van je copy/pasten zonder zelf ook een XML mimetype mee te sturen zullen al heel snel niet valide XML onder dit doctype hebben staan. (Zie ook Hixie.) Ik kan me niet echt druk meer maken om dit alles, aangezien XHTML als XML toch volledig en onherroepelijk gefaald heeft, en het doctype is dus niets meer dan een talisman, maar persoonlijk blijf ik het wel lelijk vinden.

De uiteindelijke keuze voor mij is dan ook altijd een HTML 4.01 Strict doctype, welke ik blijf copy/paste-en van site naar site: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
2 Boye op 21-04-2009 om 08:26 uur:
Ik sluit me volledig aan bij Sander wat betreft het HTML 4.01 Strict doctype, ergens vorig jaar hebben we bij e-sites de omschakeling gemaakt van pseudo-XHTML naar semantische HTML en dit zal met het oog op de toekomst (HTML 5) ook zeker zo blijven.

Ik zag overigens dat ook Dave Shea recentelijk ingehaakt is op dit vraagstuk. Vanzelfsprekend met als gevolg dat dit de welbekende discussie wederom doet oplaaien in de comments.
3 Tom op 21-04-2009 om 10:18 uur:
Als het gaat om het verschil tussen de HTML- en de XHTML-doctype vind ik dit een non-discussie. Het is vooral belangrijk te weten wanneer je browser in quirksmode gaat, zodat je dat "rare" gedrag van IE begrijpt en kunt oplossen.

Ik zou wel altijd de voorkeur geven aan een strict doctype, maar soms heb je daar geen invloed op en is het roeien met de riemen die je hebt. Maar ja, dat is juist een van de uitdagingen van ons vak! :)
4 Anne van Kesteren op 21-04-2009 om 10:26 uur:
Referentie naar Activating Browser Modes with Doctype mist hier.
5 Niek Kouwenberg op 21-04-2009 om 11:02 uur:
Ik heb zelf nog nooit een klant meegemaakt die links niet in een nieuw venster geopend wilde hebben, waardoor ik dus ook altijd een XHTML Transitional doctype gebruik.

Alleen voor mijn eigen websites gebruik ik Strict. Maar ook deze zijn XHTML zonder application/xhtml+xml mimetype, omdat niet elke browser hier correct mee om weet te gaan.

Dat is dus gewoon gebruikersvriendelijkheid die het toepassen van strikte standaarden tegengaat. We gebruiken toch ook allemaal IE6 CSS hacks!
6 David Hund op 21-04-2009 om 11:37 uur:
Ik ben het helemaal met Sander v L. eens. Maarr: gebruik toch meestal de XHTML Strict variant. Ik begrijp uiteraard dat dit een 'leugen' is, en in principe zou ik voor HTML Strict zijn, maar ik sta er toch een beetje pragmatisch in: ik ben 'gewend' aan de XHTML syntax en gebruik standaard XHTML snippets.

Beetje 'loze' reden misschien maar goed ;-)

De laatste tijd ben ik wat meer met HTML5 of een soort HTML5 'hybride' code bezig (geen 'section' element, maar 'section' classname vooralsnog bv.).

IE's 'belofte' om de ondersteuning van HTML5 te bevriezen bij grote adoptie was mij volledig onbekend (en maakt me een beetje verdrietig). Sander, waar kan ik daar meer over lezen?

Als ik het goed begrijp betekent dit dus dat, zodra HTML5 meer gebruikt gaat worden, IE support ervoor gaat droppen?! sigh

Anyway, mijn mening re: doctypes is dus ook: Altijd Strict maar 'smaakje' naar keuze.
7 Sander v. L. op 21-04-2009 om 12:55 uur:
@David: Zie bijvoorbeeld Chris Wilson op public-html: "When the potential disruption caused by our changes rises to a certain level, we will have to put those changes under an opt-in switch, just like quirks mode." - en meer van zijn berichten in die thread (ik vermoed dat er berichten waren waar hij het nog duidelijker zei dan in de specifieke email waar ik naar link, maar heb op dit moment niet de tijd om dat op te zoeken; raad zeker wel aan die hele thread te lezen - dit was het enige onderwerp waar Microsoft ooit actief mee is geweest in de HTML WG, en het is erg verhelderend voor hoe ze het web zien).

Na het schrijven van mijn eerste reactie bedacht ik me echter wel dat dit het standpunt was van voordat er uiteindelijk is gekozen om bij gebrek aan meta-switch iig voor niet-intranet-sites toch altijd de beste rendering engine te gebruiken (opt-out i.p.v. opt-in dus). Als die keuze stand houdt naar IE9 toe (wat lang niet zeker is), dan is er waarschijnlijk ook geen risico met de HTML5 doctype. Ik blijf terughoudend, maar zal wel <!doctype html> aanraden wanneer mensen <canvas>, <video> e.d. willen gebruiken.


@Niek: ik snap je laatste paragraaf niet; zou je dat kunnen verhelderen?

De laatste keer dat ik nog een klant ben tegengekomen die "links in nieuw venster" wenste (ergens in 2005) heb ik deze zonder moeite weten te overtuigen dat dit een slecht idee was. Sindsdien niet meer meegemaakt. Tabbed browsing en "mensen willen/kunnen zelf die keuze maken in hun browser" is een erg krachtig argument.
8 Niek Kouwenberg op 21-04-2009 om 16:10 uur:
Sander, met mijn laatste alinea bedoelde ik alleen dat ik poog websites te maken die voor alle bezoekers werken. En vooral bij bedrijven in Nederland heeft IE6 nog een aandeel van rond de 25% in de stats. Dit wil dus zeggen dat ik rekening moet houden met browsers die geen goede CSS ondersteuning hebben, maar die ook application/xhtml+xml niet (altijd) goed snappen en ik dit dus simpelweg moet vermijden.

De verouderde browsers van je bezoekers werken dus gebruik van nieuwere technieken tegen, ook al wil je zo graag een cutting edge website opleveren.


Met betrekking tot links in een nieuw venster openen heb ik zelf eigenlijk weinig te beslissen. Corporate policy. Een bedrijf wil gewoon niet dat een bezoeker de website verlaat zodra deze een externe link aanklikt, en daar kan ik volledig inkomen.

Ik open mijn linkjes zelf wel in een nieuwe tab, maar de gemiddelde bezoeker van een website doet dat niet. Mijn ouders hebben bijvoorbeeld zelfs nooit meer dan 1 venster tegelijk open, laat staan dat ze een link in een tweede tab openen.
9 Raph de Rooij op 23-04-2009 om 01:25 uur:
Interessante discussie, maar ook al een heel oude. Mijn advies: kies wat je zelf het prettigst vindt. En gebruik de Strict variant ;-)

Tijd voor een nieuwe invalshoek.
Het W3C werkt al jaren aan het Semantic Web. Prachtig concept en voor allerhande toepassingen heel bruikbaar. Ook op het web in (X)HTML-documenten. Alleen, de huidige manier van metadata toevoegen - via elementen in de HEAD sectie van HTML-documenten - is nogal beperkt: op die manier kun je per HTML-pagina maar één bron beschrijven. Da's onvoldoende als je bijvoorbeeld een namen- en adressenlijst publiceert; dat is een hele verzameling bronnen op één pagina.
Daarvoor is er de XHTML+RDFa Doctype, sinds oktober 2008 een W3C Recommendation. Voor 'gewone' HTML is er geen bijpassende doctype; daarvoor moeten we wachten op HTML5.

Als je serieus aan de slag wil met Web 3.0 kun je op dit moment nog geen dus eigenlijk niet om XHTML+RDFa heen. Op http://zeddammer.raph.nl/rdfa/ heb ik er een beetje mee zitten prutsen. En verder heb ik een complete website omgezet naar dit doctype. Dat was trouwens een fluitje van een cent. Maar ja, dat MIME type hè?

Voor XHTML 1.0 heb ik daar persoonlijk niet zo'n moeite mee. Serveren als text/html is formeel 'conforming'. Inderdaad in meerdere opzichten niet optimaal, maar in de praktijk heb ikzelf daar nog nooit last van gehad.

Maar XHTML+RDFa is gebaseerd op XHTML 1.1 en daarvoor geldt dat text/html niet wordt gedoogd. Probleempje is echter wel dat geen enkele versie van Internet Explorer overweg kan met application/xhtml+xml.

Op http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html vond ik vanavond een oud artikel waar dat probleem met letterlijk een paar regels server side code kan worden ondervangen. Dat IE dus eigenlijk 'tag soup' krijgt vind ik geen probleem; hadden ze bij MS maar een betere browser moeten maken.

naar aanleiding van dit vraagstuk heb ik een testpagina gemaakt op basis van een bestaande. Overigens nog zonder de metadata; dat komt later.
De pagina, http://www.opvallendeplanten.nl/test/ heeft vrijwel dezelfde look/feel/function als de 'live' versie in IE8, FF3.0.7, Safari 3.2.2, Opera 9.6 en Google Chrome 1 op een Vista-PC. Alleen in IE8 wordt text/html gebruikt.

Een opmerkelijk punt is wel dat van de browsers Opera een anti-spam e-mailadres onderaan de pagina wél ombouwt en de andere browsers niet. Ben benieuwd wat daarvoor de logische verklaring is.
Is Opera gewoon de beste browser van het stel, of wordt de pagina stiekem toch gerenderd? Want in IE8 doet-ie het ook...
10 Sander v L. op 23-04-2009 om 10:57 uur:
@Raph: Kort door de bocht en niet verder geanalyseerd: Je main.js doet document.write - dat mag niet in XHTML, dus het script faalt, dus waarschijnlijk wordt er niets verder uitgevoerd, en dus wordt dat email adres niet omgezet. Waarschijnlijk is Opera te "lenient" hier.

Ik zou ook aanraden dat artikel van Hixie nog eens grondig door te nemen. IE tag soup geven en andere browsers niet lijdt in de praktijk er toe dat wanneer (niet "als") je XML plotseling fouten gaat bevatten (wat op een dynamische website in 100% van de gevallen binnen afzienbare tijd zal gebeuren; zoals een van de whatwg mensen het een tijd geleden zei: "experience seems to show that even world-class XML experts cannot avoid generating invalid XML with their software" - en dat zijn dus echt de XML experts; meestal is het zo eenvoudig als wat ongeldige utf8 byte sequences in een query string te stoppen, wat aangeeft dat hun codepaths niet afdoende beveiligd zijn om te garanderen dat ze altijd geldige XML genereren (dat voorbeeld is de eerste die ik naar boven kon halen, maar hetzelfde is aangetoond op daadwerkelijk elke grote application/xhtml+xml site die maar te vinden is)), je de site dus wel als tagsoup in IE kan bekijken, maar dat deze in goede browsers een yellow screen of death (of equivalent) geeft.

Als je met XML wil werken MOET je afstappen van string concatenatie op de server en in je volledige workflow met XML werken; iets anders geeft altijd problemen. Dit is voor het normale web niet doenbaar, RDF is voor normale gebruikers niet begrijpbaar (nog minder dan namespaces), en dit alles zorgt er voor dat er dus geen toekomst zit in een semantisch "web" gebaseerd op deze technieken. (Wat niets afdoet aan dat het geweldige technologien zijn die heel veel mogelijkheden bieden voor instanties en organisaties die er wel goed mee kunnen omspringen - hoewel dit er waarschijnlijk minder zijn dan je denkt; ik werk op dit moment op een locatie waar veel met andere (grote) partijen in XML wordt gecommuniceerd, en we krijgen bijna vaker totaal ongeldige string soup binnen (als het al niet fallback naar HTML error pagina's is) dan iets wat we echt met XML tools kunnen behandelen.)
11 Sander v L. op 23-04-2009 om 11:03 uur:
Overigens, dat artikel van Mark stamt uit 2003. Toendertijd is er veel mee ge-experimenteert om dingen inderdaad op die manier aan te pakken, maar ervaring heeft er voor gezorgd dat virtueel iedereen die dat toen deed er weer van is afgestapt. (Als je er behoefte aan hebt kan ik waarschijnlijk wel de weblog artikelen bij elkaar sprokkelen die dit hebben gedocumenteerd, maar ik hoop eigenlijk dat je gewoon van me wil aannemen dat deze bestaan en dat dit echt een dead end is.)
12 Stephen Hay op 23-04-2009 om 20:36 uur:
There is no important difference between XHTML 1.0 Strict as text/html and HTML 4.01 Strict. This fact makes a rehash of the "XHTML lie" discussion tiresome at best. There are plenty of situations when XML syntax can be an advantage, and it doesn't hurt when it's not.

For the "switchers", talk of finding it hard to not close all tags is ridiculous, as there are (AFAIK) only 13 void elements, some of which are rarely used. Not hard to remember.

Anyone wanting to jump on the bandwagon and "switch" back to HTML 4.01 would be better off just writing carefully crafted HTML5, because it's completely possible to do. That would actually give you a perceivable advantage, for the same reasons you'd want to already use some of CSS3.

Of course, Raph does have a point regarding semantic web right now, but as HTML5 advances, so will the accommodation of semantic web technologies. It's evident that the semantic web is not in a big hurry.
13 Raph de Rooij op 24-04-2009 om 00:11 uur:
Ben het van harte eens met Stephen.

@Sander vL.: dank voor de reactie. ik heb een regel document.documentElement.className = 'js'; opgenomen in het JS-bestand en het losse 'noscript CSS bestand' gewoon in het algemene CSS-bestand te verwerken. Da's een stuk netter dan document.write; dat was echt zo'n gevalletje van 'moet ik nog een keer doen'.

Overigens heb ik een heel andere ervaring met het gebruik van XHTML met de correcte MIME type application/xhtml+xml. De vorige website op mijn werk serveerde XHTML 1.1 aan browsers die het aankonden en HTML 4.01 Strict met text/html aan de rest. Na de oplevering is die site zo'n vier jaar in gebruik geweest, op het laatste met tientallen redacteuren. Het ging allemaal zo vanzelfsprekend dat op een gegeven moment gewoon vergeten is wat voor een bijzondere website het eigenlijk was. Dus echt geen experimentele site met één ter zake kundige beheerder, maar gewoon de harde praktijk. Dus alle argumenten tegen die ik aldoor hoor maken op mij in elk geval niet zoveel indruk, zelfs niet als 'world-class experts' erbij worden gehaald.

Leuk hoor, die voortdurende discussies er over, maar veel van de technische tegenargumenten blijken weerlegbaar met ervaring die is opgedaan in de praktijk. Dan blijft er nog maar één tegenargument over dat wel degelijk hout snijdt: wat heb je er aan? Nou, niet veel dus was onze conclusie toen er een nieuwe site moest worden gemaakt. 't Is een beetje met het beklimmen van de hoogste berg. Wat heb je er aan? Bewijzen dat het kan, en dan heb je het wel zo'n beetje gehad...

Achteraf bekeken was het toch wel een 'world-class' prestatie van Sjoerd Visscher van Q42, de bouwer van de website. Zie ook http://w3future.com/weblog/2004/10/.
En jammer dat-ie er niet meer is, want eigenlijk hoort-ie in een 'hall of fame' thuis...

Voor wat betreft je opmerkingen over RDF en het semantisch web: daar ben ik het van harte mee oneens. RDF is niet primair bedoeld voor menselijke consumptie, maar voor apparaten als reasoning engines. Voor de overheid, die door een belangrijk deel van de buitenwereld wordt gezien als één (ondefinieerbaar) geheel kan het heel bruikbaar zijn. Want in werkelijkheid bestaat 'de overheid' niet: het zijn zo'n 1600 semi-autonome eenheden. Maar ze worden wél geacht naadloos met elkaar samen te werken en geïntegreerde diensten te verlenen. Een beetje hulp met slimme ICT-oplossingen kan daarbij echt geen kwaad.
En XHTML, met en zonder RDFa, kan daarbij nog een heel nuttige rol vervullen. En HTML5 trouwens ook. Zodra het stabiel genoeg is en een adequate browser support heeft, uiteraard.
14 Raph de Rooij op 24-04-2009 om 00:18 uur:
Even nog iets verduidelijken. Er staat in mijn reactie (#13):

En jammer dat-ie er niet meer is

Daarmee bedoel ik de website en dus niet Sjoerd, Die leeft nog voor zover ik weet..

BTW, ook Sjoerd verdient wat mij betreft een plekje in de 'hall of fame' ;-)
15 Sjoerd Visscher op 24-04-2009 om 11:30 uur:
Dank Ralph voor je lovende woorden! En ja ik leef nog.

@Sander: je hebt gelijk, als je xhtml wilt opleveren MOET je hele site met XML werken. Zo werkte advies.overheid.nl ook. Geen string concat was erin te vinden. Ik heb hier de testsite van Advies Overheid.nl nog draaien en je trucje met %ef%bf%bf kreeg de site niet down.

Je kan users inderdaad niet XML laten typen, dat moet met een wysiwyg tool. Dat kan bijvoorbleed met Xopus, maar bij Advies Overheid.nl hebben we een veel simpelere oplossing gebruikt: gebruik een standaard WYSIWYG browser based HTML editor, maar converteer de HTML bij het saven naar XML met javascript in de browser. Dat is namelijk heel makkelijk in de browser: loop door de HTML DOM boom heen, en bouw een equivalente XML DOM boom. Je kan het ook op de server doen mbv HTML Tidy achtige tools, maar de kans op fouten is naar mijn ervaring dan groter.
16 Sjoerd Visscher op 24-04-2009 om 11:37 uur:
Eeen toevoeging: Bovenstaande geldt net zo goed voor HTML4/5 sites. De enige garantie voor een consistent compleet valide site is als je de gehele server-side implementatie in XML doet. Bijv. die UTF-8 truc maakt een HTML site net zo invalide als een XHTML site, alleen zeurt de browser er minder over.

Bij Q42 is het nog steeds zo dat alle HTML via XML met XSL wordt gegenereerd. Het is de enige manier om te garanderen dat je niet weer eens een keer vergeet die ampersand te escapen in je href attribuut.
17 Frank van Gemeren op 07-05-2009 om 20:53 uur:
Het argument van het gebruik van Transitional tov Strict voor de linkjes is vanuit het grotere geheel gezien niet sterk.

Het is een gedragsbeschrijving. Dit hoort voor de puurheid niet thuis in de structuur van HTML. Dit is dan ook de reden dat het niet in HTML zit, maar wel acceptabel is in de DOM (waar 'target' nog wel in zit)

Natuurlijk is er de kans dat JS uitstaat, zodat het niet werkt.

De vraag is of je men het 'puurheids' argument accepteert (immers gebruiken jullie ook CSS voor de opmaak ipv bold-tags), of dat het voor het gebruiksgemak de principele scheiding toch opzij wordt gezet.
18 Raph de Rooij op 12-05-2009 om 15:08 uur:
@Frank van Gemeren:
Het 'puurheids argument' staat - in elk geval in de Webrichtlijnen - voorop. De wens om links in een nieuw browservenster te openen kan op zichzelf best legitiem zijn, maar de meest voor de hand liggende oplossing, gebruik/misbruik van het TARGET attribuut is dat naar mijn mening niet. Je stelt terecht dat het hier gaat om gedrag en dat hoort, net als CSS, niet thuis in de mark-up.

Een paar jaar geleden alweer heb ik hierover een weblogbijdrage geschreven, zie http://stijlgids.overheid.nl/actueel/weblog/links_openen_in_een_nieuw_venster/ en het in dat stuk genoemde artikel. Dat stuk heeft volgens mij nauwelijks aan actualiteitswaarde ingeboet...
Plaats een reactie