De site van H.J. de Boer

HTML5

Permalink  ·  Geplaatst op 20 februari 2006 om 15:37

Ik wil het eens hebben over HTML5, een specificatie die momenteel als Web Applications 1.0 door het leven gaat en poogt de hiaten op te vullen die HTML 4.01 en de verschillende XHTML-versies over laten. De specificatie wordt voorbereid door de WHATWG ofwel Web Hypertext Application Technology Working Group. De reden dat men aan een opvolger voor HTML is gaan werken onder de naam Web Applications 1.0, is het gegeven dat HTML ontworpen is voor het semantisch beschrijven van wetenschappelijke teksten. HTML wordt al lang niet meer alleen daarvoor gebruikt en met de snelle opkomst van webtoepassingen als veilingsites, zoekmachines, online shops, uitgebreide discussieplatforms en geavanceerde blogtools, heeft de taal een veel bredere toepassing gekregen dan oorspronkelijk was voorzien. HTML5 belooft een noodzakelijke aanvulling om een nog beter semantisch fundament onder dergelijke moderne internettoepassingen te leggen.

XHTML is dood
Waar het in internetland normaal gesproken erom draait om het nieuwste te doen of te hebben, is dit niet nuttig in het geval van XHTML. In het jaar 2000 kwam de recommendation van XHTML1 gereed bij het W3C: "A Reformulation of HTML 4 in XML 1.0" - HTML 4 in een XML-jasje dus. Meer is het niet en meer beoogt het ook niet te zijn. XHTML ís HTML, alleen geschikt voor gebruik met een XML MIME-type zodat je het document door een XML-parser heen kunt trekken. Zeker, XHTML is nieuwer dan HTML 4.01. Maar is nieuwer ook beter? Als ik voor een keuze tussen XHTML en HTML sta, moet ik die keuze normaal gesproken maken op basis van rationele afwegingen; in een bedrijfsmatige toepassing heb ik alleen te maken met aantoonbare voor- of nadelen. Mijn beslissing zal gebaseerd moeten zijn op een logische redenering en niet op een gevoelen, meeloperij, of het feit dat ik in verleiding ben gekomen door een buzz-word.

De note van het W3C over Media Types raadt aan om sites die in deze taal zijn geschreven, te versturen met application/xhtml+xml als MIME-type. Logisch, want het gaat om een bijzondere toepassing van XML. Pagina's in XHTML 1.1 mág je zelfs niet meer versturen met dat MIME-type, dat moet als application/xhtml+xml, aldus de note. Het MIME-type bepaalt wat voor document je hebt. Dit wordt meer dan duidelijk uiteengezet door Anne van Kesteren in MIME types matter; DOCTYPEs don't. Kortweg: het maakt volstrekt niet uit of je de HTML-syntax of de XHTML-syntax gebruikt, wanneer je dit document verstuurt als text/html. Elke browser zal dit parsen als HTML, als tag soup: het wordt door de SGML-gebaseerde HTML-parser van de browser verwerkt. Pas wanneer je application/xhtml+xml als MIME-type gebruikt voor je XHTML-document, vatten degelijke browsers dit op als XML. Pas dán heb je echte XHTML, dat namelijk zoals gezegd een herdefiniëring van HTML 4 in XML is. Pas wanneer XHTML als XML wordt verstuurd en behandeld, kun je genieten van de voordelen van de standaard; doe je dat niet, dan heb je geen enkele reden om XHTML boven HTML 4.01 te verkiezen.

Je hebt dus drie opties momenteel:

1. XHTML als text/html gebruiken
2. XHTML als application/xhtml+xml gebruiken
3. HTML als text/html gebruiken

Laat ik dit op volgorde behandelen:

1. XHTML als text/html versturen, wordt als schadelijk aangemerkt. Het zorgt voor een gebroken internet in de toekomst. Waarom? Hierom:
   • Developers schrijven XHTML en doen aannames die alleen gelden voor tag soup of HTML4 useragents, maar niet voor XHTML useragents, en vervolgens verzenden ze het als text/html.
   • De ontwikkelaars vinden dat het mooi werkt en dat ze een moderne website hebben.
   • Tijd verstrijkt.
   • Bij de developer groeit het bewustzijn (wellicht als Internet Explorer ooit application/xhtml+xml gaat ondersteunen) dat het beter is om zijn content te vesturen als application/xhtml+xml, aangezien het uiteindelijk toch draait om XHTML en dus een XML MIME-type verdient.
   • De developer ziet dat zijn site per direct stuk is en een dikke parse error geeft.
   • De developer verwijt XHTML dat het een slechte standaard is.
   Veel mensen zijn meegegaan in de hype van XHTML, maar hebben niet begrepen wat XHTML is. Ze hebben niet begrepen wat XML is. Ze weten niet wat well-formedness is. Ze verzenden XHTML als text/html, en weten niet dat de browser net zulke tag soup ziet als wanneer er ouderwetse HTML 3.2 gestuurd zou worden. Of het document nu valideert of niet: de browser doet zijn best om er wat van te maken wanneer hij text/html voor zijn neus krijgt, met een SGML-gebaseerde parser. Deze parser is vergevingsgezind. Een XML-parser is dat niet. XML eist well-formedness, een juiste character encodering en kennis van hoe XML omgaat met entities (bijvoorbeeld   en ©). De makkelijkste stap is om te beginnen met het document überhaupt te valideren (hoewel dat uiteraard geen well-formedness garandeert). Veel van de huidige documenten die momenteel een XHTML-doctype dragen, zijn stiekem invalid en / of malformed, alleen dat merkt de auteur ervan pas, wanneer hij ze ooit gaat verzenden als application/xhtml+xml, zoals het hoort. Dan slaat de XML-parser hem om de oren met een grote XML parse-error en daar blijft het bij: de hele pagina is onzichtbaar verder. XHTML als text/html zorgt voor een incompatible web in de toekomst. Dat mag met recht schadelijk genoemd worden. Bovendien levert XHTML als text/html ongeldige HTML op.
   
   
2. Wanneer XHTML met een XML MIME-type wordt verstuurd, wordt niet een vergevingsgezinde parser als de SGML-parser gebruikt, maar de zeer strikte XML-parser. Wanneer XHTML als écht XHTML en, aangezien het een XML-derivaat is, dus als XML-document wordt verstuurd, dan moet dit document well-formed zijn. Vanwege die eis zijn er enige aanpassingen gedaan aan de HTML 4 syntax: lege elementen als <br> of <script> zijn niet meer toegestaan, aangezien in een well-formed XML-document alle geopende elementen ook weer afgesloten moeten worden. De syntax is dus een heel klein beetje anders, maar dezelfde elementen worden gebruikt. Zoals eerder gezegd in dit stuk: in een bedrijfsmatige toepassing heb ik alleen te maken met aantoonbare voor- of nadelen; zoals ik mij niet zomaar zal laten overtuigen door een buzz-word, evenzo zal ik mij als rationeel wezen niet laten overhalen tot het gebruik van een nieuwe standaard vanwege slechts een kleine aanpassing in de syntax om XML-compliant te zijn. De vraag moet namelijk zijn waarom ik mijn HTML-document in de vorm van XML wil gieten. Heb ik dat nodig voor mijn toepassing? Met andere woorden, is er een zakelijke reden die rechtvaardigt dat ik de herdefiniëring van HTML in XML gebruik voor mijn documenten? Wat kunnen die redenen zijn? Het voordeel van het gebruik van een XML MIME-type is, dat je de XHTML kunt combineren met andere XML-gebaseerde markup languages (die dus door dezelfde XML-parser verwerkt worden), zoals MathML, embedded SVG, of RubyText. Als mijn applicatie deze toepassingen vereist dan heb ik een goede reden om mijn HTML in het XML-vat te gieten. De genoemde voordelen gaan dus alleen op, als je je document verzendt als application/xhtml+xml, dus als echte XML. Behoren gebruikers van Internet Explorer tot je doelgroep, dan heb je dus geen reden om XHTML te schrijven, aangezien je met text/html (naast het feit dat het schadelijk is) de voordelen van een XML MIME-type niet eens kunt benutten. Dit zal de komende jaren ook wel zo blijven nu het IE7 ontwikkelteam heeft besloten om in die versie nog geen ondersteuning te bieden voor application/xhtml+xml, zoals ik beschreef in "Over Internet Explorer 7, CSS 2.1 en bugs". Zelfs wanneer op basis van rationele overwegingen de keuze voor XHTML te verdedigen is, zijn er nog kanttekeningen te plaatsen. De foutafhandeling van XHTML is simpel: er wordt geen error correction gedaan, de XML-parser is zoals gezegd niet vergevingsgezind. Als je een fout maakt dan zul je dat voelen: met een grote parse error gaat je site als een nachtkaars uit. Je zult dus op elk moment de well-formedness en de validiteit van je document moeten kunnen garanderen, anders loop je een groot risico. Dit risico is zo groot, dat XHTML als business failure kan worden aangemerkt: XHTML als application/xhtml+xml is riskant.
   
   
3. Waar XHTML als application/xhtml+xml riskant is, en als text/html schadelijk, nutteloos en dus niet te verantwoorden, is valid HTML 4.01 als text/html veiliger en garandeert de grootste ondersteuning van zoekmachines en browsers. Met HTML 4.01 is dezelfde scheiding van presentatie en inhoud te maken als met XHTML. Met HTML 4.01 is hetzelfde strict doctype te gebruiken als met XHTML. HTML 4.01 wordt wel door de meestgebruikte browser begrepen en heeft dan nog het daarvoor bestemde MIME-type ook. HTML 4.01 heeft geen draconische foutafhandeling. HTML 4.01 gebruikt als text/html is volkomen juist en zal bovendien niet leiden tot een incompatible web.

XHTML gebruiken omdat het "schonere en slankere code" is of omdat je "semantischer en stricter" kunt schrijven, is nonsens. Dat kan allemaal in HTML 4.01, als je de standaard maar goed volgt. XHTML is namelijk de herdefiniëring van HTML 4.01 in XML-formaat, herinneren wij het ons nog? HTML 4.01 is hetzelfde als XHTML, alleen kun je met XHTML als application/xhtml+xml gebruikmaken van andere XML-gebaseerde talen die je kunt combineren met je XHTML-document. Niemand doet dat. Althans ik heb het in de praktijk nog bij geen website gezien. Waarom XHTML gebruiken als we het alleen voor standaard HTML aanwenden? Waarom jezelf al die problemen op de hals halen als je de echte X(HT)ML-toepassing ervan niet gebruikt? Dat is zakelijk niet te verantwoorden! Er is maar één conclusie: XHTML is dood. Verloren. Het kan niet meer gered worden.


XHTML is al teveel misbruikt om de problemen nog te kunnen herstellen. Mocht Internet Explorer ooit application/xhtml+xml gaan ondersteunen en webdevelopers krijgen door dat dat het juiste MIME-type voor hun reeds jaren oude 'XHTML'-pagina's is, dan gaan hun pagina's stuk. Ze blijven zitten met de erfenis van hun jarenlange koppigheid: een hoeveelheid layout en content die in de verste verte niet in overeenstemming is met de XML-standaard. Het W3C of de browserfabrikanten krijgen de schuld; het publiek accepteert niet dat al die sites van de ene op de andere dag niet meer werken en alleen maar lelijke parse errors uitspugen... en het XHTML-schip wordt verlaten door de opvarenden, die jarenlang hun sites op luchtkastelen van onwetendheid of onverschilligheid hebben gebouwd. Ik weet dat mijn eigen site al sinds meer dan een jaar als XHTML 1.1 aan fatsoenlijke browsers geserveerd wordt, maar: mét het juiste MIME-type. Ik kan well-formedness redelijk goed in de hand houden door het gebruik van HTML in mijn content te vermijden en in plaats daarvan gebruik te maken van een geavanceerde parser om BB-code om te zetten naar geldige XHTML. Dit voorkomt niet alle problemen, maar wel de meest voorkomende als entity encoding en dat soort zaken.

HTML heeft toekomst
We mogen stellen dat HTML de toekomst heeft. Wij mogen dat stellen, de gezaghebbende standaardenorganisatie W3C is het daar nog niet mee eens en werkt gestaag aan een specificatie voor XHTML2. Voor wat betreft het W3C zal er geen opvolger komen van HTML 4.01. De WHATWG denkt daar echter anders over. Deze werkgroep is een onofficiële en niet vastomlijnde samenwerking van een aantal browserfabrikanten, belanghebbenden en geïnteresseerden. De werkgroep is vastbesloten om een nieuwe versie van HTML uit te brengen onder de naam HTML5, om zo de ontwikkeling van webapplicaties eenvoudiger te maken. Op de vraag of de ontwikkeling van zo'n specificatie niet plaats zou moeten vinden bij het W3C of het IETF, antwoordt de werkgroep zelf:

Nu, dat is nog niet echt een antwoord, maar dat krijgen we van de specificatieredacteur, Google-medewerker en Opera-medewerker Ian Hickson:

Wat is HTML5?
HTML5 wil een backwards compatible opvolger zijn van zowel HTML4 als XHTML1. Het betekent dat geldige HTML4 ook geldige HTML5 zal zijn, maar ook dat geldige XHTML1 geldige HTML5 zal zijn. Jawel: de HTML5-specificatie voorziet in een HTML-variant en een XHTML-variant. Gesproken wordt dan ook over (X)HTML5, aangezien de specificatie voorziet in beide smaken, hoewel die naam me wat verwarrend lijkt. Met HTML5 kun je gebruikmaken van zowel een XML- als een HTML-serialisatie.
De W3C-tegenhanger XHTML2 voorziet niet in backwards compatibility met XHTML1. Dat betekent dat pagina's die in geldige XHTML1 geschreven zijn, niet zonder meer valid zullen zijn in XHTML2. Het kan een groot voordeel voor de populariteit van HTML5 (inclusief de XHTML-variant dus) zijn, wanneer diezelfde pagina's wél geldige HTML5 zijn. Echter... het W3C heeft het gezamenlijke voorstel van de Mozilla Foundation en Opera Software voor uitbreiding van HTML, DOM en CSS onder de noemer "Web Applications Markup Language 1.0" afgeschoten en wenst niet dat werkzaamheden hieraan onder de vlag van het W3C plaatsvinden: het merendeel van het consortium (waar overigens mensen van Opera en Mozilla ook deel van uitmaken) geeft namelijk de voorkeur aan ontwikkeling van XHTML2. Wat hadden we zojuist ook alweer geconstateerd? Ohja... XHTML is dood. Het W3C trekt aan een dood paard.

HTML was een taal zonder gedefinieerde foutafhandeling; browserfabrikanten moesten zelf bepalen hoe hun product omging met ongeldige markup. Uiteraard had elke browsermaker hier zijn eigen visie op, waardoor de parsing op een verschillende manier plaatsvond en pagina's er in verschillende browsers verschillend uit gingen zien. XML werkt heel anders en doet niet aan foutcorrectie, maar levert simpelweg een parse error op als er een fout in het document zit, zoals we hebben gezien. HTML5 heeft het beste van beide werelden. De specificatie schrijft een niet-draconische foutafhandeling voor zoals XHTML noodzakelijk heeft wanneer het als XML wordt verstuurd. Dit betekent dat de eindgebruiker niet blijft zitten met een onbegrijpelijke foutmelding als het document syntactisch onjuist is, maar altijd de informatie zal krijgen. Hiermee is een groot probleem van XHTML1 weggenomen: de reden dat sommigen het als 'business failure' beschouwen.

Naast een nauw omschreven foutafhandeling zal HTML5 een verbetering vormen op HTML4 en voorzien zijn van nieuwe elementen die beter toegespitst zijn op het hedendaagse web. De taal is geoptimaliseerd en klaar voor internettoepassingen in plaats van slechts voor wetenschappelijke teksten. Zo bevat de specificatie voorzieningen voor contextmenu's, een semantisch menu-element (een blocklevel-element dat li-elementen kan bevatten), een section-element (een semantische oplossing voor hoofdstukken of tabbladen in een dialoogvenster), een article-element voor bijvoorbeeld forumposts of weblog-items, een header-element en een footer-element. Verder zullen er verschillende nieuwe functies en objecten toegevoegd worden die passen bij moderne webapplicaties. Bovendien zal niet worden toegestaan dat de XHTML-variant als text/html wordt verstuurd, maar dat is ook helemaal niet nodig aangezien de HTML-variant zal voldoen voor veruit de meeste mensen. XHTML is en blijft trouwens dood, ook wanneer HTML5 een XHTML-serialisatie tot de mogelijkheden laat behoren. Wellicht doet men dat, om compatible te kunnen blijven met XHTML2, in de hoop niet uitgevlakt te worden. Helaas als ik diep in mijn hart kijk, moet ik bekennen dat ik betwijfel of HTML5 ooit een W3C-standaard zal worden. Ik denk dat XHTML2 de voorkeur krijgt.

XHTML is dood, leve HTML5! Laten we nu alleen hopen dat het W3C terugkeert op zijn schreden en het wankele pad van XHTML verlaat. Laten we hopen dat het W3C afstapt van zijn koppigheid en inziet dat HTML inderdaad de toekomst heeft. De behoefte aan buzz-words en X-factors voor de internetbusiness is voorbij. De zeepbel is al enkele jaren geleden gebarsten, het internetpubliek is nu toe aan dingen die écht zijn, die puur en volgens logische standaarden zijn. Het is nu de tijd om te werken aan zaken die zakelijk te verantwoorden zijn en die het onderwerp van beslissingen op rationele basis zijn, in plaats van het onderwerp van beslissingen op basis van onderbuikgevoelens. Het zou een goed signaal zijn, wanneer het W3C de wereld duidelijk maakt dat XHTML een vergissing is en daarom zakelijk gezien gefaald heeft. HTML heeft het internet groot gemaakt, XHTML heeft daar amper aan bijgedragen. Het wordt tijd dat HTML weer steun van het standaardenlichaam krijgt om het internet voort te kunnen stuwen naar een nieuw tijdperk. HTML is niet uitgeput, HTML5 is daar helemaal klaar voor. En daar is geen XML bij nodig.