Oorspronkelijk was het de bedoeling dat ik (Bas) tijdens de vakantie van Coen een onderwerp zou schrijven over het afscheid van Krezip, waar Coen eerder deze maand plotseling tegenover mij over begon.
Tijdens het schrijven van een bericht hierover kwam een totaal ander bericht naar buiten, wat iets dichter bij webontwikkeling ligt dan een bericht over Krezip. Het W3C heeft namelijk aangekondigd eind dit jaar te stoppen met de ontwikkeling van XHTML 2, ten faveure van HTML 5.
XHTML 2 was gedurende lange tijd een vrij controversiële ontwikkeling, aangezien het zou gaan breken met de gewoontes en praktijken van XHTML 1 en HTML 4. De laatste maanden ging de aandacht echter steeds meer uit naar HTML 5, dat wel gewoon backwards compatible wordt. En nu is dus besloten om meer mensen op het HTML 5 project te zetten.
Discussie met Coen
Diverse keren heb ik een discussie gehad met Coen, over de zin en onzin van XHTML. Al meer dan een jaar geleden heb ik zelf al besloten geen gebruik meer te maken van XHTML, maar gewoon HTML te gebruiken, zoals diverse mensen al gedaan hebben (zie bijvoorbeeld hier). Veel mensen vinden dat in eerste instantie een vreemde gedachte, aangezien ze bij HTML denken aan tabellendrama’s en het niet gebruiken van semantische opmaak (met bijvoorbeeld de <em> of <strong> elementen).
Wat echter vaak vergeten wordt, of helemaal niet bekend is, is dat de meeste webpagina’s die in XHTML zijn geschreven, als HTML aan de browser worden geserveerd, doordat het mimetype wat de server aan het bestand koppelt bijna altijd text/html is, terwijl voor XHTML het mimetype application/xhtml+xml is. Omdat Internet Explorer die laatste niet begrijpt, wordt er dus slechts zeer sporadisch gebruik van gemaakt. Je bent dus alleen jezelf voor de gek aan het houden. Maar er zijn nog meer redenen waarom je gewoon HTML zou moeten gebruiken:
- Het afsluiten van open elementen, zoals
img,linkofmeta, met een slash, omdat XML dat voorschrijft, heeft geen nut voor de schrijver ervan, want die zal toch zelf wel weten welk element open of gesloten is. - Lege attributen zijn niet toegestaan in XML, en dus ook niet in XHTML. Daardoor krijg je vreemde notaties zoals bij het
checkedattribuut (van hetinputelement). Hierdoor krijg je dus notaties alschecked="checked", wat voor een computer misschien eenvoudiger is, maar voor wij mensen is het enigszins belachelijk te noemen. - HTML heeft geen XML Namespace nodig (niet dat de meeste in XHTML geschreven pagina’s dit hebben, de W3C Validator geeft geen foutmelding als deze ontbreekt, terwijl dat wel zou moeten). Browsers die wel kunnen omgaan met XHTML, hebben echter problemen met het ondersteunen van verschillende namespaces in een XHTML-document. Zo wordt het uiteindelijk nog niet mogelijk om diverse XML-variaties door elkaar te gebruiken, wat het sterkste punt van XHTML had moeten zijn.
Sommige punten kunnen voor personen die minder goed thuis zijn in XML onduidelijk overkomen. Het helpt daarbij niet dat ik een vrij degelijke XML-cursus heb gehad enkele maanden geleden. Laten we het erop houden dat het in XML mogelijk is om prefixes (namespaces) toe te voegen aan elementen, zodat je meerdere varianten van XML door elkaar kan gebruiken (bijvoorbeeld XHTML waarin een blok MathML voorkomt).
Het redelijk alternatief
HTML 5 introduceert enkele nieuwe structuurelementen, zoals nav en footer. Hoewel de meeste browsers deze elementen nog niet ondersteunen, kunnen we ze nog niet gebruiken. Wel kan je je webpagina’s er op voorbereiden, door de elementnamen alvast als de namen van de css-classes te gebruiken, zoals in dit uitstekende artikel uit de doeken wordt gedaan. Dit gebruik van naamgeving neemt de laatste maanden steeds meer toe, en het lijkt daadwerkelijk een nieuwe trend te gaan vormen in webontwikkeling. Een goede stap, zodat de browsersmakers lichte druk zullen gaan voelen om ook echt wat met HTML 5 te gaan doen.
Enkele van de gelinkte artikelen in dit onderwerp komen uit Coen’s favorieten op Delicious. De meest recente bookmarks van hem zijn (na de vakantie) weer te volgen op de @CoenDaily Twitter. Coen is over een paar dagen weer terug uit The Big Apple, en zal dan zoals vanouds weer berichten plaatsen op deze blog.




Krijgt HTML5 geen XHTML variant? Antwoord: jawel. Zover ik weet is alleen de ontwikkeling van XHTML 2 gestaakt i.v.m. gebrek aan terugwaardse compatibiliteit.
Ik vind X(HT)ML prettiger omdat het consistenter is. Elementen niet sluiten is wel makkelijk maar niet logisch en maakt het interpreteren van code moeilijker. “[..] Heeft geen nut voor de schrijver ervan” is onzin, je schrijft de code immers niet voor jezelf maar voor anderen die waarschijnlijk niet weten wat je bedoelt.
In principe maak je een webpagina om hem geparsed in een browser te laten zien, en niet om je codeprestaties te tonen, lijkt mij. Als je een template voor Wordpress maakt, zal de layout voor de klant belangrijker zijn dan de code. Een nette code is ook wel belangrijk natuurlijk, maar dat is bijna nooit de nummer #1 doelstelling.
Ten tweede kan je van de voordelen van XHTML alleen profiteren als de browser ook daadwerkelijk de webpagina als XML/XHTML parsed. Dat gebeurt op dit moment praktisch niet (zeg maar nooit), en in de plannen die tot zover bekend zijn van Internet Explorer, is hier ook geen aanpassing van te vinden. In principe ben je dus volgens de browser alleen maar slecht geformuleerde code naar de browser aan het sturen, die wordt genegeerd. Alle voordelen die XHTML zou bieden vervallen doordat de webpagina niet door de XML-parser gehaald wordt.
De meeste mensen zullen overigens dolblij zijn dat de browser gewoon in HTML-modus parsed, want al zit er ook maar één foutje in de XHTML, de pagina zal daardoor niets meer opleveren dan een foutmelding in plaats van resultaat. En als dat het gevolg is van code die standaard door bijvoorbeeld een CMS wordt gegenereerd, is dat extra zuur.
Ik test mijn XHTML vaak als XML, ‘t is erg strict maar levert wel vrijwel perfecte code op. Ik test mijn PHP code ook met E_ALL, hoe strikter hoe beter vind ik..
Met “anderen” bedoel ik eventuele ontwikkelaars die werk van je overnemen maar ook browsers die gebrekkige code verschillend interpreteren. Mijn sites valideren vaak direct en werken daardoor prima in de meeste browsers.
Je hoeft een document niet als XML te serveren om het als dusdanig te verwerken, de meeste XML bestanden zijn gewoon platte text. Het klopt dat er voor browsers momenteel niet veel verschil is maar ik denk liever vooruit dan dat ik me door Internet Explorer laat terughouden.