Laisser tomber le XHTML ?

Pour ma part, je développe encore la plupart du temps en HTML4.01 strict. Tu as raison de signaler que cela ne change rien en terme de rigueur de code. Dans le cas du XHTML, elle est imposée de l'extérieur, alors que dans le cas de HTML, nous nous l'imposons à nous-même.

Je ne passe en XHTML que lorsque je pressens que la page (faisant partie d'un corpus plus vaste et de structure homogène) sera susceptible de modifications. Dans ce cas, un coup de moulinette XSLT me permet d'appliquer ces modifications en masse.

Oui, mais il faut savoir que le XHTML avance réellement dans le domaine de l'interaction et de l'automatisation des tâches, car on peut parser du XHTML beaucoup plus facilement qu'avec du HTML.

Ca reste une innovation technologique, et si tu refuses d'en profiter sous prétexte qu'une sous-merde qui n'est rien d'autre qu'une imposture de navigateur ne le gère pas, c'est de la régression.

Merci de ne pas verser dans le troll inutile.

Dire que IE est obsolète est vrai, par contre dire qu'il est mauvais et tout aussi vrai que de dire que Firefox ou Opera sont mauvais (la liste des bugs de Mozilla - Bugzilla - est d'ailleurs impressionnante).

Je ne suis pas d'accord avec toi e-t172, utiliser xhtml pour faire du HTML, c'est là qu'est l'imposture à mon sens ;)

Le xhtml n'a d'utilité que pour utiliser SVG, MathML et autres dérivés d'XML à insérer sur une page web.

Par ailleurs, il faut prendre en compte la retro compatibilité, il n'y a pas qu'IE qui ne gère pas le bon type MIME, les moins récents des mozilla ou autre opera ne le gèrent pas non plus.
Pour la réelle transition, attendons xhtml2.0 qui sera du vrai xhtml cette fois ci.

Woupss piti oubli :
A noter que Meyer Web est en HTML4.01 en effet, et même HTML4.01 transitionnel :D

Mais là utiliser le Strict serait plus justifier au niveau séparation contenu/mise en forme ;)

Le transitionnel interdit la séparation contenu / forme ? :)

Pourquoi ne pas faire du XHTML 1.0 Trans ? Ca permet d'avoir une certaine rigueur (qui permet de se poser de bonnes questions quand on débute) tout en ne sombrant pas dans le fanatisme.

Sur un projet commencé il y a plus d'un an, je me suis posé la question HTML 4.01 ou XHTML et si XHTML, quel DTD ?

Sachant que le projet allait durer un certain temps, j'ai fait le choix de l'entre deux soit XHTML 1.0 strict.

Pourquoi ce choix ?
- C'est exactement HTML 4.01 sauf qu'il a une notation XML
- Coté back-office, il est plus simple de jouer avec un langage XML qu'avec un SGML (notamment si on a des applicatifs DOM2).
- Si besoin de "jouer" avec les rendus clients, c'est plus simple

Certes le mime renvoyé est et restera un moment en text/html mais le jour ou ce sera généralisé ça se passera sans problèmes.

L'avantage que je vois dans XHTML c'est la possibilité dans l'avenir (ou même maintenant)d'interagir avec ses pages web avec autre chose qu'un navigateur web classique en utilisant XML. Par exemple, j'ais rendu un Flash dynamique en important dedans les données d'un fichier XHTML,et ces données étaient lues grâce à l'objet XML d'actionnscript. Cela me permet maintenant de traduire tout mon contenu avec Systran qui ne sait pas lire le XML, mais qui maîtrise bien le HTML.

Vous me parlez tous d'avenir, de DOM2, de XML+Actionscript, etc.

Mais ce ne sont que des applications que je n'utilise pas.
Comme le dit Olivier, lorsque j'aurai besoin de ces applications, et d'utiliser SVG, MathML et autres dérivés d'XML... alors il sera logique d'employer un langage déclaré en XHTML/XML... mais en attendant...

@Raphaël, concernant Strict/Trans, là il y a un réel interet, c'est pas juste pisser dans un violon, les DTD strictes impliquent la séparation contenu/présentation du fait de la non validation des principaux attributs de mise en forme. Par ailleurs, on peut très bien utiliser le HTML 4.01 transitionnel de façon stricte ;) Mais j'entend par là que HTML4.01 Strict me semble plus légitime que HTML4.01 Trans pour les mises en pages que nous réalisons en général.

La question est différente en ce qui concerne xHTML "contre" HTML, en effet, il est tout de suite moins légitime d'utiliser xHTML que HTML pour simplement faire du HTML :)

Sinon, aux XML users, evidement, xHTML1 n'est pas à jeter, pour les cas de figures que vous exposez (interaction avec l'objet XML d'AS, parsing XML/XSL, ...), là oui l'utilisation d'xHTML est déjà plus utile et prend son sens :D
Mais pour faire la page web de papa ou tout autre site n'utilisant pas XML, aucun interet à mon sens.

Rokad souligne un point qui mérite qu'on s'y arrete. Peut être qu'xHTML en tant qu'outil pédagogique pourrait être interessant, mais lié à la validation (validateur w3c/validome/etc) et pas utilisé seul.

Plus de <p> sans son </p> (autorisé en HTML4.01), et autres points peut être utile pour bien cadrer le débutant ou le moins initié.
Mais à partir du moment où le langage est connu, là zou on retourne au HTML :)
Mais bon... c'est un peu paradoxal comme façon de faire ^^

De toute façon quand on vois le carnage syntaxique sur certaines pages xHTML... xHTML ou HTML... bof le carnage est le même !!!

"C'est aujourd'hui que sort la traduction du livre de Jeffrey Zeldman : "Designing With Web Standards"; un livre pour les webmasters intéréssés par les standards de l'Internet et surtout le design." Source : www.whynet.org.

Peut etre que les réponses à tes questions se trouvent dans ce bouquin (que tu dois déjà connaitre...) Ca tombre bien, il sors aujourd'hui :-)

@Rokad > blog.alsacreations.com/20... :)

Oui je sais, c'est là que je l'ai lu en premier en fait grâce ton fil rss :-)

mon navigateur dans mon téléphone portable préfère le xhtml à l'html. voilà une bonne raison de rester en xhtml, sinon je ne pourrai plus consulter ton blog dans le train ;)

@YoGi > je suis ouvert à toute explication, mais en quoi est-ce qu'il "préfèrerait" XHTML à HTML ?

Je ne vois pas en quoi il serait mal d'écrire du XHTML 1.0 servi en text/html. Tu veux écrire en HTML 4.01 Strict ? C'est bien, mais, à mon sens, c'est pas mieux, les deux se valent.
HTML Tidy permet de convertir du HTML en XHTML automagiquement, il n'y a rien de compliqué à passer de l'un à l'autre (surtout quand, comme tu le dis, on est rigoureux). Quand on sert du text/html, pour moi, XHTML, HTML 4.01, c'est kif-kif...

@Raphael > quand des balises sont mal fermées (l'exemple du <p> a été cité plus haut), selon la structure du document, le navigateur de mon téléphone a tendance à s'emmêler (c'est initialement un navigateur xhtml et wap, pas html).

Maintenant je t'accorde que tu peux fermer tes balises même en HTML 4.01.

Moi j'utilise un script PHP de négociation de contenu, donc j'envoi en application/xhtml+xml aux agents utilisateurs qui le gèrent

je suis assez de l'avis de Thomas Linard et je serais curieux qu'on m'explique en quoi cette vision serait erronnée (si tel est le cas)

Salut,

Pour te convaincre de revenir au xhtml :

www.media-box.net/article...

;)

Hé hé, sacré Dom :)
Cet article est un peu vieux. Il souffre de quelques imprécisions du fait de mon manque de connaissances à l'époque.
J'y confondais par exemple XHTML avec standards, CSS et Accessibilité :/

"le site de l'expert mondial en CSS, Eric Meyer, n'est pas en XHTML mais en HTML 4.01."

C'est bien connu: "les cordonniers sont toujours les plus mal chaussés".

Dans un souci de perrénité de l'application!
le xHTML est plus orienté XML, l'avenir étant aussi orienté vers une grammaire du type XML, il va de soi que le xHTML garanti une meilleure maintenabilité du code, et même peut être un meilleur rendu dans les futures évolutions des différents navigateurs.

Je partage aussi l'avis de Thomas :-)

Thomas > Quand on sert du text/html, pour moi, XHTML, HTML 4.01, c'est kif-kif...


Le problème, c'est qu'xHTML ne devrait pas être servi en tant que tel ;) C'est donc un juste retour des choses que de faire du HTML avec le doctype HTML. C'est justement là que toute la nuance se situe et ce que Raphaël et moi précisons.

OK, OK. Par contre, il faudrait faire attention car après avoir proné l'utilisation du XHTML et disant qu'il fallait être stric (oui, je parle de toi Olivier) vous arrivez tout tranquilles en disant que finalement on utilise mal le XHTML et qu'il vaut mieux faire du HTML. Les gens risquent de ne plus vous croire quand vous dites quelque chose...

@Rokad :
Je pense que le message que voulait faire passer Oliver, c'est que si tu fais du HTML 4.01 *strict* tu es "plus propre" et "plus honnete" (envers le navigateur) que si tu faisais du XHTML strict.

J'inste bien sur le strict, car perso, je pense qu'il vaut mieux n'importe quel HTML en mode strict qu'un XHTML transitional.

@rokad, je peux comprendre en effet, mais je ne suis pas l'évangile :D
Par ailleurs, tout ceci vient après une réflexion de longue haleine, c'est une remise en question.

Et je continu de dire (voir commentaire id#2318) que pour un apprentissage, l'xHTML Strict n'est peut être pas un mal, un rôle de structuration assez efficace une rigueur de code encadrante. C'est assez bénéfique. Mais ce qu'il faut voir derrière, c'est le choix d'un doctype adapté à nos besoins, et là ça a toujours été le cas (même si j'ai toujours proné le xhtml stric jusqu'ici) il a toujours été question de choisir un doctype adapté à ses besoins. Certe il etait plus question de transitionnel pour l'utilisation des target que de réflexion sur l'enjeu réel :s

Ensuite, c'est un choix de chacun que d'utiliser xHTML ou HTML, perso je pense que dans la plupart des cas, HTML est suffisant (c'est comme UTF/ISO tiens ^^, pourquoi utiliser UTF si on est certain d'utiliser uniquement des caractères latin :s) et il n'y a pas lieu d'utiliser xHTML. Par contre, xHTML prend tout son sens lorsque l'on souhaite interagir avec des langages plus ciblés XML. Mais là, je préfère attendre xHTML2.0 pour 2 raisons principales :
- à la sortie d'xHTML2.0 les navigateurs seront plus avancés, l'utilisation d'un vrai xHTML sera donc plus envisageable (c'est à espérer)
- la norme sera bien plus claire et efficace que pour xHTML1.1 ou xHTML1.0

En fait, je dicerne mal l'interet de xHTML1.0 :s vu que xHTML1.1 parait tout aussi adapté à l'utilisation de langages dérivés d'XML.

Faudrait vraiment faire un tour dans la doc, mais bien profond et bien comprendre l'interet d'xHTML1.0, le seul qui transparait ici, c'est faire du HTML avec la rigueur d'XML... mwé boff moyen comme interet :D
Même s'il est tout à fait possible d'utiliser des dérivés d'XML avec xHTML1.0 mais en fait, où est alors la différence avec xHTML1.1 (à part ruby peut être).

Donc, xHTML1.0 pour faire du HTML qui ressemble à du XML (waaaoohouuu) ou bien xHTML1.0 pour utiliser des langages dérivés d'XML dans une page web... roooh mais on dirait bien xHTML1.1 ça !!

J'ai vraiment l'impression de plus rien comprendre à tout ce binz. Je doute en tout cas de plus en plus de **l'utilité** d'xHTML1.0 (et surtout servi en text/html).

Enfin voilà ^^, c'est compliqué tout ça finalement.

(Raphael a écrit) "Vous me parlez tous d'avenir, de DOM2, de XML+Actionscript, etc.

Mais ce ne sont que des applications que je n'utilise pas."
>> Plus de 640ko de Ram, mais qui aura besoin de tout ça?? ;-)
Quelle est la pérénnité du site ou du projet, quelle est son ampleur, quand la technologie qu'il utilise aura-t'elle disparu(e)?

N'y a-t-il pas comme lors de toute avancée technologique, ses partisans et ses détracteurs ?
Il me semble qu'il est plus progressiste de se dire : on utilise les technologies du moment, quitte à ce que les 0,n % d'utilisateurs de ie 5 sur mac n'aient pas le meme rendu.

Pour ma part, (je sort un peu du sujet) je préfère séparer la forme et le fond et faire un site en div flottants, ca m'amuse plus que de faire un site ac des tableaux compatible netscape 4.

Il faut quand meme le dire, réaliser une mise en page complexe en css et rester compatible PARTOUT est une mission difficile...

C'est vrai qu'il y a eu un amalguame incroyable autour du xhtml...

1) Comment défineriez-vous un site qui n'utilise pas les tableaux pour les mises en page, mais les div, avec le respect de l'accessibilité ? On avait pour habitude de lire "site xhtml strict", par quoi faut-il remplacer cette mention ?

2) A part le doctype (une ligne de code dans le fichier), quelle est la différence entre du html strict et de xhtml strict, si on utilise les div, si on ferme les balises... si on se tient à la rigueur de l'écriture ? Cela ne change pas grand chose finalement, non ?

3) Quelle importance accordez-vous au W3C ? C'est là la plus forte contradiction que vous soulevez dans ce post. Le W3C, oui ou non, recommande-t-il l'utilisation du xhtml1.0, en attendant le 2.0 ? Comment prêcher le suivi de ces recommandations (ses membres sont des développeurs de navigateurs, eux-même se mettent au xhtml (pas crosoft, mais macromedia, sans parler des sites institutionnels comme l'Elysée (xhtml1.0)), si vous ignorer d'un coup la recommandation de l'emploi du xhtml1.0 ? (Je rejoins l'avis de Rokad, là. Je crois que vous vous descriditez sur ce coup là).

J'espère que OpenWeb maintiendra son cap !

Question subsidiaire à Raphaël : ce n'est pas une attaque, loin de là (je te respecte énormément), mais j'espère juste que ce revirement de situation n'est pas lié à ta recherche d'emploi, ce serait vraiment dommage.

Olivier > Le problème, c'est qu'xHTML ne devrait pas être servi en tant que tel


Qui parlait des royalistes plus royalistes que le roi ? ;-) Il n'y a rien de *mal* à servir du XHTML en text/html, sauf que le W3C souhaiterait, dans l'idéal, que les choses ne se passent pas ainsi... Si toi et Raphaël vous voulez faire du HTML 4.01 Strict, très bien, je n'ai rien à redire. Ce qui me semblerait excessif, ce serait de vouloir convertir du XHTML en HTML parce que ce serait *mieux* (bon, je ne pense pas que c'est ce que vous voulez faire, Raphaël parle de commencer un nouveau site).

Olivier > c'est comme UTF/ISO tiens ^^, pourquoi utiliser UTF si on est certain d'utiliser uniquement des caractères latin

Parce qu'on ne peut pas écrire du français orthographiquement correct en ISO 8859-1 ?
Parce qu'on ne peut pas écrire du français typographiquement correct en ISO 8859-1 ?

Dom > Comment défineriez-vous un site qui n'utilise pas les tableaux pour les mises en page, mais les div, avec le respect de l'accessibilité ? On avait pour habitude de lire "site xhtml strict", par quoi faut-il remplacer cette mention ?

Mais on peut utiliser des tableaux pour la mise en page en XHTML Strict... même les attributs align et valign pour <tr>, <th> et <td>, attribut width, border, cellspacing et cellpadding pour <table>...

Thomas : non, je parle du non emploi des tableaux pour ce qui est de la mise en page, pas de l'affichage de données tabulaires.

On peut peut-être parler de site "sémentiquement correct en vus de l'accessibilité" ou un truc du genre, mais c'est trop flou. Je cherche le moyen de définir un site "pas comme les autres", écrit dans le soucis d'une bonne accessibilité.

Dom > Comment défineriez-vous un site qui n'utilise pas les tableaux pour les mises en page, mais les div, avec le respect de l'accessibilité ? On avait pour habitude de lire "site xhtml strict", par quoi faut-il remplacer cette mention ?

C'est tout simple, en fait : site HTML4.01 STRICT ;)

Dans le choix d'un doctype (qui n'est rien d'autre qu'une norme) on peut aussi prendre en compte le mode (quirks ou standard) des navigateurs.

Un article très intéressant à ce sujet (en anglais) avec notamment un tableau sur les doctypes/navigateurs/modes :
hsivonen.iki.fi/doctype/

Dom > Thomas : non, je parle du non emploi des tableaux pour ce qui est de la mise en page, pas de l'affichage de données tabulaires.

Oui, mais non ;-). Le débat « Tableaux ou divs pour la mise à page » n'a rien à voir avec les DTD « Strict ».

@Dom : "Question subsidiaire à Raphaël : ce n'est pas une attaque, loin de là (je te respecte énormément), mais j'espère juste que ce revirement de situation n'est pas lié à ta recherche d'emploi, ce serait vraiment dommage."

>> Très certainement pas ! ;) C'est juste que je me pose des questions existentielles en ce moment.
De toute façon, pour les agences que j'ai contactées et qui ne connaissent que le Wysiwyg pur tableaux, faire du XHTML strict ou du HTML strict est tout aussi barbare :)

Pour moi, il n'y a pas de problème. Le W3C recommande d'utiliser les dernières spécifications. XHTML est la dernière. En 1.0, le W3 dit qu'on * peut * le servir en tant que text/html si le navigateur ne gère pas le application/xhtml+xml. Parfait. Je suis donc les spécifs à la lettre : je fais de la négociation de contenu et je balance du text/html à tout navigateur qui ne met pas application/xhtml+xml dans son Accept. Pourquoi s'en priver ?

Le W3C a prévu ce problème de compatibilité dans sa spécification en autorisant l'envoi en text/html... profitons-en ! Le W3C a comme politique de privilégier la compatibilité descendante plutôt que ascendante. En revenant au HTML 4.01, vous ne suivez pas cette politique et la pérénnité de vos sites s'en trouvera diminuée, simplement parce que vous voulez être "honnête" avec un navigateur qui ne pose pas de problème à lire du XHTML servi en text/html ? Pour moi, c'est disproportionné.

Thomas>Oui, mais non ;-). Le débat « Tableaux ou divs pour la mise à page » n'a rien à voir avec les DTD « Strict ».

Oui, je m'explique mal. Pour moi, honnêtement, je me moque de faire une page avec un DTD strict, en XHTML ou HTML.

Le plus important, c'est l'accessibilité des pages. Cette accessibilité ne dépend pas du DTD, comme tu le dit effectivement, mais de la sémentique employée par le développeur.

Je suis personnellement très fier quand je vois que le contenu de mes pages est propre et accessible en désactivant les CSS. Et que les balises sont employées à bon escient.

C'est tout ce qui compte.

Les normes imposent de dissocier le fond et la forme. Il y a pleins d'avantages à ca, alors j'applique ! Et comme le rappel Raphaël, il est possible de procéder ainsi en HTML. Ce n'est dont pas obligatoire d'adopter le XHTML pour ça.

Les normes imposent de fermer toutes les balises. Ok, c'est pas indispensable, mais cela apporte de la rigueur dans le développement, et permet parfois de corriger un bogue d'affichage. Alors j'adopte et m'y tiens !

Les normes imposent l'emploi de balises à bon escient. Il n'y a que des avantages à ca, en matière d'accessibilité. Alors j'adopte !

Voilà la lecture à faire des normes. Rien de plus.

Maintenant, je cherche un texte court à mettre en bas de mes pages, permettant aux visiteurs de se dire : "tiens, ce site est différent des autres ?". La mention "site xhtml strict" ou autre ne parle pas aux non informaticiens. Sans parler qu'elle n'est pas directement liée à l'accessibilité. Moi, je souhaite une formulation qui interpèle le visiteur, et qui le renvoie sur une page explicative sur l'intérêt d'un site -sémentiquement- bien écrit, en vue d'une meilleure accessibilité aux handicapés.

Finalement, c'est bien ca le but de la normalisation, faire du web un espace accessible à tous.

J'ajoute : si tout le monde qui utilise les dernières spécifications (XHTML) revient aux anciennes (HTML), comment voulez-vous que les navigateurs commerciaux tels que IE voient un intérêt de mieux supporter le XHTML ? Personne ne l'utiliserait !

@e-t172 : "Personne ne l'utiliserait !"

> Peut-être, mais ça ne me gênerait pas plus que ça. XHTML 1.0 est un produit hybride, pas fini qui ne sait pas trop lui-même à quoi il sert (il est un peu HTML et un peu XML selon les goûts). Bref, pour rappeler tout ce qui a été dit : ce n'est en fait qu'une sorte de HTML où la rigueur est imposée.

Par contre, XHTML 1.1 lorsqu'il sera supporté correctement, et XHTML 2.0 seront - eux - une réelle avancée.

XHTML 1.0 est une avancée. Pourquoi ? Parce qu'on peut le générer avec DOM ou XSLT et parce qu'on peut le parser.

Il y a fort à parier que dans l'avenir, les technologies XML seront omniprésentes. Donc, s'il est très propable que les navigateurs du futur pourront lire le XHTML 1.0, en revanche je suis beaucoup plus sceptique pour le HTML qui sera du "vieux" SGML.

XHTML garantit l'opérabilité car l'opérabilité est une partie intégrante de XML. XML a été conçu pour ça. Si quelqu'un s'amuse à programmer quelque chose qui génère une table des matières à partir des <h*> d'une page, il va en chier énormément pour une page HTML. Pour une page XHTML, il le fera en 5 minutes chrono. Ce n'est qu'un exemple, mais on peut imaginer quelque chose de beaucoup plus grand, par exemple un traitement en masse de plusieurs milliers de documents d'une entreprise, qui prendrait beaucoup moins de temps en XHTML valide. XHTML réduit donc le temps - donc les coûts - par rapport à HTML. En choisissant le HTML, tu t'exclus de cette évolution.

Et ce n'est pas parce que toi tu n'utilises pas les technologies XML que les autres ne l'utilisent pas. Si je veux afficher sur mon site la liste des topics d'un de tes forums, je peux le faire en 5 minutes en le parsant avec DOM et PHP 5. Si c'était du HTML, je mettrais une bonne journée et ce ne serait même pas fiable. XHTML nous facilite la vie, et même si on ne le sent pas maintenant, on le sentira plus tard. Et là on sera contents de ne pas être passés plus tard au XHTML.

il est un peu HTML et un peu XML selon les goûts



C'est justement tout l'intérêt non ? ça permet de se tourner vers l'avenir et envisager une utilisation en tant que application/xml+xhtml et d'envisager l'utilisation d'autres types de données xml tout en permettant une compatibilité descendante...

Je rajoute un petit truc:

De très nombreux sites utilisent maintenant des templates avec PHP en utilisant un moteur basé sur des reg exp style celui de phpbb, phplib etc.

Mais on peut très efficacement faire ça en utilisant des document xml et faire des transformations xslt.

ça c'est possible si on génére des document xhtml et donc de vrais documents xml.

Utiliser des documents xml et les transformer avec xslt pour en faire des document hmtl, ça n'a pas grand intérêt... c'est même complètement absurde je trouve.

@Cedric > Oui, mais je n'avais pas retenu cet argument car ce n'est pas vraiment avantageux pour un site simple :

www.e-t172.net/2005/02/24...

C'est vrai que c'est beaucoup plus lourd à programmer.

Concernant l'utilisation des ressources, le problème est que pour les petits sites, ça reste faisable, mais en même temps, pour des petits sites c'est pas réellement avantageux.

Par contre pour des gros sites où l'utilisation de php5 et xslt est intéressante, ça consomme beaucoup de ressources...

Et de toute façon, seuls les gros sites peuvent se permettre de se payer un hébergement offrant les prestations nécéssaires pour mettre en oeuvre ces technologies.

Mais on s'écarte du sujet ;)

Dernier déviage: ovh supporte l'extension xsl de php5 même sur les tout petits "pack" d'hébergement :)

@Raphaël: si le HTML4 et XHTML sont identiques, pourquoi revenir en arrière alors que tu maîtrises un outil potentiellement beaucoup plus puissant?

J'ai pas tout lu vers la fin (un peu du mal à suivre, trop naz), mais là :
Thomas > "Ce qui me semblerait excessif, ce serait de vouloir convertir du XHTML en HTML parce que ce serait *mieux* "

Wowowow qui a parlé de convertir qui que ce soit ?????
Ca y est le grand Raphaël Goetter maitre parmi les maitres, grand gourou de la secte W3C & cie à dit qu'il se demandait s'il ne valait pas mieux faire du HTML4.01 que du xHTML1.0 par rapport au contenu réel, donc tout le monde doit faire pareil... Qu'est ce que c'est que ça ???

C'est une réflexion, une remise en question, un replacement dans les objectifs, ça n'a rien d'une dictature qui voudrait imposer sa façon de penser aux autres. C'est quoi ça...

Ehh mais sans déconner, vous lisez ce qui est écris ??

Vous êtes bien gentil avec vos cassage d'opinion **personnelle**, mais vous dîtes la même chose que ce que j'ai pu dire dans un de mes commentaires. Vous me parlez de parsing XSL, et autres choses du genre... Ehh bien oui, c'est là qu'xHTML est utile et prend son sens à être utilisé (en application/xhtml+xml), je l'ai dit, mais pour 99% des sites xHTML "strict" W3C compliant et autres super boutons 80*15 en bas de pages, xHTML n'a aucun interet et c'est là tout le propos.

xHTML n'a pas de réelle utilité dans les plupart des pages, ce n'est rien que du HTML, mais lorsque des processus basé sur XML ou XSL sont utilisés, là oui bien sûr qu'il FAUT utiliser xHTML. xHTML n'est pas inutile, loin de là, il faut juste l'utiliser quand c'est nécessaire et pas à tout va comme une mode.
Par contre, là où *je* me pose des *questions*, c'est où est la différence entre xHTML1.0 et xHTML1.1.

Donc pour récapituler ce que pas grand monde ne semble comprendre :
- utiliser xHTML1.0 pour faire du HTML tout simplement, aucun interet, autant utiliser HTML4.01 (qui sera toujours compris par les futurs navigateurs en tant que HTML4.01, puisque c'est une norme, et que ces normes sont faites pour ça)
- utiliser xHTML1.x (en application/xhtml+xml) pour réellement faire du xHTML, parsing XSL, inclusion de SVG, de MathML et autres dérivés d'XML, là OUI, bien sûr qu'il faut l'utiliser.

Ce qui est dit, c'est finalement "choisir un doctype *adapté* et s'y tenir". Et encore une fois, c'est pas parceque mÔssieur Raphaël Goetter à dit ci ou ça qu'il faut absolument faire pareil, qu'il faut prendre ça comme parole d'évangile. Faut se faire son opinion un petit peu.

Euh, ça fais nerveux du clavier mes 2 derniers commentaires, mais bon, faut pas prendre ça comme une attaque ;)
Je suis juste très agacé que les propos soient déformés et mal interprétés, on fait dire des choses qui ne sont pas dites etc.

C'était juste histoire de mettre les choses au clair :P Je mord pas ^^

Bon, je vais préciser que le blog Alsa et - par définition - un carnet personnel et qu'il n'est pas déclaré source officielle AFP ;)

Donc je ne dis que tout le monde doit adopter HTML, je dis simplement que je me pose des questions... en attendant XHTML 1.1 et 2.0 correctement implémentés.

Rien de méchant hein, faut pas que ça vous empêche de dormir :P

"Donc pour récapituler ce que pas grand monde ne semble comprendre :
- utiliser xHTML1.0 pour faire du HTML tout simplement, aucun interet, autant utiliser HTML4.01 (qui sera toujours compris par les futurs navigateurs en tant que HTML4.01, puisque c'est une norme, et que ces normes sont faites pour ça)
- utiliser xHTML1.x (en application/xhtml+xml) pour réellement faire du xHTML, parsing XSL, inclusion de SVG, de MathML et autres dérivés d'XML, là OUI, bien sûr qu'il faut l'utiliser."

Copier-coller :

"Et ce n'est pas parce que toi tu n'utilises pas les technologies XML que les autres ne l'utilisent pas. Si je veux afficher sur mon site la liste des topics d'un de tes forums, je peux le faire en 5 minutes en le parsant avec DOM et PHP 5. Si c'était du HTML, je mettrais une bonne journée et ce ne serait même pas fiable. XHTML nous facilite la vie, et même si on ne le sent pas maintenant, on le sentira plus tard. Et là on sera contents de ne pas être passés plus tard au XHTML."

Et je répète encore que tu ne tiens absolument pas compte de la perrenité dans tes propos...

"ce n'est pas parce que toi tu n'utilises pas les technologies XML que les autres ne l'utilisent pas" Encore une fois, c'est exactement ce que je n'arrete pas de dire !!!!!!

Relis.

La perenité ?? où est le problème ? Un code respectant une normes définie fonctionnera dans le futur, que ce soit du HTML4.01 ou du xHTML1.x point barre.

" "ce n'est pas parce que toi tu n'utilises pas les technologies XML que les autres ne l'utilisent pas" Encore une fois, c'est exactement ce que je n'arrete pas de dire !!!!!! "

Non non non. Tu n'as pas compris. Je dis simplement que si tu fais un site en HTML, tu ne te compliques pas plus la vie, mais tu compliques la vie des personnes tierces qui veulent le parser pour une rayon X. Je ne crois pas que tu aies vu mon propos de ce point de vue...

De ce point de vue, en effet. Mais là de ton côté aussi (oui se prendre le chou sur HTML/xHTML, c'est chercher la petite bête) tu vas chercher la petite bête. Là c'est un problème bien plus complexe, dans cette optique, il faudrait tout faire en fonction des autres. Ca me parait une solution plutôt difficile à mettre en oeuvre actuellement, même xHTML à ce niveau ne me semble pas suffisant.

Mais là je ne partage pas ton avis (question de choix ici ;)), j'ai plus interet personnelement à utiliser telle ou telle chose que d'interet à utiliser telle ou telle autre pour une tierce partie. Prend ça pour de l'égoïsme si tu veux, mais ce n'est pas dans ce sens. J'utilise AVANT TOUT, ce qui est adapté à MES besoins, sinon, on n'en sort pas.
Par ailleurs, un document HTML bien construit avec un balisage bien fait (fermeture des balises, balisage sémantique), il reste des possibilités.

Bon, maintenant que ce point est éclairci, moi j'arrete ^^, un peu marre de tourner autour du pot pour une question de l'ordre de la réflexion personnelle qui n'engage que celui qui veut.

"un peu marre de tourner autour du pot pour une question de l'ordre de la réflexion personnelle qui n'engage que celui qui veut."

Tout à fait d'accord, seulement une réflexion personnelle peut surement être alimentée par les réflexions des autres, c'est pour ça que raphael permet les commentaires et c'est pour ça qu'on li son blog ;)

Wé mais quand ça tourne à la déformation de propos... Enfin bref ^^ j'ai dit que je m'arretais là :D

Olivier > Wowowow qui a parlé de convertir qui que ce soit ????? [...] ça n'a rien d'une dictature qui voudrait imposer sa façon de penser aux autres. C'est quoi ça... [...] Ehh mais sans déconner, vous lisez ce qui est écris ?? [...] Donc pour récapituler ce que pas grand monde ne semble comprendre [...] Euh, ça fais nerveux du clavier mes 2 derniers commentaires [...]

Effectivement, ça fait un peu nerveux du clavier... Et en citations tronquées et propos attribués abusivement tu n'es pas mal non plus. Bon, on se caaaalme...

"xHTML n'a pas de réelle utilité dans les plupart des pages, ce n'est rien que du HTML, mais lorsque des processus basé sur XML ou XSL sont utilisés, là oui bien sûr qu'il FAUT utiliser xHTML"

Il ne faut pas seulement se baser sur ce que le développeur a besoin. Peut-être que pour un site, le développeur n'a pas l'intention d'utiliser un parser xml ou un truc du genre, mais qui sait si le développeur d'un autre site externe ne voudra pas parser ses documents pour en faire quelque chose ? Ne serait-ce pas mieux, peu importe le document, de l'écrire en fonction de ca ? Dans l'idée qu'un jour, peut-être, le développeur du site ou quelqu'un d'autres voudra parser le document ?

Je dis ca car en html strict, certaines balises ne doivent pas être fermées, comme <img>. J'imagine alors qu'il sera plus difficile de parser le document, non ?

"J'utilise AVANT TOUT, ce qui est adapté à MES besoins, sinon, on n'en sort pas."

Oui mais je croyais que l'internet avait pour but de faciliter le partage d'informations. Le xhtml améliore de beaucoup cet aspect non ? Faire en sorte qu'on puisse accéder facilement au contenu, que ce soit par son navigateur ou par un parser X me semble important.

"Il ne faut pas seulement se baser sur ce que le développeur a besoin. Peut-être que pour un site, le développeur n'a pas l'intention d'utiliser un parser xml ou un truc du genre, mais qui sait si le développeur d'un autre site externe ne voudra pas parser ses documents pour en faire quelque chose ? Ne serait-ce pas mieux, peu importe le document, de l'écrire en fonction de ca ? Dans l'idée qu'un jour, peut-être, le développeur du site ou quelqu'un d'autres voudra parser le document ?"

Merci Merkel, tu as dit exactement ce que j'avais dit plus tôt, mais en beaucoup plus clair ;)

Je ne voulais pas répéter ce que tu avais dis, j'ai été grillé par toi. J'ai vu ton commentaire après avoir posté. :)

Waaaa c'est pratiquement impossible que tu m'ailles grillé avec pas loin de 30 minutes d'écart. Je devais être dans la lune et j'avais pas lu ton commentaire ! :p

Très intéressante cette discussion, bravo à tous ces acteurs.
Après réflexion, lecture à droite à gauche, je viens de me décider à changer mes DTD pour repasser en HTML 4.01. J'ai beaucoup aimé ce lien: www.hixie.ch/advocacy/xht...

C'est tellement vrai en plus (et je m'inclus dedans) de voir des "document.write" au lieu d’utiliser des méthodes lié au noyau DOM, pas de déclaration xml, un balisage pour définir la langue du document et qui n’est pas compris pour du HTML (en quirks mode), ne pas inclure nos feuilles de style à la façon XML etc... :)

Bref il n’y a pas que le type MIME "text/html" ou "application/xhtml+xml" à gérer en fonction du navigateur rencontré mais plein d’autres éléments.

Sinon point de vu besoin, ben transformé des documents XML en HTML avec XSLT me suffit pour le moment (je sens que mon commentaire va plaire :D )

Je changerais peut être d'avis en continuant les autres chapitres de: www.amazon.fr/exec/obidos... que j'ai commencé hier soir.

A+

70 commentaires! Ca ressemblerait ti pas à un joli troll HTML4.01 vs XHTML parfaitement camouflé ce joli billet de blog? Félicitations Raphaël! :-D

bonjour

moi je suis d accord avec raphael
(ca fait bizarre j etais habitué a sibelius :))
j ai appris le html en fac avec un prof qui ne connaissait rien aux normes
j ai eu beaucoup de mal a generer du code propre au vu de la facon dont j ai appris
(pas de css, pas de dtd et vive les frames)

je me suis donc mis aux css et sans comprendre je mettais des dtd xhtml
maintenant je me rends compte que je ne comprends rien de rien aux dom et autres applications xml et avant de lire cet article j avais deja commencé a remettre des dtd html
donc je comprends tres bien ce que veut dire raphael (meme si lui saurait ecrire de bôs docs xhtml)

je lis vos commentaires et je ne comprends vraiment rien enfin vaguement (je suis pas debile non plus ;))

juste pour vous faire rire une anecdote qui explique bien l idee
le jour ou mon fai m a dit que j avais droit au php sur son serveur j ai changé toutes les extensions htm de mon site en php pour faire bien ^^

je crois pas que raphael demande la mort du xhtml mais juste son emploi a bon escient
une recommandation n est pas une norme :)

en tout cas merci a toi raphael de faire preuve de tellement d ouverture d esprit dans ce monde ou l ayatollisme semble etre une norme justement :)

"une recommandation n est pas une norme" > erreur, le terme anglais recommandation est trompeur et désigne bien une spécification, donc une norme (c'est pas moi qui le dit, c'est Laurent Denis).

désolé
j emploie les definitions de l aeronautique où la recommandation est un conseil et la norme une obligation :)

Bonjour,

Je voulais juste faire remarquer une chose : contrairement a ce qui a été écrit plus haut :

"Pour rappel, les seules différences entre HTML et XHTML tiennent de la rigueur :

* Toute balise ouvrante doit être fermée
* Balises et attributs en minuscules
* Valeurs entre quotes (apostrophes) ou double quotes (guillemets)
* Chaque propriété doit avoir une valeur (pas de propriété vide)
* Les balises doivent être correctement imbriquées

... Or on peut très bien avoir exactement la même rigueur dans la norme HTML 4.01 Strict."

La convention d'écriture du HTML 4 est différente de celle du XHTML. Pour n'en citer que deux :

Toutes les balises ne sont PAS a fermer.
Les balises sont en MAJUSCULES.

Donc si on souhaite réellement produire un code HTML conforme aux recommandations du W3C, on applique pas les mêmes conventions d'écriture en HTML qu'en XHTML...

;)

@Pierre :

"Toutes les balises ne sont PAS a fermer.
Les balises sont en MAJUSCULES."

> Je ne crois pas que les Spec HTML *imposent* de ne pas fermer les balises, ni d'écrire les balises en majuscules.

Bref, on peut très bien faire du HTML strict valide avec des balises fermées et en minuscules :)

En fait, sans vouloir juger de la crédibilité de ce ticket, je trouve le débat un peu stérile.

Il se trouve que le xhtml 1.0 a été vu comme une passerelle entre l'HTML et le prochain xhtml, avant peut-être d'arriver au tout xml.

Tout ceci va dans le bon sens, en vue d'une homogénéité des documents. Bien-sûr, l'homogénéité prendra des années, mais c'est un bon début.

Vouloir retourner au HTML, c'est effectivement envisageable, mais n'apporte strictement rien. XHTML1.0 a été créé intelligemment, et permet une compatibilité avec tous les navigateurs récents. Il a apporté une rigidité dans l'écriture, en vue des prochaines versions du XHTML puis XML. Et encore, personne n'est obligé de respecter cette rigidité puisque qu'une DTD transitionnal a été pensée.

Je pense donc que, défenseurs de l'accessibilité et des standards nécessaires à une uniformisation (d'un point de vue codage) des documents, nous avons intérêts à suivre l'évolution logique du passage de l'HTML au XHTML, en produisant dès aujourd'hui des documents XHTML1.0

Au risque de me répéter, il n'y a pas de raisons valables à revenir sur le HTML (quand on défend les recommandations du W3C et que l'on connaît les avantages du XHTML).

Le XHTML, même "servi à la sauce" text/html n'est pas un problème en soi, puisque les acteurs du W3C l'ont prévu ainsi et que les navigateurs s'en satisfont.

Comme il l'a été rappelé plus haut, vous n'êtes pas des gourous, et avez bien le droit de vous remettre en question. Pour ma part, en tant que "défenseur" du XHTML, je suis personnellement déçu car vous aviez (les nombreux commentaires l'affirment) une très forte influence sur la communauté des développeurs, et je suis prêt à parier que certains vont maintenant produire du HTML401.

Je voudrais leur dire que rien ne les oblige à agir ainsi, et qu'ils ont tout intérêt à poursuivre leurs efforts dans la lignée des recommandations du W3C (et OpenWeb), pour ne citer que les plus importants.

Très bon week-end à tous.

> Je ne crois pas que les Spec HTML *imposent* de ne pas fermer les balises, ni d'écrire les balises en majuscules.

Pour certaines si : "Balise ouvrante : obligatoire, balise fermante : interdite"

Je suis tombé ici par hasard, j'en profite juste pour dire que perso, je code en xhtml 2.0 (sorti en juillet de l'année dernière).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "TBD">

Sincèrement, ça ne me sers à rien mais j'ai pris l'habitude faire comme ça au point d'aller aussi vite qu'en HTML 4.01 ou xhtml 1.0 ou 1.1.
Par contre mon code y a gagné en légèreté et en clarté.

Dans la conception web, il n'y a à mon sens qu'une règle :
Tant que c'est affiché partout pareil, c'est bon. Après il faut choisir le standard dans lequel on est le plus à l'aise, tant dans la conception que dans la maintenance.

J'ai choisi xhtml, mais cela est peut-être aussi lié à ma jeune expérience qui fait que je connais plus xhtml que html. Question de générations peut-être... ;)

Je n'ai pas lu tous les commentaires, mais voici ce que j'en pense :

les navigateurs embarquant un moteur XML affichent plus vite les pages XHTML.

les navigateurs embarqués sur un périphérique portable peuvent parfois lire du XHTML, et pas du HTML, et c'est d'ailleurs en partie pour ça que XHTML a été créé : pour alléger la sauce.

e-t172 a écrit :
« le terme anglais recommandation est trompeur et désigne bien une spécification, donc une norme (c'est pas moi qui le dit, c'est Laurent Denis). »

Il a écrit ça Laurent Denis ?

Parce qu'il a aussi écrit ça :
« Que je souhaite simplement disposer, en tant qu'utilisateur du Web, de formats universels, ouverts et pérennes. Qu'on les baptise d'une manière ou d'une autre m'est totalement indifférent. »

normand.no-ip.org/?2005/0...

Sans vouloir faire redondance, je précise quand même que je partage entièrement l'avis de Deliv. ;)

@Deliv> juste pour dire que perso, je code en xhtml 2.0

Ouais si tu veux. Je trouve un peu idiot de jouer avec un truc en Working Draft mais bon...

"Je suis tombé ici par hasard, j'en profite juste pour dire que perso, je code en xhtml 2.0 (sorti en juillet de l'année dernière)."

Il n'est pas sorti, c'est un brouillon et ta page ne peut pas être valide car XHTML 2.0 n'est pas encore passé au stade de recommendation :)

@Raphael : dans mes bras. À titre de rappel, blog.dreams4net.com/Xhtml...

Tout d'abord pour corriger quelques idées reçues que je vois dans les commentaires :
- on peut très bien faire du DOM sur du HTML, il y a même un module DOM prévu rien que pour ça. Le HTML est aussi hiérarchique que le XML, il n'y a pas plus de problèmes pour faire du DOM dessus.
- on peut très bien générer du HTML à partir de XSLT, c'était d'ailleurs le mode de fonctionnement de mon ancien blog. Il y a même une instruction spécifique en XSLT qui ne sert qu'à ça.

La seule différence entre le XHTML et le HTML c'est la grammaire utilisée. Avez vous besoin de la grammaire XML ? pas pour DOM, pas pour XSL. Pour quoi alors ?

La bonne question c'est "qui utilise le document ?". À priori c'est probablement un navigateur. Tous les navigateurs utilisables que je connais décodent au moins aussi bien le HTML que le XHTML, parfois mieux.

Ma première question tranche donc pour le HTML mais je n'ai qu'une moitié de réponse. "qui d'autre utilise mon document ?". Certains peuvent utiliser des scripts ou des applications qui lisent le document. Ce n'est pas fréquent mais c'est possible. Maintenant, l'énorme majorité des pages est en HTML, pas en XHTML. Le moteur embarqué *devra* supporter le HTML, par contre il ne supportera pas forcément le XHTML. Là aussi on tranche coté HTML.
Un geek peut aussi coder une moulinette pour lire votre document via un moteur XML ? oui, c'est vrai, mais ce même geek peut tout aussi facilement intégrer une transformation automatique html->xhtml dans sa moulinette. Ca ne prend pas beaucoup de temps et il y a plein d'outils qui font ça. Bref, ce n'est pas vraiment un critère.

Dès lors le truc c'est : "si c'est moins bien supporté ou en tout cas pas mieux, ai-je une raison de passer à XHTML ?"
Là certains vont me répondre oui mais réfléchissez bien, la plupart vont répondre non. C'est simplement mon cas, c'est visiblement aussi celui de Raphael.
Et pour ceux qui répondent oui, j'aimerai bien savoir ce qui motive ce oui. Certes on peut mettre du RDF, du SVG et plein d'autres joyeusetés mais vu le support actuel des navigateurs ça me semble hasardeux.

Je rejoins tout de même les pro-xhtml sur un point : quand j'apprend le html à des gens (je donne des formations sur le sujet régulièrement), oui, là, c'est souvent effectivement le xhtml est plus simple, donc est une bonne option.

Bonjour,

J'ai demandé l'avis de Tristan Nitot (Mozilla and OpenWebGroup Contributor), sur le sujet, pour avoir un autre avis sur la question.

Je vous invite à lire sa réponse :

standblog.org/

Je le remercie pour sa réponse publiée quelques minutes seulement après l'envoi de mon mail.

Lien plus précis vers le standblog :
standblog.org/blog/2005/0...

@Raphaël, on est pas tout seul :D (cf commentaire d'Eric Daspet)

Bonjour,
je pense (et c’est mon humble avis) que la réflexion porte plus sur le fait que tant qu’a utiliser le XHTML alors il faut aller jusqu’au bout et non faire du XHTML dans une optique de le sortir en text/html (ce que ce langage nous offre et heureusement) et oublier/négliger énormément de choses.

A votre avis pouvons nous avoir un document bien formé + valide d’un point de vu DTD mais qui ne donne pas le résultat voulu dans un contexte XML ?

J’ai continué la lecture de mon livre (qui date de 2000, donc peut être que les choses ont changé mais le principe est là à mon avis)
Au chapitre 3 on me parle de balises meta qui sont reconnu dans un mode HTML mais pas dans un monde XML.
On me dit qu’il faut que je me tourne vers un format RDF qui me permet de décrire mon document.
Ok alors moi je me dis que si je veux alors que mon document soit VALIDE (tiens la route) dans un contexte XML alors il faut que je prévois cette alternative.

Combien de personnes utilise t’il ce métalangage de description ?

Encore une fois à mon humble avis beaucoup font du XHTML (et je m’inclus encore dedans) mais reste dans une philosophie HTML et ne vont donc pas au bout des choses.

Bref c’est pas si grave hein &#61514;

franchement je me soucie pas de savoir comment s'appelle le code que j'écris :-) qu'il s'appelle HTML ou XHTML, je me contente d'appliquer les recommandations et voila.
Le but étant de rester lisible pour le plus grand nombre sur internet.

et en plus vu les bugs des navigateurs par rapport à l'interprétation des CSS et du code, j'ai bien du mal à obtenir une validation complète sur tous les points. Alors je teste sur différents navigateurs et si ça s'affiche lisiblement je m'arrête là :-)

comme dit Nosoucy, bref c'est pas si grave :-)

@Ziala > le CSS n'a justement rien à voir avec le choix du langage. C'est une grande idée reçue.

"je me contente d'appliquer les recommandations"
> Mais lesquelles justement ? :) Il y'a une recommandation HTML et une XHTML ;)

"Maintenant je t'accorde que tu peux fermer tes balises même en HTML 4.01."
"Je ne crois pas que les Spec HTML *imposent* de ne pas fermer les balises."

Ah non ! Les balises autofermantes, représentant les éléments vides comme <img /> ou <meta />, sont interdites en HTML. Donc HTML impose de ne pas fermer certaines balises.

Le XHTML est plus rigoureux et, comme dans tout ce qui touche la communication, la rigueur ne peut etre que bénéfique.
De plus, les débutants comprennent plus facilement les impératifs du XML que les libertés floues du HTML.

On parle du futur, du vrai XHTML à venir... et bien préparons-le ce futur, même si ça semble vain de coder en XHTML du simple texte avec balises.

Pierre Dureau a dit:
Ah non ! Les balises autofermantes, représentant les éléments vides comme <img /> ou <meta />, sont interdites en HTML. Donc HTML impose de ne pas fermer certaines balises.


Ok je ne suis pas un expert des recommandations et des standards, je ne suis qu’en phase de réflexion :) mais tout ce que tu dis nous ramène alors à :
Faire du XHTML avec sa grammaire associée (balise ouvrante accompagnée obligatoirement d’une balise fermante) pour comme tu dis ‘préparer ce futur’ MAIS avec une sortie text/html pour produire au final un code non valide (du moins qui ne suit pas les recommandations HTML)

Il y a comme même un truc qui me chiffonne là dedans.
Enfin avec plus de recul et plus de culture sur les standards and co. je trouverais bien des réponses à mes questions.

Idée reçue n° 64878 : "le XHTML est plus strict", "le XHTML est plus rigoureux".


La réponse c'est "non". Le XHTML est plus verbeux, il est plus explicite, potentiellement plus simple à comprendre et à interpréter, mais pas plus rigoureux.
XHTML et HTML sont tous les deux des langages sans aucune ambiguité. Les fermetures de balises HTML ne sont pas toujours explicitement marquées leur position est toujours connue avec précision par un moteur SGML standard (à condition de faire du code valide).
Les règles sont les mêmes, l'arbre et la hiérarchie sont identique, il y a même moyen de passer d'un format à l'autre automatiquement sans aucune perte. Les deux sont aussi stricte.

Le fait de fermer explicitement les balises ça n'est pas de la rigueur, pour la machine (cible du HTML) ça revient au même. L'avantage est principalement pour l'humain, parce que c'est plus verbeux donc et demande moins de réflexion.

Merci pour ce petit article :) Je crois que ça fait longtemps que l'on en avait besoin !

Si je puis me permettre, Eric D. avait écrit qqch du genre il y a qques temps :

blog.dreams4net.com/Xhtml...

@Eric Daspet
Désolé Eric, mais quand tu lis "Start tag: required, End tag: optional" franchement il y a de quoi dérouter. Je ferme ? Je ferme pas ? Si je ferme pas ça change quoi ? Si je ferme c'est mieux ou il comprend quand même ?

Maintenant je te rejoint tout a fait sur le fait que l'on peu créer un document très propre en HTML 4.01 strict et que ça ne changera pas grand chose par raport au XHTML 1.0 strict. D'ailleurs si on suis quelques conventions (dont celle de toujours toujours fermer la balise quand c'est optionnel), il suffit simplement de changer de DTD et fermer les quelques balises balises ou en HTML ça dit "End tag: forbidden" et modifer quelques attributs par ci par la.

Pour moi passer en XHTML 1.1 est encore un peu prématuré mais se donner de 'bonnes habitudes' avec XHTML 1.0 ne fait pas de mal.

Qu'il est difficile de trancher avec des avis aussi argumentés de chaque coté.

Bon alors, moi je n'utilise aucune technologie xml (je ne sais même pas ce qu'est un dom...), l'aspect xml du xhtml m'est donc totalement inutile.
Logiquement (selon ma logique xD), passer en html 4.01 serait un choix tout à fait cohérent. Bon, ensuite pour quoi faire ? Au final, ça changerait pas grand chose..Mais c'est vrai que si on s'attache au "sens" des choses et à l'état d'esprit du web, ce qui est mon cas (je crois), c'est utile puisque ça a un sens. Soit.
Qu'est ce qui me rebute ? le fait de coder strictement, j'adore, c'est clair, c'est net.
Le xhtml strict, avec TOUTES les balises fermées est tout, j'adore cette façon de coder. Quoi ? Comment ? Le html peut être strict ? ha...certaines choses sont moins tranchées comme la fermeture de certaines balises optionnelles..bon, c'est pas grand chose, juste un choix.

Ca ressemble quand même fortement à un cercle vicieux ce truc, je m'en aperçois a force de changer d'avis lors d ema reflexion..Coder en xhtml alors qu'on se sert que du html et pas du xml, c'est pas très normal, passons au html 4.01, pour l'avenir avec les applications qui se serviront du xml de plus en plus courante et pour aller dans le sens de l'évolution du web,autant rester en xhtml 1.0, on sera préparé..En plus, mais j'aime la façon de fermer toutes les balises, je trouve ça plus clair, c'est très personnel mais c'est vrai..

Bon, je suis comme beaucoup, mon avis se perd et il ne reste plus que la reflexion..
Je vais suivre le sage qui nous disait "faut pas que ça vous empeche de dormir", donc je crois que je vais attendre de prendre encore plus de recul pour changer quoi que ce soit :)