Cet article de Peter Provost indique une solution pour empêcher Internet Explorer de proposer le téléchargement des fichiers délivrés en tant qu'application/xhtml+xml, grâce à un hack de la base de registre. Il explique ainsi les choses: Bien qu'un grand nombre de gens pensent qu'Internet Explorer ne supporte pas ce type MIME, la véritable réponse est qu'il ne lui manque qu'une entrée dans la base de registre pour lui dire ce qu'il doit en faire.

Malheureusement, ceci est totalement faux. Internet Explorer n'est pas capapable de traiter les documents servis en tant qu'application/xhtml+xml. Tout ce que ce hack fait se limite à lui dire de traiter le document en tant que text/html, en attribuant le CLSID pour text/html à l'entrée application/xhtml+xml dans la base de registre.

Sachant qu'il y a déjà des agents utilisateurs capables de traiter le type mime correct, à quoi cela sert-il donc d'ajouter une entrée au registre pour qu'Internet Explorer traite le contenu en tant que text/html ? Cela n'affecte pas l'entête ACCEPT envoyé par Internet Explorer (Heureusement). Dès lors, tous les sites qui font de la négociation de contenu vont continuer à lui envoyer le contenu en text/html.

Du point de vue d'un développeur Web, cela n'est d'aucune aide. Informer ses visiteurs que ce site sera mieux rendu dans tel navigateur avec telle résolution est déjà une démarche assez ridicule: la plupart des développeurs sont à présent assez sensés pour avoir compris qu'un visiteur n'a aucune envie de changer son navigateur et sa résolution juste pour voir votre site. Mais cette solution franchit un pas de plus : afin de voir ce site Web, vous devrez ajouter cette entrée à votre registre Windows.

Même en supposant qu'un utilisateur d'Internet Explorer sous Windows décide de faire ainsi, et en supposant que des sites Web servent leur contenu en tant qu'application/xhtml+xml quelque-soit les capacités du navigateur, quel serait le résultat exact de ce hack ;?

Les déclarations XML de feuilles de styles seront totalement ignorées, et avec elles toutes les autres fonctionnalités XML comme xml:base. Le contenu ne sera pas parsé pour vérifier s'il est bien formé. Le balisage aura toujours des éléments implicites, comme tbody si celui-ci n'a pas été explicitement ajouté. Sans compter toute la somme de problèmes de script, tels que les commentaires CDATA ignorés, tandis que les commentaires SGML, document.write et innerHTML seront tous respectés.

Si un développeur doit utiliser XHTML, et s'il se soucie d'Internet Explorer, il doit soit délivrer son contenu en tant que text/html en suivant les directives de compatibilité avec HTML, ou utiliser la négociation de contenu pour adresser du application/xhtml+xml aux agents utilisateurs qui le comprennent, et du text/html aux autres. Tout ce que fait ce hack est de dire à Internet explorer de traiter ce contenu application/xhtml+xml en tant que text/html. Or, la plupart des contenus application/xhtml+xml ne suivent pas les directives de compatibilité HTML, ce qui signifie qu'Internet Explorer devra recourir encore plus que d'habitude sur ses procédés de recouvrement d'erreur.

Une solution bien plus simple est de se procurer un meilleur navigateur.