XHTML-compatibilité des navigateurs

[kot]

Bonjour,

Je suis l'auteur d'un site de vente en ligne. J'ai développé mon site entièrement en HTML 4.01 et j'ai tenté de respecter la norme W3C à l'aide de son validator.

Maintenant, je me pose la question de savoir si je dois transférer mon site en XHTML

ET SURTOUT, ma question est vais-je perdre des chalands potentiels si je fais du XHTML, d'après vous y-a-t-il beaucoup de navigateurs qui ne supportent pas XHTML.

Je me place dans le contexte où les personnes venant voir mon site sont des informaticiens du dimanche et que leur navigateur n'est pas forcément à jour.

Alors,

d'après vous?

Modifié 28 Septembre 2005 par kot

[Xavier]

Il n'y a aucune raison de faire du XML. Et en tous cas pas juste pour "être à la mode"

Le XML c'est symplement une syntaxe. Elle est à la base de nombreuses syntaxes (SVG, XForms, RDF et bien sur XHTML) mais en soi elle ne veut rien dire. Fais un site en XML, tu aura quelque chose qui ne veut rien dire et que les navigateurs ne pourront pas interpréter (vu que ça ne veut rien dire).

Bien sur tu peux te créer ton propre langage XML, qui lui aurait un sens. Mais de là à ce que les navigateurs le comprennent, je crois que tu peux dormir tranquille

Bref, reste en HTML, c'est le plus adapté à l'heure actuelle. Le Xhtml est encore trop mal supporté.

Si vraiment tu veux te mettre au XML pour faire hype, utilise-le comme base de données (c'est à ça qu'il sert en fait, décrire des données).

[kot]

Euh, désolé je parlais de x(ht)ml! bien sûr (j'ai corrigé)

Ta réponse est donc : mal supporté

Modifié 28 Septembre 2005 par kot

[Xavier]

Oui, à vrai dire il n'y a à ma connaissance guère que Gecko (Mozilla, Firefox et cie), KHTML (Konqueror et Safari) et Presto (Opera) qui le supportent, et probablement quelques autres browsers exotiques.

IE ne connait pas (et demande de télécharger), et de nombreux autres navigateurs non plus (vieux ou pas). Bref, le HTML c'est très bien. Strict bien évidemment (c'est-à-dire avec séparation contenu/mise en forme).

[petit-ourson]

Je pensais qu'il parlait de XML + XSL avec une sortie en HTML ou XHTML ... J'ai bien fait de ne pas répondre trop vite lol

[MarvinLeRouge]

Oui, à vrai dire il n'y a à ma connaissance guère que Gecko (Mozilla, Firefox et cie), KHTML (Konqueror et Safari) et Presto (Opera) qui le supportent, et probablement quelques autres browsers exotiques.

IE ne connait pas (et demande de télécharger), et de nombreux autres navigateurs non plus (vieux ou pas). Bref, le HTML c'est très bien. Strict bien évidemment (c'est-à-dire avec séparation contenu/mise en forme).

<{POST_SNAPBACK}>

Faudrait éviter de dire des bêtises : tous les navigateurs supportent le xhtml, pour la bonne et simple raison que, tant qu'on le sert en tant que tel, c'est du html.

Xhtml est simplement une évolution de html, un moyen de le tirer progressivement vers xml.

Et IE comprend très bien xhtml. Il y a certains défauts certes, mais rien à voir avec "une demande de téléchargement".

Principaux problèmes connus avec le xhtml :

1) Le xhtml avec prologue xml (qui est optionnel dans la plupart des cas, quand on le sert en html) fait passer IE en mode "Quirks". Mais, comme je l'ai indiqué, le prologue xml est optionnel dans la plupart des cas (cf le très bon article de blog and blues sur le sujet)

2) Le xhtml 1.1, lui pose vraiment problème, car il doit OBLIGATOIREMENT être servi sous un type mime qui est pour l'instant très mal pris en compte par les navigateurs.

Si ton but est de te forcer à avoir un code propre, pur et évolutif, du html 4.01 strict est équivalent à du xhtml 1.0 strict.

Et effectivement, il ne faut pas choisir un doctype parce que c'est "in", mais parce que c'est ce qui correspond à ton besoin : ne pas suivre l'exemple, donc, de ceux qui mettent du xhtml 1.1 pour le principe de mettre la dernière mouture, et qui le servent comme du "text/html".

Je te conseille les articles de Openweb et de blog & blues sur ce sujet.

[Dudu]

Faudrait éviter de dire des bêtises :

Oui comme tu dis par ce que t'en sors des pas mal aussi

Suivez le guide.

tous les navigateurs supportent le xhtml, pour la bonne et simple raison que, tant qu'on le sert en tant que tel, c'est du html.

Dans ce cas tu ne fais pas du XHTML, tu travailles avec une syntaxe XHTML. D'une.

De deux, l'équipe de développement d'Internet Explorer 7 pour Windows a déclaré "nous ne supporterons pas l'XHTML" donc si on suit ton raisonnement ils disent des bêtises c'est çà ? C'est vrai qu'ils ne sont absolument pas concernés par les supports de langages web dans des navigateurs: c'est juste leur boulot (mais à part çà c'est pas grave)

De trois, servir n'importe quoi en type MIME text/html c'est faire appel au support HTML point barre. Que le "n'importe quoi" en question soit de l'XHTML ou non.

Et IE comprend très bien xhtml.

NON. C'est faux, archi-faux.

1) Le xhtml avec prologue xml (qui est optionnel dans la plupart des cas, quand on le sert en html) fait passer IE en mode "Quirks". Mais, comme je l'ai indiqué, le prologue xml est optionnel dans la plupart des cas (cf le très bon article de blog and blues sur le sujet)

C'est pas une question ni de prologue, ni d'XML, ni d'XHTML.

IE passe en mode quirks si la première ligne de code n'est pas un doctype valide.

Rajoutes une ligne blanche avant un doctype et IE passe en quirks direct. Tu peux aussi rajouter "ouahdkfkj" c'est la même chose.

Faudrait voir à éviter de tout confondre

Et je t'assure qu'IE Win fait une demande de téléchargement quand il tombe sur une page envoyée en application/xhtml+xml Pour t'en convaincre clique sur ce lien avec IE WIn: http://www.mozilla.org/projects/mathml/start.xhtml

***

Maintenant pour répondre à kot l'important est de faire un code valide. Valide ne veut pas dire que le validateur t'a donné 0 faute à ton document, çà veut dire aussi séparation contenu/présentation, çà veut dire aussi sémantique (bon usage des balises, pas de tableaux ou de div à tout-va, etc etc).

En soi, l'HTML brut de pomme n'a rien de déshonorant: Eric Meyer (référence des CSS s'il en est, grand maître à penser du codage backend) a écrit son site perso en HTML4. Raphaël Goetter d'Alsacréations (moins "grand" que Meyer mais plus proche de nous autres français) fait pareil.

Et on peut citer beaucoup d'autres exemples.

Cela étant je préfère conseiller l'XHTML pour des raisons d'évolution: la norme XHTML 2 pointe son nez et je me dis qu'il va déjà être dur de passer d'XHTML 1 à XHTML 2, donc faire le grand saut depuis HTML 4 risque d'être carrément chaud

Puis çà apprend à être strict dans sa syntaxe ce n'est pas plus mal.

Bon courage en tous cas

PS: concernant LE navigateur qui ne sait pas lire l'XHTML il suffit de lui envoyer la page en HTML, et pour tous les autres aucun souci. Il n'est pas dangereux de faire de l'XHTML et il est facile de contourner la non-compatibilté IE Win

[Xavier]

Rhooo, Dudu, qu'est-ce que je réponds moi maintenant ? Tu m'as piqué toute ma réponse.

Bon, il me reste encore une carte, une seule : Sending XHTML as text/html Considered Harmful. Eh oui, faire du XHTML et le traiter en text/html c'est rien d'autre que de proposer un tag-soup plein de /> aux navigateurs, qui ne vont rien faire d'autre que de corriger ça vite fait

Il suffit de réenregistrer une telle page depuis le navigateur pour s'en rendre compte, tous les <br /> sont devenus de <br> prouvant que le navigateur vous a pris pour un gros naze qui ne sait pas coder

Cela étant je préfère conseiller l'XHTML pour des raisons d'évolution: la norme XHTML 2 pointe son nez et je me dis qu'il va déjà être dur de passer d'XHTML 1 à XHTML 2, donc faire le grand saut depuis HTML 4 risque d'être carrément chaud

Puis çà apprend à être strict dans sa syntaxe ce n'est pas plus mal.

Bon courage en tous cas

Sauf que le XHTML 2.0 n'est

1. Pas près de sortir (il est au stade de Working draft, pas de recommandation finale avant de très nombreuses années
   
2. Encore moins près d'être implémenté dans les navigateurs (pour peu je prendrais presque les paris qu'il ne sera pas utilisable avant 10-15 ans).
   

On a donc largement le temps de voir venir.

Par contre ce qui va venir plus vite c'est le HTML 5.0 tel que proposé par le WHATWG, avec ses WebApps, ses WebForms et ses WebControls. C'est un HTML "+".

Pour info le WhatWG regroupe la majorité des fabricants de navigateurs. (en fait probablement tous sauf Microsoft). Le but est de proposer quelque chose d'utilisable, et ce rapidement, sans attendre que le XHTML 2.0, donc d'ici quelques années, et pas décennies. Le dernier document de travail est sorti pas plus tard qu'aujourd'hui. Ça avance donc vite. Je ne sais pas s'ils prévoient une version XHTML, pas sûr du tout.

Donc le XHTML, je ne sais franchement pas trop (à part pour le SVG et MathML...).

[jeanpierre949]

Le codage des <br /> <img /> etc... en <br> , <img> quoi de plus naturel pour les navigateurs qui ne savent pas lire le xhtml ? L'espace avant le / a été prevu pour ca justement .Reste ceux qui sont capables de l'interpreter correctement

[Xavier]

Non, ce n'est pas normal !

En théorie un

<br />

devrait être interprété comme ça :

(saut de ligne)
/>

Eh oui, c'est un "bug" des navigateurs qui permets de faire passer du XHTML comme du HTML. C'est une des raisons de ne pas faire de XHTML envoyé en html indiquées dans l'article que j'avais mentionné : http://hixie.ch/advocacy/xhtml

Mais il y en a de nombreuses autres (commentaires etc.)

Alors baser l'affichage correct de ses pages sur une erreur d'implémentation du SGML par les navigateurs... très peu pour moi

[kot]

Bon,

en gros et si je résume y'a toujours des problèmes avec le xhtml.

C'est juste ce que je voulais savoir !

D'ailleurs je crois que je vais de ce pas enlever mes balises /> à la fin de mes BR et autres input

Maintenant pour répondre à kot l'important est de faire un code valide. Valide ne veut pas dire que le validateur t'a donné 0 faute à ton document, çà veut dire aussi séparation contenu/présentation, çà veut dire aussi sémantique (bon usage des balises, pas de tableaux ou de div à tout-va, etc etc).

ça, ça m'intéresse fort, mais y'a quelqu'un qui pourrait me donner une adresse de site de cette sorte. Car j'ai du mal à voir comment je peux appliquer plusieurs styles différents sans avoir de balises où les appliquer. En gros, j'ai pas mal de div et quelques tableaux et pour l'instant j'avais pas honte!

[jeanpierre949]

Xavier,

Dans l'article que tu nous presentes sur les mefaits de l'utilisation du xhtml, il est precisé que les documents xhtml qui etaient validés par le W3C n'etaient pas concernés par ces problemes

[MarvinLeRouge]

Aaaarrghhh !!!

Je peux même pas répondre à Dudu comme il faut car on ne peut pas imbriquer 3 niveaux de citation.

Crotte zut flute.

Bon ben en gros alors :

1) Le Xhtml, par définition (et ça c'est pas moi qui le dit, c'est le w3c) est une extension et une évolution du html.

2) Le Xhtml, comme le xml, étant un langage de description de structure de document, j'ai du mal à comprendre la différence que tu fais entre "faire du xhtml" et "utiliser une syntaxe xhtml". NB : Je suis parfaitement conscient qu'il y a l'esprit visant à séparer le contenu de sa présentation, pas la peine d'aller sur ce terrain.

3) Depuis quand les équipes de développement d'IE sont-elles considérées comme ne disant pas de bêtises ? Troll mis à part, je pense qu'il est question là (bien que je ne dispose pas du contexte), de xhtml servi en tant que application/xhtml+xml, ce qui est certes souhaitable (si on s'en réfère au sacro-saint tableau à ce sujet sur le site du w3c), mais pas obligatoire : du contenu xhtml peut être servi en tant que text/html, c'est marqué en toutes lettres : MAY. Et il ya aussi SHOULD dans la case application/xml+xhtml, je l'ai lu aussi .

4) "Et IE comprend très bien xhtml" "Non c'est faux, archi-faux". OK, cette fois c'est mon tour (cf la suite) : j'aurais dû préciser "servi en tant que text/html".

5) Pour le prologue : Bah quoi donc c'est pas faux ce que j'ai dit : un prologue xml fait bien passer IE en mode Quirks, puisqu'un prologue xml fait partie de la famille "autre chose qu'un doctype". Ce que tu dis est vrai, mais ça ne contredit en rien mon argument, ça le généralise, c'est tout.

6) "IEWin fait une demande de téléchargement". Alors là c'est pas mon tour, puisque c'est toi même qui rajoute "page envoyée en application/xhtml+xml", précision qui n'était pas dans le post d'origine. Je le re-dis : servir un document xhtml en tant que text/html est possible, ce n'est pas l'idéal (SHOULD), mais c'est possible (MAY).

Bon et maintenant, pour l'entente cordiale :

Sur ce sujet, nous avons été d'accord : l'important est de faire du code propre, évolutif, bien conçu, valide dans le sens respectant la norme que tu as choisi de lui appliquer et pas dans le sens "un robot stupide m'a dit que c'était bon parce que je l'ai complètement grugé".

Et pour ce qui est de la façon de servir le document, si tu peux servir ton xhtml en application/xhtml+xml aux navigateurs qui le comprennent, c'est mieux.

Concernant le WhatWG, j'espère franchement que son existence va permettre de mettre un coup de boost à l'évolution des normes, parce que là, ça fait franchement trop longtemps qu'on patauge à mon goût (d'ailleurs, si ce n'était pas le cas, cette discussion n'aurait pas eu lieu).

[Xavier]

1) Le Xhtml, par définition (et ça c'est pas moi qui le dit, c'est le w3c) est une extension et une évolution du html.

Ben oui, une évolution du HTML, rien ne l'empêche de partir dans une autre direction (en particulier le HTML 5).

2) Le Xhtml, comme le xml, étant un langage de description de structure de document, j'ai du mal à comprendre la différence que tu fais entre "faire du xhtml" et "utiliser une syntaxe xhtml". NB : Je suis parfaitement conscient qu'il y a l'esprit visant à séparer le contenu de sa présentation, pas la peine d'aller sur ce terrain.

Il n'a pas dit ça ! Il a dit

Puis çà apprend à être strict dans sa syntaxe ce n'est pas plus mal.

Strict dans le sens «guillemets obligatoires», «";" à la fin des entités» etc.

Disons que ça "oblige" à une certaine discipline, car c'est tout à fait valable en HTML aussi, et que si ce n'est pas déclaré en XML alors on peut tout aussi bien se laisser aller...

3) Depuis quand les équipes de développement d'IE sont-elles considérées comme ne disant pas de bêtises ? Troll mis à part, je pense qu'il est question là (bien que je ne dispose pas du contexte), de xhtml servi en tant que application/xhtml+xml, ce qui est certes souhaitable (si on s'en réfère au sacro-saint tableau à ce sujet sur le site du w3c), mais pas obligatoire : du contenu xhtml peut être servi en tant que text/html, c'est marqué en toutes lettres : MAY. Et il ya aussi SHOULD dans la case application/xml+xhtml, je l'ai lu aussi  .

Pour autant qu'il respecte les 13 Règles de compatibilités du HTML. Ce qui est loin, très loin d'être le cas de toutes les pages XHTML servies en text/html. Malheureusement.

Parce qu'un xml:lang sur une page text/html, s'il n'y a pas le lang qui va avec... le validateur ne dit rien (d'ailleurs il ne dit rien s'il n'y a pas le lang du tout), mais c'est totalement inutile.

4) "Et IE comprend très bien xhtml" "Non c'est faux, archi-faux". OK, cette fois c'est mon tour (cf la suite) : j'aurais dû préciser "servi en tant que text/html".

Oui mais dans ce cas il le comprend comme du HTML, donc plutôt qu'il "comprend" c'est "il arrive à s'en sortir plus ou moins correctement"

6) "IEWin fait une demande de téléchargement". Alors là c'est pas mon tour, puisque c'est toi même qui rajoute "page envoyée en application/xhtml+xml", précision qui n'était pas dans le post d'origine. Je le re-dis : servir un document xhtml en tant que text/html est possible, ce n'est pas l'idéal (SHOULD), mais c'est possible (MAY).

Bon et maintenant, pour l'entente cordiale :  

Le post d'origine parlait en fait de XML, puis ça a dérivé sur le XHTML. Pour moi du XHTML servi en tant que text/html ce n'est pas vraiment du XHTML, ça n'en a pas les avantages en terme d'évolutivité (SVG, MathML etc.) ou de syntaxe XML (arrêt sur erreurs, commentaires XML, sections CDATA etc.) pour ne citer que ça, et si c'est pour qu'au final le navigateur commence par corriger ce code bourré d'erreurs, bof bof !

Je préfère conseiller de prendre du temps pour séparer le contenu et la mise en page (CSS), c'est bien plus utile, du temps mieux investi à mon avis, et aussi et surtout pour travailler l'accessibilité de son site

[MarvinLeRouge]

2) Xavier tu t'égares (de post ou de ligne) : Dudu a bien dit

Dans ce cas tu ne fais pas du XHTML, tu travailles avec une syntaxe XHTML.

. Il y a égarage de défense votre honneur.

3) C'est bien pour ça que je parlais de "valider intelligemment" (ce ne sont pas mes termes, mais l'esprit y est). Il est très facile de tromper un robot, mais le premier qu'on trompe en faisant ça, c'est soi-même.

6) Ah ben voui bah moi je savais pas m'sieur l'juge : moi y'avait marqué xhtml dans le titre alors j'l'ai cru moi, vous m'comprenez hein ?

Je suis bien d'accord avec ta conclusion : le pourcentage d'internautes ayant un déficit perceptuel (excusez moi si l'expression n'existe pas) ou moteur est à mon humbre avis fortement sous-estimé.

[Dudu]

Faire du xhtml: envoyer ses pages avec le type mime correct

Travailler avec une syntaxe xhtml: envoyer ses pages en html

Et c'est assez simple je pense de n'envoyer le 'mauvais' type mime qu'à WinIE: un petit script php de 3-4 lignes maxi.

PS: Désolé je ne pourrais pas suivre ce sujet beaucoup ces temps-ci: si je ne réponds pas c'est (malheureusement) normal

[TheRec]

Bonsoir,

mouais... tant qu'on ne m'interdit pas d'utiliser quelque chose qui permet une meilleure compatibilité entre les navigateurs sans envoyer un contenu différent en fonction du navigateur je ne me gêne pas pour utilisé cette possibilité... Pour la bonne et simple raison qu'en l'occurence, le type text/html est supporté par TOUS les navigateurs que je connais...

Effectivement il est préférable d'utiliser le type mime le plus approprié en fonction des cas, mais comme tous les cas ne peuvent pas être traîtés on réduit lui choix à quelques navigateurs qu'on connait et pour les autres qui éventullement supporteraient aussi application/xhtml+xml on se contente de les ignorer... dans ce cas autant, tant que le cas contient des exceptions inconnues ne pas traîter les exceptions et se cantonner au cas général qui fonctionne partout...

Mais effectivement si on décide de faire du XHTML 1.1 on se doit d'être honnête et ne jamais servir du text/html, même si cela "fonctionne". Autant ne pas respecter les recommandations W3C si c'est pour les baffouer avant même d'avoir envoyé quelque contenu que ce soit (ben oui c'est dans les HTTP headers...).

Concernant le prologue XML j'applique la même "philosophie" (c'est un grand mot quand même).

[Xavier]

Bonsoir,

mouais... tant qu'on ne m'interdit pas d'utiliser quelque chose qui permet une meilleure compatibilité entre les navigateurs sans envoyer un contenu différent en fonction du navigateur je ne me gêne pas pour utilisé cette possibilité... Pour la bonne et simple raison qu'en l'occurence, le type text/html est supporté par TOUS les navigateurs que je connais...

<{POST_SNAPBACK}>

Ben... dans ce cas je ne vois pas trop d'argument pour ne pas faire de HTML 4.01... j'ai peut-être raté quelque chose mais vu que le XHTML 1.0 (en text/html) n'apporte rien de plus que le HTML 4.01, je peine vraiment à comprendre pourquoi on ne ferait pas tout simplement du HTML, renseigné comme tel...

Pourquoi vouloir essayer de mentir aux navigateurs ? Vu que de toutes façons si on envoie en text/html le XHTML n'a aucun avantage ?

C'est surement une question de goût, pour ma part soit je fais du text/html et j'assume jusqu'au bout en faisant du HTML 4.01, soit alors du application/xhtml+xml obligatoire et là je peux vraiment faire ce que je veux (entités personnalisées, svg, mathml et cie), mais pas question d'envoyer ça en text/html à qui que ce soit.

Mais un XHTML 1.0 bridé par le text/html vraiment je trouve ça démoralisant

[TheRec]

Pourquoi vouloir essayer de mentir aux navigateurs ? Vu que de toutes façons si on envoie en text/html le XHTML n'a aucun avantage ?

<{POST_SNAPBACK}>

Simplement pour une question d'évolutivité du code, je ne pense pas vouloir me repencher sur mon code lorsque je déciderai dans, un futur "proche" (c'est tout à fait relatif à la durée de vie d'une page...), d'envoyer du application/xhtml+xml. Mais mon précédent message expliquait simplement qu'envoyer selectivement du application/xhtml+xml (en fonction du User Agent) n'est pas à mon avis aussi honnête que d'envoyer en text/html tant que le contexte actuel l'impose (beaucoup d'UA qui ne prennent pas en charge ou mal leapplication/xhtml+xml). Ce problème est évoqué ici : No to XHTML - Spartanicus' Web tips

C'est surement une question de goût, pour ma part soit je fais du text/html et j'assume jusqu'au bout en faisant du HTML 4.01, soit alors du application/xhtml+xml obligatoire et là je peux vraiment faire ce que je veux (entités personnalisées, svg, mathml et cie), mais pas question d'envoyer ça en text/html à qui que ce soit.

Mais un XHTML 1.0 bridé par le text/html vraiment je trouve ça démoralisant

<{POST_SNAPBACK}>

Comme tu le dis, c'est du XHTML "bridé"... libre à toi de le débridé quand bon te sembleras (voir ci-dessus pour savoir comment), si possible on ne démolissant pas l'accessibilité à tes pages ... mais à mon avis vu la diversité des UA c'est quasiment inimaginable.

Finalement, tu as certainement raison, pourquoi s'échiner à voir trop loin. Surtout quand on lit ce genre de document : Servir du XHTML en tant que text/html jugé néfaste

Ce n'est pas la première discussion sur ce sujet que je suis de près et je commence à me convaincre qu'utiliser HTML 4.01 Strict est la solution qui pose le moins de problème lors du développement.

[Xavier]

.

Ce problème est évoqué ici : No to XHTML - Spartanicus' Web tips

Je ne connaissais pas ce document. Il rejoins bien ce que je dis (enfin... il m'arrive de passer outre les "problems caused by serving XHTML as application/xhtml+xml" . Et puis sur le "users shouldn't be bothered with useless information about the site's mechanics onto the main content pages" je ne suis pas d'accord du tout. )

Servir du XHTML en tant que text/html jugé néfaste

<{POST_SNAPBACK}>

OOooh ! Je n'avais pas vu qu'il y avait une traduction française Elle est toute neuve.

J'aime bien cet article parce que je suis effectivement passé par les points 1 à 5, donc je m'y reconnais assez bien (pas dans le point 6, et je ne l'ai pas évité comme le pense l'auteur parce que j'étais un "utilisateur avancé", plutôt parce que je n'ai simplement pas fait le lien entre XHTMl et les problèmes rencontrés - en l'occurence c'était les marges sur le <html> )

Merci pour tous ces liens !

Modifié 1 Octobre 2005 par Xavier

[jeanpierre949]

Mais pourquoi tout melanger?

html=application sgml.

xhtml=application xml .

Libre a chacun de choisir entre sgml ou xml .

Lequel des 2 est evolutif en vue lecture PDA, WAP etc.. ?

[TheRec]

Mais pourquoi tout melanger?

html=application sgml.

xhtml=application xml .

Libre a chacun de choisir entre sgml ou xml .

Lequel des 2 est evolutif en vue lecture PDA, WAP etc.. ?

<{POST_SNAPBACK}>

Oui dans le best-case senario c'est juste... mais maintenant la discussion portait sur le fait de servir du XHTML 1.0 en tant que text/html (qui n'est pas interdit dans les recommandations du W3C) et la ça revient à dire : xhtml = soupe de balises ...en schématisant beaucoup... (Servir du XHTML en tant que text/html jugé néfaste)...

Le plus évolutif entre HTML et XHTML est clairement le second, de par sa syntaxe (orientée XML) et par le fait que la majorités des "nouvelles" technologie tel MathML, etc. se basent sur celle-ci.