De l'utilité actuelle de XHTML

On nous dit souvent qu'aujourd'hui XHTML ne sert à rien, puisque le navigateur le plus utilisé ne supporte pas le type MIME "application/xhtml+xml".

Je trouve que c'est une vision très réductrice : pourquoi limiter l'intérêt d'XHTML à son traitement par le client ?

Un bon système de script serveurs permet en général de traiter tout un tas de fichiers XML, de les parser, de les construire grace à une API qu'on lie trop souvent à Java/ECMAScript : DOM. DOM est supporté par ASP.Net, Java, PHP (dans une moindre mesure), et j'en oublie certainement.

Par exemple, on trouve actuellement tout un tas de systèmes de templates plus ou moins artisanaux pour des générateurs de contenus, des blogs, des forums, etc. utilisant des caractères du style "{}" ou "[]" pour insérer du code et du contenu (X)HTML dans un fichier avant son envoi sur le client. Ça revient à recréer un système de balisage propriétaire, alors qu'il suffirait d'utiliser le DOM et un espace de nom créé pour l'occasion pour faire la même chose sans avoir à réécrire un analyseur de fichier, et avec la quasi certitude, si c'est bien fait, de générer des fichiers bien formés, voire valides, quitte à les envoyer par la suite comme "text/html" si le client est allergique à "applicaton/xhtml+xml".

Voilà, c'était mon humeur du jour.

Slt,

Lanza a écrit :
construire [...] DOM

brillante idée

Lanza a écrit :
Par exemple, on trouve actuellement tout un tas de systèmes de templates plus ou moins artisanaux pour des générateurs de contenus, des blogs, des forums, etc. utilisant des caractères du style "{}" ou "[]" pour insérer du code et du contenu (X)HTML dans un fichier avant son envoi sur le client. Ça revient à recréer un système de balisage propriétaire, alors qu'il suffirait d'utiliser le DOM et un espace de nom créé pour l'occasion pour faire la même chose sans avoir à réécrire un analyseur de fichier, et avec la quasi certitude, si c'est bien fait, de générer des fichiers bien formés, voire valides, quitte à les envoyer par la suite comme "text/html" si le client est allergique à "applicaton/xhtml+xml".

Le plus simple reste de ne pas réinventé la roue, et donc de permettre l'utilisation de Xhtml. Pour la validation, il suffit d'un schéma XML, d'une validation côté serveur et le tour est joué.

Cya