Un p'tit bout de bon sens à propos de XHTML 2.0, qui avait échauffé les esprits recemment pour son absence de compatibilité avec XHTML 1.0. Drew McLellan (oui, celui qui écrit sur CSS et DreamWeaver) nous explique pourquoi il ne faut pas s'affoler à cause de cela. XHTML 2.0, est après tout du XML. Donc il est possible de le retravailler programmatiquement avec XSLT pour générer du XHTML 1.0, qui lui sera compris par tous les navigateurs. Pour cela, il faudra une feuille de style XSLT, me direz-vous. Certes. Mais elle sera générique et de toute évidence disponible gratuitement. Autrement dit, il suffira de coder le contenu en XHTML 2.0 valide pour pouvoir servir tous types de clients. Ceux acceptant XHTML 2.0 auront le contenu original, les plus anciens se verront servir du contenu XHTML 1.0, compatible HTML 4.01. Des questions dans la salle ? Si oui, lisez-donc XHTML 2.0 again !
Le livre surveillance://
Je suis l'auteur du livre surveillance://, Les libertés au défi du numérique : comprendre et agir.
Nous générons chaque jour plus de données qui sont captées par des multinationales et des États, et cela peut se retourner contre nous. Comment est-ce possible ? Comment éviter cela ? Ce sont les questions auxquelles je réponds dans ce livre, qu'on peut se procurer chez C & F Éditions.
Ce site, qui porte principalement sur les standards du Web, les navigateurs et la technologie, est maintenu par Tristan Nitot.
Les opinions exprimées sur ce site sont uniquement celles de son auteur et ne sauraient être attribuées à quelconque organisation à laquelle il pourrait être affilié.
Ce site fonctionne avec des logiciels libres tels que Debian GNU/Linux, Apache, MySQL, PHP et DotClear.
6 réactions
1 De gizmo - 18/09/2003, 18:06
Et quid des browsers qui refusent d'utiliser le XSLT parce qu'il nuit au principe d'universalité du HTML/XML?
2 De Dam_ned - 18/09/2003, 20:41
je ne comprend pas ta question.
3 De gizmo - 19/09/2003, 00:07
C'est simple, Tristan se veut rassurant vis-à-vis de la non-compatibilité entre XHTML 1.1 et XHTML 2.0 gràce à un stratagème consitant en l'utilisation d'une feuille XSLT. Or justement, ces feuilles sont décriés par certains "puristes" (que ce terme fait péjoratif) car elles permettent justement de casser toute la sémantique et la syntaxe d'un document. De plus, les navigateurs actuels ne supportent pas ou pas complètement ce format, or c'est justement pour ces navigateurs que le problème va se poser. D'où ma question quand au bien fondé d'une telle *solution*.
4 De Benoit - 19/09/2003, 00:41
Je pense qu'il voulait parler d'une transformation XSLT du côté *serveur*.
5 De gizmo - 19/09/2003, 09:55
ce qui implique une possibilité de scripting, qui est loin d'être universelle. Le but du HTML, c'est justement d'être un balisage universel pour le web. Nombre d'hébergeurs gratuits ne proposent pas de scripting, et un nombre encore plus grand de personnes ne connaissent rien au scripting (déjà que pour le html, c'est loin d'être top...).
Il est beaucoup plus facile de modifier un petit site statique d'amateur qu'un site professionnel qui travaille sans doute avec des applications internes qui lui renvoient peut-être des données DEJA formatées (c'est con, mais ca existe), c'est par la base, qui bosse à l'oeil, que nous aurons, je pense, le plus de facilité à faire changer les choses.
6 De Eric Daspet - 21/09/2003, 13:33
Je trouve Gizmo que tu crée des problèmes là où il n'y en a pas :
- Le support des navigateurs n'est pas parfait mais il existe, c'est supporté pleinement par Gecko et MSIE/win. Il manque encore Opera mais ça viendra probablement.
- Les hébergements ne proposent pas tous du scripting ? c'est vrai, mais ça l'est de moins en moins. Il faut maintenant chercher pour avoir un hébergement sans scripts.
Que celà ne tienne, si tu as un site statique il n'est pas complexe d'éditer du xhtml2 et de faire les transformations XSLT avant envoi sur le serveur.
C'est déjà ce que font plus ou moins la plupart des gens avec des templates dreamweaver, des éditeurs qui font des conversions avant publication, etc. Pour peu que ça finisse par être intégré dans les outils on ne verra pas la difféence.