Alors, pourquoi ton site en XHTML1.0, et ton autre site en XHTLM1.1 ?

Juste un truc qui n'a pas grand chose à voir avec l'article, mais ruby ne sert pas à afficher des signes diactritiques, mais des annotations. Les signes diacritiques, ce sont, par exemple, les accents ; ça n'a rien à voir. http://fr.wikipedia.org/wiki/Diacritique

Sinon, pour ce qui est du côté XML du XHTML, tu sembles oublier l'autre côté : oui, on peut partir du XHTML via XSLT, mais on peut aussi _générer_ du XHTML via XSLT... (oui, il y a aussi une méthode pour sortir du HTML via XSLT, mais ça n'a pas grand intérêt)

@ glandium : ah... "diacritique" m'a échappé à cause d'une tentative récente pour utiliser ruby en arabe Mais tu as tout à fait raison, et je corrige de ce pas.

Sinon, générer du XHTML via XSLT, bien-sûr. Mais ceci suppose bien forcément une source XML ? Donc, quel rapport avec le choix HTML / XHTML de la diffusion finale ? Je dois être un peu assommé par la canicule naissante, là

@ Julien : Pourquoi XHTML ici ? Pour explorer, justement

Un aventage (ou un inconvéniant, c'est celon) du XHTML 1.x strict, c'est qu'il est plus strict que l'HTML4.x strict.

Pour moi, c'est un aventage parceque:

-Ca donne moins envie de faire de la soupe de tag (je prèfère nettement la soupe au poireaux et celle au potiron). -Ca me correspond mieux étant quelqu'un d'assez scrict et scrupuleux.

Je ne suis pas d'accord concernant la lisibilité, je trouve un document XHTML plus lisible parcequ'il est plus strict, il y a moins de structure possible (par exemple: écrire uniquement en minuscule, les atributs ont obligatoirement un contenu, ...) mais, cette avis n'est pas nécessairement objectif.

Je trouve un très gros avantage avec XHTML : il est très strict. Mozilla n'affichat par ailleurs pas les pages XHTML contenant une erreur , je sais tout de suite si mon code est valide.

Plus de doute et d'approximation. C'est l'équivalent d'une phase de compilation.

Je dois dire que je suis resté perplexe après (et pendant aussi d'ailleur) la lecture de ton article... selon toi le xhtml strict ne serait pas mieux que le html (non valide ou valide) ... hmm ahh bon ... Je trouve pourtant que la bonne utilisation (que j'essai d'adopter) du xhtml strict lié aux css permet une lisibilité du code accrue, une manipulation et creation plus rapide et plus efficace, un allégement net du code, une meilleure evolutivité, une plus grande facilité de modification (via css, mais permi par xhtml strict propre). Enfin je trouve que tu vas un peu vite en besogne...

Sinon pour répondre à Bertrand, les pages xhtml contenant des erreurs sont tout a fait affichable, heureusement d'ailleur, sinon peu de pages seraient affichées ^^ Imagine le carnage pour un wiki ou tu ne controle pas totalement à 100% le contenu ! (enfin il me semble, mes connaissances sont un peu floues sur ce point) Je pense que tu voulais parler du XML qui la oui ne s'affiche pas à la moindre erreur.

@++

Je pense qu'il est tout à fait possible de faire des pages dont la présentation et le contenu sont séparés dans un fichier HTML4 et CSS et avoir des documents bien propres.

En ce qui concerne mozilla, il signale bien les erreurs sur du code XHTML, mais uniquement lorsqu'il est servi en tant que tel.

@ElMoustiko> Y a-t-il des DTD "mieux" que d'autres dans l'absolu ? Oui, par exemple :

- HTML4.0.1 est "mieux" que HTML3.2 avec par exemple l'introduction de nombreux éléments d'accessibilité. - Les DTD HTML et XHTML Strict sont "mieux" que les transitional, en raison de la disparition des éléments de présentation, de l'obligation de fermeture des balises, etc. - Les DTD (X)HTML Strict et Transitional sont "mieux" que les Frameset en raison des problèmes spécifiques posés par les cadres...

Mais on ne retrouve pas une telle différence qualitative entre HTML4.01 Strict et XHTML1.0 Strict, ou entre HTML4.01 Transitional et XHTML1.0 Transitional. XHTML est relatif à des besoins bien précis. Il est par ailleurs un terrain d'approche du XML à recommander à qui peut en tirer profit.

Dans le forum d'où est extrait ce billet, la personne qui avait commencé la discussion demandait au départ: "HTML 4.01 ET XHTML 1.0, comment mon site peut il etre valable dans les deux ????" A voir les compétences de cette personne, qui a commencé à maîtriser HTML et qui ignore tout des spécificités du XHTML, faut-il vraiment lui recommander XHTML ? Aurait-elle besoin de traiter du XML ?

Bien-sûr, il y a un aspect du XHTML qui n'était pas abordé dans ce billet : le fait que les règles de syntaxe du XML donne à l'auteur d'un document XHTML une marge d'erreur moins grande, en interdisant :

• les éléments et attributs en majuscules
• les attributs sans guillemets
• la non-fermeture d'éléments non vides
• la minimalisation des attributs

La validation XHTML oblige à respecter ces règles, ce qui peut-être un avantage.

Mais ceci relève tout aussi bien de bonnes pratiques de codage en HTML, pour l'auteur qui sait que la rigueur syntaxique lui simplifiera le débugage de ses pages : par exemple, puisque l'omission des guillements d'attributs provoque une erreur lorsque le contenu de l'attributs comporte des espaces, prendre le parti unique des guillemets systématiques est une question de bon sens.;

@laurent, au sujet de la personne "instigatrice" du topic, oui je pense que lui expliquer les règles du xhtml, la façon de coder en xhtml (en séparant contenu et mise en forme et donc en le liant aux css), de ne pas utiliser d'attributs de mise en forme dans ses pages est une bonne chose, ca rejoins un peu un article de mon blog, "Combat pour un web meilleur", tu n'avais pas l'air d'accord, le fait est que si l'on indique pas les marches à suivre aux débutants et qu'on leur laisse prendre les mauvaises habitudes (oui mauvaises, elles ne sont pas bonnes... vade retro satanas multi tableaux imbriqués, font et autres bgcolor ! ), le web restera encore bien longtemps cette poubelle de tag, ou cette "soupe de tag" (comme disait je ne sais plus qui, désolé pour lui). J'ai l'impression que tu ne veux pas inciter les gens à bien coder leur page... je trouve ca un peu dommage, enfin je doit aller un peu vite en besogne sur ce point ! Je trouve l'apprentissage du xhtml plus facile de par sa rigueur et ses "contraintes" (entre guillemets parceque selon moi, ca n'en est pas) que du html "soupe de tag" souvent pondu par des "ouisi ouigue".

Enfin bref... @++

ps: comme dit sur le topic du dit forum, discutaillez pas trop aujourd'hui !!!!!!!! que je n'en loupe pas une miette ^^

Comment faire comprendre que la séparation du contenu et de la présentation est pour l'essentiel acquise dans le passage du transitional au strict, et non dans le passage du HTML au XHTML ?

D'autre part, les tableaux imbriqués utilisés pour la présentation... sont tout aussi possibles en XHTML qu'en HTML.

Les elements de mise en forme sont proscrit en html4.01 strict ??? Je ne pensais pas, dans ce cas tu aurais alors raison. Mais de toute facon les tableaux utilisés pour la présentation alourdissent le code et meme s'ils sont utilisable en xhtml, il ne sont pas indiqués pour cette utilisation, c'est donc une déformation des "directives" données par le w3c.

L'aventage du XHTML 1.x strict sur le HTML 4.x strict, c'est qu'il est un peu plus restrictif et qu'il oblige plus à prendre de bonnes habitude, mais, ce n'est pas un aventage pour tout le monde, tout dépend du niveau de celui qui apprend à faire de l'(X)HTML.

Pour modérer le texte de Denis :

* sur le XSLT en fait être en XHTML simplifie un peu mais ne donne pas plus de fonctionnalités. La traduction HTML->XHTML peut être faite automatiquement et sans perte par n'importe quel outil à partir du moment où le HTML de départ est valide. Pour celui qui veut faire un traitement XSLT, rajouter un filtre de conversion en entrée ça n'est pas difficile (au regard du XSLT) : Tidy est très employé pour ça (entre autres). faire du XHTML directement facilite le travail mais n'apporte rien de plus.

* concernant le mélange de langages XML c'est la théorie. C'est très utile mais finalement très peu supporté, et ça pose d'autres problèmes (CSS qui ne comprennent pas les espaces de nom, doctype à modifier pour intégrer le mélange, DTD non adaptée aux namespace mais obligatoire en XHTML, etc.). C'est ce qui rendra le XHTML utile, mais pour l'instant c'est encore du domaine du futur.

* pour ce qui est du modèle strict : faire valider de façon stricte un HTML n'est pas complexe. Et pour ceux qui trouvent plus simple de ne pas profiter des possibilités de HTML, il est toujours autorisé de fermer les balises de paragraphes et autres.

Après .... blog.dreams4net.com/Xhtml...

@Eric : Faire valider de façon strict un HTML suppose que l'on maîtrise totalement le code produit. Ce n'est pas toujours le cas, selon les outils que vont employer les auteurs, les services auxquels on fait appel qui génèrent un code inclus dans la page, etc.

Sinon, je suppose que tu voulais écrire "possibilités de XHTML" ?

Si tu ne maitrises pas ta chaine et qu'elle peut te générer des choses non valides alors surtout ne génères pas du XHTML de toutes façons. Si tu considères le XHTML (qui est sensé avoir une gestion des erreurs stricte d'après les specs XML) c'est que tu maitrises de bout en bout la validité, sinon le HTML est quoi qu'il en soit le seul choix acceptable (non pas que ça soit mieux mais ça s'inscrit mieux dans les possibilités et la philosophie de l'existant HTML)

(non, je parlais bien des possibilités de HTML, de tout ce qui est écriture implicite : ne pas fermer les paragraphes par exemple, mais aussi ne pas délimiter les valeurs des attributs quand ce n'est pas nécessaire, etc. Celui qui trouve ça trop laxiste peut tout à fait prendre une attitude stricte tout en restant en HTML)

@Eric : je parlais de générer du HTML, non du XHTML, pour expliquer qu'il y a des conditions de production du code qui conduisent à opter pour le HTML transitional de préférence au strict.

Pour ce qui est d'écrire du HTML en fermant ses paragraphes, en délimitant ses valeurs d'attributs, voir mon commentaire ci-dessus blog-and-blues.org/weblog... : nous disons exactement la même chose