Plan de site — Navigation
Blog & Blues Techniques et Standards de la Qualité Web

Accueil > weblog

- Lire le billet précédent - Lire le billet suivant -

XHTML1.1, beaucoup de bruit pour rien

Par Laurent Denis, le 11 juin 2004.

Ah... Me voilà encore à jouer les rabat-joie : très joli, le passage au XHTML1.1. Mais maintenant, il n'y a plus qu'à... remettre ça avec le bon vieux DocType XHTML1.0

En effet, à la différence du XHTML1.0, le XHTML1.1 :

Pour ceux qui se posent la question, disons que le type mime est une information envoyée par le serveur qui indique au navigateur ce qu'il va recevoir :

  • du HTML ;
  • du XML ;
  • une image GIF, PNG...
  • de la soupe ;
  • des brocolis ;
  • ou une claque.

Actuellement, une page servie incorrectement en text/html... c'est de la soupe. Coup de bol, les navigateurs s'en accommodent et font comme si c'était du HTML.

Passer en application/xhtml+xml ne serait pas une bonne solution, car :

  • Ce type mime n'est pas supporté (entre autres) par Internet Explorer (Win et Mac). Le document se transforme alors en brocolis à télécharger.
  • Le document étant interprété par les navigateurs Gecko et par Opera comme étant du XML, il ne doit comporter aucune erreur de syntaxe sinon... c'est la claque ! Le moteur de rendu du navigateur s'arrête sur l'erreur, affiche un message d'alerte et la suite du code XHTML. On peut être un peu masochiste et apprécier ce mode de validation radical (c'est mon cas et celui de Denis Boudreau aussi, il me semble), mais il faut être sûr de bien maîtriser sa syntaxe ! Ce serait encore jouable dans certains cas, mais ce serait très dangereux par exemple dans un weblog où les commentaires et trackbacks risquent d'amener du code invalide : Denis Boudreau témoignera (avec accablement) que j'ai souvent (et involontairement) dézingué son CyberCodeur juste avec la petite esperluette du Blog & Blues de ma signature dans un trackback...

Déclarer correctement du XHTML1.1 est donc plutôt contraignant :

  • Il faut faire de la négociation de contenu au niveau serveur pour n'envoyer du XHTML1.1 en application/xhtml+xml qu'aux navigateurs qui déclarent le supporter, et du XHTML1.0 en text/html aux autres 
  • Les règles de compatibilités XHTML1.0-HTML doivent être appliquées lorsque le document est envoyé en tant que text/html, ce qui nécessite quelques adaptations du code XHTML1.1 ;
  • Pas de droit à l'erreur en application/xhtml+xml sous peine de voir le navigateur se fâcher.

Et ces contraintes n'apportent... aucun avantage concret pour la quasi-totalité des pages concernées. En effet, XHTML1.1 sert principalement à intégrer un élément supplémentaire (le module ruby) : seul un besoin réel d'utiliser l'élément ruby semble pouvoir justifier la décision d'enfreindre le should not be served as text/html. Or ruby est d'une portée très limitée en français...

Trackbacks

Les trackbacks pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.

Commentaires

Gloom, le 11 juin 2004

Et en plus, on se marginalise des vieux navigateurs en ne pouvant plus utiliser la redondance name="..." id="..." et lang="..." xml:lang="...".

Mais au fait, est-ce que, en XHTML1.0 strict, on peut utiliser l'attribut lang sans redondance avec xml:lang ?

Laurent Denis, le 11 juin 2004

Oui, on peut utiliser à la fois lang et xml:lang par souci de compatibilité. La spécification XHTML1.0 recommande même la redondance, en fait. Voir l'appendice C. HTML Compatibility Guidelines.

Gloom, le 11 juin 2004

Je reformule ma question (mais, j'ai cru comprendre sur la page que tu as lié que la réponce est non):

En XHTML1.0 strict, peut-on utiliser l'attribut lang SEUL (sens xml:lang) ?

Laurent Denis, le 11 juin 2004

Désolé, je n'avais pas saisi. Formellement, oui, une page XHTML1.0 strict n'utilisant que lang est valide (c'est le cas de celle-ci, en principe) :

<!-- internationalization attributes
  lang        language code (backwards compatible)
  xml:lang    language code (as per XML 1.0 spec)
  dir         direction for weak/neutral text
-->
<!ENTITY % i18n
 "lang        %LanguageCode; #IMPLIED
  xml:lang    %LanguageCode; #IMPLIED
  dir         (ltr|rtl)      #IMPLIED"
  >
Document Type Definitions - XHTML-1.0-Strict

glandium, le 13 juin 2004

> Or ruby est d'une portée très limitée en français...

Et d'un intérêt limité en japonais...
glandium.org/2004/02/15/4...

Pour ce qui est de faire du xhtml 1.1, il suffit d'avoir un moteur basé sur XML, plus aucune erreur n'est possible alors... C'est ce que je fais, et ça marche très bien. Bon, il n'y a pas encore de commentaires mis en place, mais même quand les commentaires seront en place, les erreurs, si jamais il y en a, exploseront côté serveur avant d'exploser côté navigateur...

Laurent Denis, le 13 juin 2004

La gestion des erreurs n'est pas un obstacle rédhibitoire, en effet (que l'on traite uniquement en XML ou non, dès lors qu'il y a un processus de validation). En revanche, pourquoi sers-tu du XHTML1.1 en text/html à Internet Explorer ? Puisque tu pratiques déjà la négociation de contenu, il t'es possible de gére le DocType selon le type mime envoyé...

glandium, le 13 juin 2004

Parce que je DOIS servir du XHTML 1.1 pour le ruby... (et que j'ai rien prévu pour ne générer en XHTML 1.1 que si c'est _vraiment_ nécessaire)

Laurent Denis, le 13 juin 2004

lol ! J'avais oublié cette aberration : IE est le seul à supporter ruby, mais ne supporte pas le type mime correct qui doit être employé lorsque celui-ci est exploité... C'est indiscutablement un bonne raison de faire avec text/html. Toutes mes excuses, glandium smiley clin d'oeil

Laurent Denis, le 06 juillet 2004

Pour mémoire : Voir golem.ph.utexas.edu/~dist... pour le recours à XHTML1.1 justifié par le besoin d'y embarquer du MathML.

Laurent Denis, le 24 juillet 2004

Pour mémoire encore : les fonts pour lire le MathML sont détaillées par http://linuxfr.org/~jikao/14681.html

Les commentaires pour ce billet sont temporairement fermés en raison d'une série d'attaques de spam.