Het probleem van XHTML

XHTML, een afkorting die staat voor Extensible HyperText Markup Language. De bedoeling is dat deze standaard op den duur HTML (HyperText Markup Language) moet gaan vervangen, de taal waarmee het mogelijk is om websites te bouwen. Maar volgens Anne van Kesteren zijn gebruikers én browsers bij lange na nog niet klaar om met XHTML overweg te kunnen en zal het nog een flinke tijd duren voordat XHTML ook écht aanslaat.

XHTML heeft een probleem en dat probleem begint langzamerhand bekend te worden. Het draait om MIME-types. Het officiële MIME-type voor XHTML is application/xhtml+xml, terwijl het MIME-type van HTML text/html is. XHTML is gebaseerd op XML en het gaat mis op het moment dat je in plaats van een XML MIME-type die van HTML (text/html) gaat gebruiken. Op het moment dat je text/html als MIME-type gebruikt zal je document door de meeste huidige browsers als niet-valide HTML gezien worden. Hieruit kun je concluderen dat je, omdat je in feite gewoon HTML gebruikt, dan geen enkel voordeel van XHTML meer hebt. De voordelen van XHTML liggen niet in het veranderen van de doctype declaratie en het aanpassen van de syntaxis die je voor HTML gebruikt, maar liggen in het MIME-type. Dat kun je nog verder uitbuiten als je ook daadwerkelijk voordeel haalt uit het gebruik van dat MIME-type. Het echte voordeel van XHTML zit hem in het feit dat je het kunt gebruiken in combinatie met andere op XML gebaseerde markup talen, zoals MathML, SVG, XForms en XHTML Ruby.

Gebruik je XHTML zonder het te mixen met iets anders, dan heeft het, gezien de implementatie in sommige browsers, een aantal nadelen ten opzichte van HTML. De browsers die XHTML (als application/xhtml+xml) aankunnen zijn Mozilla, Opera, Safari en Konquerer. Deze browsers hebben geen van allen het opbouwend laden van XML geïmplementeerd. Het probleem is dan dat eerst het gehele document moet worden ingeladen voordat het aan de bezoeker getoond wordt. Mocht je een erg groot document hebben, dan kan dat erg storend werken. Ook bij kleinere documenten kan dit al snel zichtbaar zijn, maar dat hangt meer af van het type connectie dat de bezoeker gebruikt.

Naast het inladen van het document is er ook het probleem dat de huidige sites die XHTML op een ‘correcte’ manier gebruiken (zonder het te ‘mixen’ met andere XML talen) veelal de XHTML opbouwen zonder gebruik te maken van het DOM en andere middelen om te garanderen dat de gegeneerde XHTML correct is. Deze sites hebben meestal een soort mechanisme ingebouwd dat browsers die application/xhtml+xml niet ondersteunen HTML of hetzelfde document als text/html krijgen. Aangezien er een redelijke kans bestaat dat die documenten op een dag ill-formed worden (syntactisch incorrect), heb je als gebruiker van een browser die XHTML zal ondersteunen op een dergelijke site nadeel. Naast het feit dat de site trager wordt getoond loop je ook nog de kans dat je een geel scherm te zien krijgt met daarop in rode letters een foutmelding (Mozilla gebruikt dat). De ‘Mozilla Web Author FAQ’ geeft dat als volgt weer:

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofitted to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).

Hoewel XHTML als text/html eigenlijk nooit gebruikt zou moeten worden, is het volgens de XHTML 1.0 specificatie wel toegestaan mits je appendix C volgt. Hoewel het gebruiken van XHTML in dat geval geen voordelen oplevert, zijn er mensen die vinden dat het ‘gewoon beter’ is. Het probleem is echter dat op het moment dat je dat doet, je bijna zeker weet dat je document ‘ill-formed’ geraakt. Verder treden er, op het moment dat je overstapt naar application/xhtml+xml als MIME-type, nog enkele andere nadelen op. Zo zullen je scripts hoogstwaarschijnlijk niet meer werken. Of omdat ze niet omgaan met namespaces, wat redelijk logisch is in een HTML document of omdat je document.write gebruikt en dat wordt niet ondersteund in een XML omgeving (zie ook de uitleg van Ian Hickson). Verder kun je problemen krijgen met CSS. Dat is het geval wanneer je de background property gebruikt op het BODY element en de waarden daarvan niet meer doorgegeven worden aan de ‘canvas’. Dit gebeurt in XML documenten alleen nog maar als background gebruikt wordt op het root element (het HTML element in XHTML documenten). In text/html documenten kun je overflow gebruiken op zowel het BODY als HTML elementen. Door de browser wordt dit dan op de viewport gezet zodat je kunt instellen of het document al dan niet een scrollbar heeft. In XML documenten is dat niet meer mogelijk. Als je daar overflow gebruikt op welk element dan ook, zal het nooit op de canvas gezet worden.

Hoewel XHTML leuk is om mee te experimenteren, is het gewoon nog niet klaar om gebruikt te gaan worden. Enerzijds omdat de mensen die het gaan gebruiken eigenlijk HTML eerst beter moeten leren begrijpen en anderzijds omdat er nog veel problemen mee zijn en de browser die nu nog het meest gebruikt wordt het niet ondersteund.

Dit artikel verscheen in het februari nummer 2005 van OpenMagazine. Behalve enkele wijzigingen is het artikel hetzelfde. Vorige maand schreef dezelfde auteur ‘Karaktercodering is nog een ondergeschoven kindje’ (UTF-8).