HTML5 backwards compatibility
Permalink · Geplaatst op 21 februari 2006 om 14:48
Hoe uitgebreid het stuk ook was dat ik gisteren schreef over "HTML5", toen ik vanmiddag nog wat over dat onderwerp zat te lezen op een Duits weblog, bemerkte ik dat ik vergeten ben iets belangrijks te zeggen. Ik heb het gehad over het feit dat HTML5 backwards compatible zal zijn met HTML 4.01 en over het feit dat XHTML 2.0 niet backwards compatible zal zijn met XHTML 1. De XHTML 2.0 Working Draft schrijft daar over:
quote: http://www.w3.org/TR/xhtml2/introduction.html#backCompat
Because earlier versions of HTML were special-purpose languages, it was necessary to ensure a level of backwards compatibility with new versions so that new documents would still be usable in older browsers. However, thanks to XML and style sheets, such strict element-wise backwards compatibility is no longer necessary, since an XML-based browser, of which at the time of writing means more than 95% of browsers in use, can process new markup languages without having to be updated.
Dankzij XML is backwards compatibility niet langer nodig, want XML-gebaseerde browsers kunnen die nieuwe markup verwerken zonder ge-update te hoeven worden, zo zegt men. De vraag is dan welk MIME-type dwingend voorgeschreven zal worden voor XHTML 2.0. Wellicht zal in tegenstelling tot XHTML 1.1 gaan gelden dat het met application/xml als MIME-type verzonden moet worden, gezien de testpagina die zowel in Internet Explorer, als in Mozilla, Firefox en Opera werkt met dat MIME-type. In Internet Explorer? Jazeker, deze browser heeft namelijk best wel een XML-parser aan boord en daar kan XHTML 2.0 dus gewoon gebruik van maken. Het schort bij IE6 en IE7 alleen aan ondersteuning voor application/xhtml+xml, het voorgeschreven MIME-type van XHTML 1.1; dáárom werkt XHTML nu niet in de browser van Microsoft.
Overigens lijkt het me van inconsequent beleid te getuigen als nu het application/xhtml+xml mediatype weer verlaten zou worden: dat lijkt meer van praktische noodzaak te getuigen dan van goed doordachte theorie. Verder zie ik XHTML 2.0 als application/xml ook nog niet direct een succes worden in bestaande browsers. De zojuist gelinkte testpagina werkt via een XSL-stylesheet die de XHTML 2.0 converteert naar XHTML 1.0; dergelijke omslachtige eisen lijken me niet bevorderlijk voor een snelle adoptie van zo'n standaard door webdevelopers die voor een mainstream doelgroep ontwikkelen.
Of HTML5 daar dan het antwoord op is, blijft natuurlijk een beetje in het midden. Toch denk ik dat de backwards compatibility een groot voordeel voor het bedenksel van de WHATWG kan zijn. Een geldig HTML 4.01 document zal ook geldig zijn in HTML5. Developers vinden het fijn als ze niet bestaand werk opnieuw hoeven te doen; een argument dat wellicht uiteindelijk wel voor de praktische doorslag gaat zorgen. Bovendien moet volgens de XHTML 2.0 Working Draft elke browser voorzien zijn van ondersteuning voor XForms en XML Events. Gezien de weinige haast die Microsoft maakt met de volledige en juiste implementatie van CSS2.1, en een juiste ondersteuning van XHTML 1.1 (dus met het bijbehorende MIME-type), betwijfel ik of dat zo gauw van de grond komt in Redmond.
Persoonlijk zie ik dan nog eerder de uitbreidingen op HTML 4.01 in de vorm van HTML5 toegevoegd worden. Voor wat betreft de XHTML-variant van die specificatie staat men op gelijke hoogte met XHTML 2.0: XML documenten met elementen uit de XHTML-namespace die de nieuwe features uit de Web Applications specificatie gebruiken "must be sent using an XML MIME type such as application/xml or application/xhtml+xml and must not be served as text/html." Ook daar staat de gebrekkige ondersteuning door Internet Explorer van application/xhtml+xml dus niet in de weg. Het zal simpelweg afwachten worden welke van deze twee voorstellen het uiteindelijk redt tot standaard voor de komende jaren: XHTML 2.0 of HTML5.