Bonjour,
Voir les exemples de code-type donnés dans
http://www.blog-and-blues.org/weblog/2004/08/16/275-encodage-caracteres-xhtml (en dépit du titre de cet article portant plus spécifiquement sur le
charset).
Et pour faire plus généralement le point:
Le type de contenu d'un fichier HTML ou XHTML n'est pas prioritairement déterminé par l'élément meta. Celui-ci, comme son attribut
http-equiv l'indique, n'est qu'un rappel du type de contenu indiqué par l'en-tête HTTP
Content-type envoyé par le serveur. Cet en-tête sera prioritaire dans tous les cas, quelque-soit le contenu de la meta.
Le type de contenu choisi, qu'il soit
text/html ou
application/xhtml+xml doit donc être fixé via cet en-tête. Par exemple, sur un serveur Apache, via la configuration du serveur, ou bien une directive dans le fichier .htaccess, ou bien une instruction
header.
Dans les deux cas de type de contenu, le rôle de la
<meta http-equiv="content-type" est double, et diffère côté serveur et côté client:
- côté serveur, il permet d'automatiser, si la configuration serveur est prévue à cet effet, l'envoi de l'en-tête HTTP correspondant.
- côté client (navigateur) cependant, c'est la seconde partie de l'information donnée par cette meta qui sera exploitée: le
charset sera en effet déterminé en fonction de cette meta lorsque le fichier est enregistré, puis lu localement. En revanche, le fait que la
meta répète le type de contenu n'est pas déterminant pour le navigateur, comme tu l'as constaté.
Dans le cas d'un fichier servi en
appplication/xhtml+xml, de plus, c'est en fait le
prologue XML qui permet de faire le rappel local du type de contenu et du charset. Non la meta.
Enfin, concernant les extensions de fichiers: tout comme les serveurs, les clients et leurs applications (les navigateurs), peuvent être configurés pour associer un traitement spécifique à une extension donnée. Mis cela n'a aucun caractère obligatoire, et les extensions .xhtml, .html, .htm etc. ne permettent pas de préjuger du traitement final du document. Du point de vue du Web sémantique, le nom et l'extension d'un fichier n'ont en effet aucune signification quant à la nature de la ressource qui y est associée via l'URI.
En résumé, si un document XHTML1.0 doit être servi avec le type de contenu application/xhtml+xml (ce qui n'a aucun caractère obligatoire à la différence d'XHTML1.1):
- adresser le type de contenu application/xhtml+xml via l'en-tête HTTP
- ajouter le prologue xml pour le rappel du type de contenu et surtout du charset si différent d'utf-8
- ommettre la meta
Et naturellement, puisqu'IE et d'autres clients ne peuvent traiter correctement un document servi de cette manière:
- tester la préférence exprimée par le client (en-tête HTTP
Accept) pour vérifier s'il déclare accepter application/xhtml+xml
- si ce n'est pas le cas, faire les adaptations nécessaires dans le code XHTML pour respecter les règles de compatibilité HTML/XHTML (voir spec XHTML1.0, appendice)
- envoyer l'en-tête HTTP
content-type text/html
- le répéter avec le charset dans la
meta
- ne pas mettre de prologue XML (inutile, et problème de doctype switching pour IE 6.0)
Et
surtout, pour faire plus bref: 80% des sites actuels en XHTML1.0 n'ont aucune vocation ni aucune capacité à être servis en
application/xhtml+xml, et leur type de contenu le plus approprié est
text/html...
Modifié par Laurent Denis (14 Aug 2006 - 17:55)