Excellent sujet mere-teresa, et je partage complètement ton point de vue sur la question. Une rapide visite sur le top 50 des pires sites est édifiante.

Et il faut convenir que c'est un obstacle pour beaucoup de développeurs qui n'ont pas cette vision d'avenir. La séparation traitement/contenu/présentation avec par exemple PHP/XHTML/CSS a du mal à rentrer dans les moeurs, peut-être à cause des habitudes qui ont du mal à disparaître de faire tout en une seule opération. Peut-être aussi à cause (en grande partie?) des éditeurs utilisés, éditeurs WYSIWYG en particulier qui n'ont pas été conçus avec en arrière plan des idées de conformité de code: c'est la mode du RAD et il est plus facile et infiniment plus rapide de construire du tableau à la volée avec un logiciel comme Dreamweaver (®) sans toucher au code que de se pencher sur ce même code à la main.

À quand des éditeurs qui sortiront un code conforme et valide avec un minimum de retouches ?

Il y a aussi un autre aspect qui n'est pas négligeable quand on choisit de faire du XHTML strict c'est le poids de la page. Pour un site ayant beaucoup de traffic on y gagne énormément et vu le prix du go c'est pas rien

Je n'irai pas jusque là, on peut très bien faire des pages syntaxiquement correctes voire valides en XHTML et faire particulièrement lourd. Des tableaux HTML peuvent être valides en XHTML. Là où on gagnera, c'est dans la plupart des cas en les supprimant, mais on aborde là un autre aspect et on doit passer aux CSS. Ce qui fera la différence à mon avis, c'est le degré de séparation entre traitement / données / présentation.

Et il faut convenir que c'est un obstacle pour beaucoup de développeurs qui n'ont pas cette vision d'avenir. La séparation traitement/contenu/présentation avec par exemple PHP/XHTML/CSS a du mal à rentrer dans les moeurs

Ce que je ne comprends pas, c'est en quoi ceci est si supérieur à PHP/HTML/CSS ?
Lynx lit très bien les sites développés en HTML... C'est la séparation présentation/données qui est vitale, pas l'utilisation du XML. HTML est un format ouvert, un standard et en ça il est suffisant. Il ne faut pas sacrer XHTML langage web de l'année sous pretexte qu'il cause XML, et que c'est la grande mode de ces dernières années.

Je persiste à militer activement pour la séparation des données et de la présentation, pour l'utilisation intensive des feuilles de styles, mais pas pour l'utilisation systématique de XHTML comme langage tellement "mieux" que HTML.

Beaucoup font des sites en XHTML "parce que comme ça, ça valide", comme ça "je peux mettre le bouton [affreux] XHTML-Valid du W3C et ça pète la classe". Il n'y a pas ou peu d'intention louable derrière.

Si on fait un site web en pensant aux déficients visuels, ok, mais alors il faut le faire jusqu'au bout(*). Mais honnêtement, combien le font dans cette optique (ah ah, jeu de mots) ? Combien d'autres par contre le font parce que c'est "in'" ?

(*) Je n'ai pas de navigateur pour déficients sous la main, mais je pense que les 3/4 des sites "qui valident XHTML" ne passent pas si bien sous ces navigateurs... Alors que d'autres sites (valides bien sûr) HTML, mais avec une bonne séparation données/présentation passent bien mieux.
Je crois sincèrement que vous vous trompez de priorité : le langage importe peu, tant qu'il est bien écrit (HTML ou XHTML), l'important c'est cette séparation données/présentation.

Les CSS oui ! XHTML pas forcément...

(*) Je n'ai pas de navigateur pour déficients sous la main, mais je pense que les 3/4 des sites "qui valident XHTML" ne passent pas si bien sous ces navigateurs... Alors que d'autres sites (valides bien sûr) HTML, mais avec une bonne séparation données/présentation passent bien mieux.
Je crois sincèrement que vous vous trompez de priorité : le langage importe peu, tant qu'il est bien écrit (HTML ou XHTML), l'important c'est cette séparation données/présentation.

Tu te trompes de colère.
Le XHTML est une normalisation du HTML, qui est faite pour que le plus grand nombre de navigateurs lisent les sites !

Je cite Openweb (Pourquoi les standards du W3C ?)
car cela me paraît aller dans ton sens.
Pour moi tu t'énerves contre le XHTML parce qu'on en parle, alors que tu es pour, en fait...

En utilisant les standards du Web, et tout particulièrement les normes XHTML pour la structure des documents, CSS pour la présentation et DOM W3C jumelé à ECMAScript pour le DHTML, il est possible de communiquer avec tous les agents utilisateurs en ne parlant qu'un seul langage. On garantit ainsi que tous les navigateurs répondant aux normes de l'industrie pourront afficher correctement le contenu. Bien sûr, la présentation de ce contenu sera plus sobre dans les navigateurs plus anciens, mais il demeurera parfaitement accessible. Se conformer aux standards, c'est également accepter que le Web soit un médium flexible qui, contrairement à l'imprimé, s'adapte aux capacités des agents utilisateurs.

Pour moi tu t'énerves contre le XHTML parce qu'on en parle, alors que tu es pour, en fait...

Je m'énerve surtout contre le mépris ambiant du HTML, alors qu'il est tout aussi normalisé, tout aussi standard, tout aussi tout ce que vous voulez que le XHTML, sauf que ce n'est pas du XML.
Alors effectivement, j'ai une rancoeur envers le XML, tout simplement par esprit de contradiction, et parce que j'estime que cet effet de mode, et cette volonté de vouloir coller du XML partout rend trop lourds certains échanges (je pense en particulier aux web-services, qui sont inutilisables hors-lan car les échanges au format XML sont tout simplement trop lourds pour être gérables avec une bande passante "classique", et je trouve ça vraiment plus que regrettable).

Sans cette mode du XML, et cette volonté d'être "in" et de valider XHTML, on se retrouverait avec des sites :
- tout aussi valides (HTML est un standard du w3c, hein, au fait... autant qu'XHTML)
- plus légers (balises plus courtes, syntaxe globalement plus compact)
pour peu qu'on programme en HTML avec les mêmes soucis qu'en XHTML (séparation des données, respect des standards).

Je regrette profondément qu'on donne à un standard plus d'importance qu'à un autre, alors que le second est dédié au web depuis bien longtemps, et qu'il est plus léger, et plus simple.

Je regrette que le HTML ne soit plus considéré comme un standard du w3c pour la génération de pages web.

Je regrette que les web-services n'aient pas été développé avec un format ouvert mais, un standard dédié à ce protocole : pourquoi a-t-on encore fichu du XML ? Ce qui alourdit les échanges et le rend inutilisable sur le web...

Je suis bien conscient des avantages indéniables du XML, en particulier la possibilité de parser les pages avec autre chose qu'un navigateur web, mais je suis tellement hors de moi quand je vois tous les nerds qui codent XHTML "parce que c'est cool", que du coup je n'ai aucune envie de suivre la vague (comportement irresponsable, je l'admets).
Mais face à toute cette vague qui considère le XML comme le messie de l'informatique, il faut bien équilibrer les choses, alors du coup, moi je dis que c'est l'antéchrist... Mais au fond oui, je suis de mauvaise foi, oui je suis pour, et oui j'ai compris tous les arguments du oui (au xml, la constitution européenne c'est un autre débat ). Mais que faire face à la mauvaise fois inverse ?

Je ne vais pas rentrer en détail dans le débat mais globalement, j'approuve Naholyr.

Selon moi, l'essentiel est la qualité du code et cela dépend de celui qui le pond.
Peu importe que ce soit en HTML ou en xHTML, il faut du code propre et valide.

Maintenant, tant que le W3C proposera un validateur pour le code HTML,
tant que le HTML 4 (valide) sera correctement interprété par la majorité des navigateurs,
tant que le xHTML ne proposera pas des enrichissements significatifs et inacessibles en HTML,
je ne verrai pas de raison d'abandonner le HTML au profit du xHTML.

NB : Je continue d'utiliser la balise <b> au lieu de <strong> même si j'en connais les subtiles différences.
Mais, que voulez-vous, à mon âge...

c'est quoi les différences entre <b> et <strong> ?? si ce n'est le nom et que <b> passe pas au validateur strict ( enfin il me semble )

c'est quoi les différences entre <b> et <strong> ?? si ce n'est le nom et que <b> passe pas au validateur strict ( enfin il me semble )

Comme l'a dit mere-teresa, question de sémantique.

- "b" est le raccourci pour "bold". Donc <b> doit mettre en gras, c'est tout.
- "strong" signifie qu'il s'agit d'un élément important. On peut très bien choisir de mettre les éléments importants en rouge plutôt qu'en gras, et on il se trouve que <strong> rend en gras par défaut sur les navigateurs.

Du coup moi quand j'ai envie de mettre un truc en gras, c'est que je veux le mettre en gras -_-' donc je mets <b>, et après on m'engueule on me dit "non il faut mettre <strong> si tu veux mettre en gras", ce qui est fondamentalement stupide, vu que <strong> n'est pas fait spécifiquement pour mettre en gras, contrairement à <b> (ce qui prouve bien qu'on fait le bon choix en utilisant <b>, vu que j'utilise ce qui est dédié à la mise en gras).

Par contre si tu veux indiquer qu'un passage est important, <b> peut éventuellement ne pas être interprété comme ça (mere-teresa a pris l'exemple du navigateur vocal, qui mettra une inflexion de voix particulière pour les passage <strong>). Rendre un concept abstrait comme "important" sur différents media ne pose pas de problèmes, alors que rendre un concept strictement graphique comme "police grasse" ferme d'entrée la porte à tout media hors-écran.

Donc théoriquement, si je veux mettre un passage en gras "pour le look" ce sera <b>. Si je veux le mettre en gras "parce que c'est important", ce sera <strong> et j'ajouterai "pour le look" la feuille de style strong{font-weight:bold}.

Logique tout ça

P.S: <strong>, il est aussi dans HTML, sauf que <b> y est aussi... qui est le plus ouvert des deux ? hein ?

ok merci

Je cite Openweb (Pourquoi les standards du W3C ?)

Ce que je trouve le plus marrant, c'est que ce ne sont pas des standards, ce sont des recommandations: http://www.w3.org/2004/02/Process-20040205/tr#RecsW3C

Malgré qu'eux-même tendent à décrire ces recommendations comme étant similaires aux standards de certaines organisations.

Il n'en reste pas moins que le mot recommandation est utilisé dans tous leurs documents et non standard.

À méditer...

Je cite Openweb (Pourquoi les standards du W3C ?)

Ce que je trouve le plus marrant, c'est que ce ne sont pas des standards, ce sont des recommandations: http://www.w3.org/2004/02/Process-20040205/tr#RecsW3C

Malgré qu'eux-même tendent à décrire ces recommendations comme étant similaires aux standards de certaines organisations.

Il n'en reste pas moins que le mot recommandation est utilisé dans tous leurs documents et non standard.

À méditer...

C'est peut-être simplement que tout attachés qu'ils sont à la sémantique, ils veulent mettre les bons mots sur les bons concepts. Un standard personne n'est obligé de le suivre, on en fait ce qu'on en veut... En cela c'est plus une recommandation qu'autre chose finalement.

Il reste une question que je me pose par rapport à tout ça: il est vrai que le HTML est peut-être bien plus souple que le XHTML. Pourtant on sait que la version actuelle de HTML est 4.01 : on sait également qu'il n'y aura plus de mise à jour et qu'il est vain d'espérer une version 4.02 ou 4.1 voire 5.0. En revanche, on sait que XHTML en version 2 est en préparation depuis au moins deux ans et ce ne sera sûrement pas fini pour autant.

Alors on peut préférer coder en HTML, mais sachant que les navigateurs suivent également une évolution vers les nouvelles recommandations, on peut s'attendre à ce qu'ils interprètent de plus en plus incorrectement le HTML4 dans les années à venir parce qu'ils seront orienté vers une interprétation correcte du XHTML.

D'autre part, je voudrais mettre un bémol sur le propos de naholyr concernant les validations à la mode parce que c'est "in" : Il faut bien commencer quelque part. Si ceux qui font des sites (personnels ou professionnels) font déjà cet effort de rigueur dans leur codage, c'est un départ. Il est peut-être difficile de leur demander tout d'un coup. Lors de l'explosion de la bulle internet et de la multiplication des pages personnelles, la norme HTML étaient allègrement envoyée par dessus bord. Commençons avec du code valide et ensuite on intègrera la visibilité du contenu pour les internautes utilisant des navigateurs spéciaux, oral ou braille par exemple. À l'origine, le HTML n'avait d'autre but que de diffuser de l'information brute, puis est arrivé la mise en page et à ce stade, le web est devenu quelque chose d'essentiellement visuel. Je peux faire erreur, mais pour diffuser ce même contenu vers des médias particuliers, les techniques étaient un peu absente au niveau du HTML. XML est une solution qui apporte ce +, ce me semble, peut-être existe-t-il d'autres options ?

Mais le HTML est une partie du SGML, tout comme le XML :

- il y a des balises
- il y a une syntaxe à suivre
- il y a une DTD (d'où l'existence de navigateurs)

XML expliqué à mon DG reprend un peu l'histoire et explique bien
Différences entre HTML et XHTML reprend de façon claire l'origine et le pourquoi du XHTML.

Quelques images extraites de sites [stroke]étrangers[/stroke] allemands et néerlandais, qui expliquent un peu la filiation de ces langages de mise en forme.
Les schémas de cette page (allemand) sont intéressants, je pense

1. 
2. 
3. 
4.