W3C ne renouvelle pas XHTML 2

[jcaron]

C'est clair. Je crois que beaucoup n'ont pas compris qu'à part Firefox, aucun navigateur (aucune version de IE, aucune version d'Opera, probablement aucune version de Safari ou Chrome?) ne supporte le XHTML en tant que tel (ils se disent juste que c'est du HTML un peu bizarre), et qu'au moins 90% (si ce n'est 99%) des pages en XHTML sont servies comme du HTML (avec un Content-Type: text/html), et donc interprétées comme du HTML par tous les navigateurs.

Bref, une immense majorité de pages soi-disant en XHTML sont interprétées comme du HTML (mal formé, avec tous ces <.../>), pas comme du HTML. Et comme je le disais précédemment, si elles étaient interprétées comme du XHTML, un bon paquet ne s'afficheraient même pas, le "vrai" XHTML étant beaucoup plus strict que le HTML, un document incorrectement formaté (avec les tags non fermés, ou pas dans le bon ordre par exemple, ou avec des "&" là où il devrait y avoir des "&amp;") devant normalement être rejetée complètement au lieu d'être interprétée comme de la "tag soup".

Le XHTML n'a jamais percé, n'a aucun intérêt pratique (en théorie c'est beaucoup mieux, mais en pratique vu que personne ne le supporte réellement, c'est juste du HTML, donc retour à la case départ). Merci, au revoir, passons à autre chose.

Jacques.

[Moof]

Le boulet arrive :
C'est quoi la différence entre xhtml et html ?
Le boulet repart.

[Leonick]

C'est clair. Je crois que beaucoup n'ont pas compris qu'à part Firefox, aucun navigateur (aucune version de IE, aucune version d'Opera, probablement aucune version de Safari ou Chrome?) ne supporte le XHTML en tant que tel

sûrement parce qu'ils ne font, eux même, que de la soupe de tags

[jcaron]

C'est quoi la différence entre xhtml et html ?

En gros, HTML est basé sur SGML, et utilise des balises genre <balise attribut=valeur...> et </balise>. Certaines balises sont "auto-fermantes" (par exemple <img> n'a pas besoin de </img>), il y a des balises implicites, etc. Et surtout, comme beaucoup de gens écrivent du HTML n'importe comment, la plupart des navigateurs et parsers HTML interprètent tout ça de façon très libérale (la "tag soup"), sinon ils n'afficheraient jamais rien.

XHTML est basé sur XML, qui est beaucoup plus "cohérent": une balise qui est ouverte doit être fermée (en ordre inverse, ou au sein de la même balise <balise .../>). Un document XHTML n'est valide que si le XML est valide, ce qui est nettement plus contraignant pour la plupart des gens qui écrivent du HTML (surtout ceux qui l'écrivent en php...). En gros, si un document XHTML ne passe pas le validateur W3C, il n'est pas censé être affiché.

Le fait d'avoir un vrai document XHTML a aussi des conséquences indirectes: on ne peut par exemple pas utiliser document.write("du HTML"), il faut utiliser DOM (document.getElementById(...).appendChild(createNode(...)) par exemple).

En pratique, 99% des documents soi-disant en XHTML (avec des balises <.../>, un doctype XHTML, et une balise <?xml...> au début) sont servis comme du HTML (avec un Content-Type: text/html), et interprétés comme du HTML, donc ça n'a aucune espèce d'importance, c'est juste du HTML mal formaté (<.../> n'est normalement pas accepté en HTML, mais visiblement c'est toléré...). Heureusement pour eux, parce que s'ils étaient interprétés comme du "vrai" XHTML, ils ne passeraient pas.

Personnellement, je suis tout pour le principe du XHTML, mais il y a tellement de gens que ça ferait tellement ch..r que ce n'est pas réaliste, et comme ce n'est de toutes façons pas réellement supporté, bof bof... D'ailleurs je continue encore et toujours à ne faire que du HTML 4.01...

Jacques.

[Moof]

Merci pour l'explication !!
Je viens de prendre conscience que je fais de la soupe, moi qui me croyait à la pointe avec mes "<br />"

Le fait d'avoir un vrai document XHTML a aussi des conséquences indirectes: on ne peut par exemple pas utiliser document.write("du HTML"), il faut utiliser DOM (document.getElementById(...).appendChild(createNode(...)) par exemple).

Pourquoi ?

[jcaron]

Parce qu'avec document.write tu peux lui donner de la "tag soup" (du HTML plus ou moins bien formé), alors qu'avec des appels DOM tu es sûr de ne pas casser la structure du document. En tous cas si tu fais un document XHTML, que tu le sers comme du XHTML, et que tu le lis avec un browser compatible (Firefox), document.write ne fonctionne pas, même si tu lui balances le plus beau des XHTML.

Il y a aussi le fait qu'en HTML le document est interprété "au fil de l'eau", donc document.write a un sens (on écrit là où on est) alors qu'en XHTML le browser commence par interpréter la structure XML complète (pour construire l'arbre correspondant) avant d'interpréter ce qu'il y a dedans. Donc document.write n'aurait pas beaucoup de sens, ce serait à la fin, après le tag final </html>, donc nulle part.

Jacques.

[forummp3]

Cette "norme", c'est vraiment pas gagné...

salut, c'est pas une normes, c'est des recommandations.
T'es libre de faire du html pourri si ca t'enchente
De toute façon, le but, c'est que ca apparaissent partout pareil sur les navigateurs et que ca facilite le developpement (css, etc) et accesoirement rajouter de nouvelles options de graphisme.

[Bellegarde-webb]

Tout le monde est libre d'écrire de la soupe, mais laissons ceux qui ont une éthique d'écriture l'avoir : ils sont peu nombreux !

[Audiofeeline]

T'es libre de faire du html pourri si ca t'enchente

Rien à voir, je parlais de la vidéo.

[Pandore]

oui mais sans XHTML 2 il n'y aura pas de XHTML 3, c'est quand meme un abandon.

Non, ça n'a rien à voir. Comme je le disais, d'après ce que j'ai pu en lire, l'abandon de xHTML2 est du au fait que ce dernier casse la compatibilité avec les contenus HTML4 en bonne partie. Le W3C a voulu se lancer dans une piste et ça n'a pas fonctionné comme il le voulait, c'est tout. Et de toute façon, qui dit HTML5 dit aussi sa déclinaison en XML, que l'on pourrait appeler xHTML5. Il n'y a donc pas d'abandon de la voie xHTML.

Cet abandon montre qu'il faut avancer vers un langage plus puissant (html5) en levant certaine barrierre trop restrictive.

Certaines barrières trop restrictives ? Il n'y a pas tant de différences que ça entre HTML4 et sa déclinaison XML, xHTML1 :
* Toute balise ouverte doit être fermée
* Toutes les balises doivent être correctement imbriquées
* Tout doit être écrit en minuscules, balises et attributs
* Toutes les valeurs des attributs doivent être entre ' ou "
* Tous les attributs doivent avoir une valeur
C'est tout ! Tu trouves que ce sont des barrières trop restrictives ?! C'est plus des habitudes de codage à prendre qu'autre chose.

[KOogar]

techniquement tu as Entierement raison, mais c'est le fond du problème que je commente. Dans cette discussion nous rentrons dans les détails mais en surface ? va voir un peut sur d'autres forums, le "ton" y est taquin et on y vois un abandon. Cela a fait du bruit; le lendemain de cette annonce il y a avait deja php Classes qui sortait un article de plusieurs pages sur le HTML5 http://www.phpclasses.org/blog/post/98-HTML-5-for-a-better-Web.html , je ne suis pas toute l'actualité mais ce genre de revirement a du alimenter bien des discussions

[Pandore]

techniquement tu as Entierement raison, mais c'est le fond du problème que je commente. Dans cette discussion nous rentrons dans les détails mais en surface ?

Je préfère regarder en détails plutôt que en surface. Ce que je vois c'est que oui, le projet xHTML2 est abandonné en tant que tel. Mais des idées développées pour xHTML2 on été reprises dans HTML5. Donc pas abandon total pour moi. Ce que je vois aussi c'est que le xHTML n'est pas prêt d'être abandonné.

a voir un peut sur d'autres forums, le "ton" y est taquin et on y vois un abandon. Cela a fait du bruit; le lendemain de cette annonce il y a avait deja php Classes qui sortait un article de plusieurs pages sur le HTML5 http://www.phpclasses.org/blog/post/98-HTML-5-for-a-better-Web.html , je ne suis pas toute l'actualité mais ce genre de revirement a du alimenter bien des discussions

Alors après les effets de manches ... J'ai même vu sur un site un article dont le titre très accrocheur annonçait carrément la mort de xHTML au profit de HTML, l'auteur se rattrapant après en disant que c'était faux. C'est pas très malin mais effet buzz garanti. Certains doivent se marrer de voir le W3C se tromper de voie et de devoir abandonner un projet de cette envergure. Si ça fait couler de l'encre et parler les langues, pourquoi pas.

Le plus important est que le Web évolue dans le bon sens. Il y a plein de trucs intéressants avec HTML5/xHTML5. Reste à voir si les navigateurs vont suivre, en particuliers un dont je tairai le nom mais que tout le monde connait pour sa médiocrité à respecter les normes.

[darkjukka]

combien de sites xhtml valident réellement ?
combien de sites xhtml valident réellement en mode strict ?
et combien le font avec le header "Content-Type: application/xhtml+xml;", parce que, renvoyer du xhtml strict en text/html; on ne peut pas vraiment appeler cela du xhtml strict

Présent

Cela dit je trouve quand même abusé que le validateur W3C ne soit pas capable d'encaisser ce type MIME justement, comment il peut valider du XHTML Strict s'il n'accepte pas le MIME correspondant ?

[Leonick]

Cela dit je trouve quand même abusé que le validateur W3C ne soit pas capable d'encaisser ce type MIME justement, comment il peut valider du XHTML Strict s'il n'accepte pas le MIME correspondant ?

si, il n'a aucun problème avec du xhtml strict renvoyé en application/xhtml+xml, je viens de revérifier
Le fait qu'il affiche text/html vient de ton serveur

[darkjukka]

En fait j'envoie du XHTML 1.1 quand le navigateur supporte le application/xhtml+xml et du XHTML 1.0 Strict quand il ne le supporte pas et pour le validateur c'est du 1.0 qui ressort en détection automatique, c'est pour ça que je m'interroge.