Comme d’autre ont déjà cité, votre affirmation que le W3C est né après le WEB est totalement fausse et assez incongru pour qui contre connaît l’histoire du Web. (Voir le lien inclus).
Votre enracinement dans l’HTML est compréhensible, mais on voit au premier coup d’oeuil que vous ne connaissez pas l’ampleur des avantages du couple CSS/XHTML.
— Compatibilités ascendantes et descendantes
Aucun problème de ce coté, car les « tags » XHTML ne sont que ceux de l’HTML de base, certains « tags » son designer pour être abandonné tel <I>, mais un substitue mieux adapté existe <EM>.
— L’HTML est un langage tolérant, qui accepte les erreurs.
Le XHTML Transitional aussi accepte les erreurs.
— Interopérabilité
Encore une fois, le XHTML avec son code plus sémantique peut être vu par plus de gens et sur plus de plateformes que l’HTML, grâce a certaine feuille de style, il peut même s’adapter aux différents formats possibles.
— L’HTML est une norme d’usage.
L’HTML a été inventé et publié sous normes par les mêmes gens qui publient aujourd’hui les normes XHTML
— Les balises exotiques de l’HTML
À mon avis, elles ne sont pas une grande perte
— Les tables de mise en pages
Elles causent beaucoup de problèmes pour qui veut accéder à un site sur autre chose qu’un « browser » sur un ordinateur de bureau. De plus, elles sont — avec les « fonds tags » — responsable de 20 % de code dans chaque page. Sur un petit site 20 % de poids supplémentaire n’est pas vraiment important, mais sur un site de milliers de pages, ça devient embarrassant. D’autant plus qu’un simple document de quelques octets suffit généralement à remplacer tout ce code.
— Les frames
Ils ont toujours été une horreur pour l’indexation, mais en utilisant XHTML Frameset, on donne encore le choix.
— La perte de compatibilité et de souplesse
Un site XHTML n’empêche aucunement au Browser de supporter encore les anciens « tags », je ne vois donc pas ou est le problème de tenter de freiner la multiplication de code inutile. La compatibilité descendante dont vous parler n’est donc pas en cause.
— L’accessibilité
Il est effectivement possible de fabriquer des pages XHTML non accessible, mais il est beaucoup plus facile de faire une page HTML non accessible par l’utilisation de table et de font face.
— Le XHTML, même « strict », n’implique pas que les webmestres vont conserver des éléments clairs de structuration.
C’est là qu’on voit l’utilité de la validation, ainsi, s’il manque un niveau de titre <h1>...<h3>, la validation va nous avertir que le code ne semble pas correct. Le même problème arrive toujours en HTML, combien de gens code correctement les titres avec des <Hn> ? La plupart des codeurs que j’ai côtoyés utilisent plus souvent <font sise> combiner a <b>.
— Avant tout : privilégier l’apprentissage
« les balises fondamentales et simples : <HTML>, <body>…, <p>, <b>, <i>… ; dès ces rudiments il est possible de publier de l’information »
Rien n’est changé a ce niveau avec le XHTML sauf le remplacement de <b> et <i> par <strong> et <emphasis>.
« rapidement on apprend les balises supplémentaires permettant, en gros, de tout faire »
Encore une fois, rien n’est changé (a moins que vous ne soyez pas au courant que les tableaux pour présenter de l’information tabulaire est toujours présents dans le XHTML).
« une étape est franchie lorsqu’on comprend le principe des tableaux de mise en pages »
L’apprentissage ici est un peu plus complexe, mais l’apparition de logiciels WYSIWYG pour faire des CSS fera la même chose qu’avec les tables. Combien de gens commençant avec l’HTML sont capables de coder une table complexe à la main ?
« progressivement on affine et simplifie son code avec des feuilles de style »
Encore une fois aucune différence n’ente l’HTML et le XHTML
« à la longue on parvient à séparer plus nettement les feuilles de style et le contenu, ce qui effectivement permet d’obtenir un code plus « propre », plus léger… »
Donc à la longue on fait du XHTML, ne serait-il pas plus simple de BIEN commencer plutôt ?
En fait, je trouve votre article déplorable de la part d’un site professionnel, il est a mon avis incompréhensible que les gens ne voient pas tous les avantages du XHTML, mais plus je lis sur le Web, plus je comprends qu’il ne salit souvent que de paresse intellectuelle. Il est un peu plus difficile d’aborder le CSS, mais il ne m’avait pas été plus facile d’apprendre à coder à la main mes pages en 1994. L’apparition d’application WYSIWYG de CSS va probablement faire taire les gens comme vous qui ne semblez pas comprendre l’utilisation de XHTML/CSS.
Comme d’autre ont déjà cité, votre affirmation que le W3C est né après le WEB est totalement fausse et assez incongru pour qui contre connaît l’histoire du Web. (Voir le lien inclus).
Votre enracinement dans l’HTML est compréhensible, mais on voit au premier coup d’oeuil que vous ne connaissez pas l’ampleur des avantages du couple CSS/XHTML.
— Compatibilités ascendantes et descendantes
Aucun problème de ce coté, car les « tags » XHTML ne sont que ceux de l’HTML de base, certains « tags » son designer pour être abandonné tel <I>, mais un substitue mieux adapté existe <EM>.
— L’HTML est un langage tolérant, qui accepte les erreurs.
Le XHTML Transitional aussi accepte les erreurs.
— Interopérabilité
Encore une fois, le XHTML avec son code plus sémantique peut être vu par plus de gens et sur plus de plateformes que l’HTML, grâce a certaine feuille de style, il peut même s’adapter aux différents formats possibles.
— L’HTML est une norme d’usage.
L’HTML a été inventé et publié sous normes par les mêmes gens qui publient aujourd’hui les normes XHTML
— Les balises exotiques de l’HTML
À mon avis, elles ne sont pas une grande perte
— Les tables de mise en pages
Elles causent beaucoup de problèmes pour qui veut accéder à un site sur autre chose qu’un « browser » sur un ordinateur de bureau. De plus, elles sont — avec les « fonds tags » — responsable de 20 % de code dans chaque page. Sur un petit site 20 % de poids supplémentaire n’est pas vraiment important, mais sur un site de milliers de pages, ça devient embarrassant. D’autant plus qu’un simple document de quelques octets suffit généralement à remplacer tout ce code.
— Les frames
Ils ont toujours été une horreur pour l’indexation, mais en utilisant XHTML Frameset, on donne encore le choix.
— La perte de compatibilité et de souplesse
Un site XHTML n’empêche aucunement au Browser de supporter encore les anciens « tags », je ne vois donc pas ou est le problème de tenter de freiner la multiplication de code inutile. La compatibilité descendante dont vous parler n’est donc pas en cause.
— L’accessibilité
Il est effectivement possible de fabriquer des pages XHTML non accessible, mais il est beaucoup plus facile de faire une page HTML non accessible par l’utilisation de table et de font face.
— Le XHTML, même « strict », n’implique pas que les webmestres vont conserver des éléments clairs de structuration.
C’est là qu’on voit l’utilité de la validation, ainsi, s’il manque un niveau de titre <h1>...<h3>, la validation va nous avertir que le code ne semble pas correct. Le même problème arrive toujours en HTML, combien de gens code correctement les titres avec des <Hn> ? La plupart des codeurs que j’ai côtoyés utilisent plus souvent <font sise> combiner a <b>.
— Avant tout : privilégier l’apprentissage
« les balises fondamentales et simples : <HTML>, <body>…, <p>, <b>, <i>… ; dès ces rudiments il est possible de publier de l’information »
Rien n’est changé a ce niveau avec le XHTML sauf le remplacement de <b> et <i> par <strong> et <emphasis>.
« rapidement on apprend les balises supplémentaires permettant, en gros, de tout faire »
Encore une fois, rien n’est changé (a moins que vous ne soyez pas au courant que les tableaux pour présenter de l’information tabulaire est toujours présents dans le XHTML).
« une étape est franchie lorsqu’on comprend le principe des tableaux de mise en pages »
L’apprentissage ici est un peu plus complexe, mais l’apparition de logiciels WYSIWYG pour faire des CSS fera la même chose qu’avec les tables. Combien de gens commençant avec l’HTML sont capables de coder une table complexe à la main ?
« progressivement on affine et simplifie son code avec des feuilles de style »
Encore une fois aucune différence n’ente l’HTML et le XHTML
« à la longue on parvient à séparer plus nettement les feuilles de style et le contenu, ce qui effectivement permet d’obtenir un code plus « propre », plus léger… »
Donc à la longue on fait du XHTML, ne serait-il pas plus simple de BIEN commencer plutôt ?
En fait, je trouve votre article déplorable de la part d’un site professionnel, il est a mon avis incompréhensible que les gens ne voient pas tous les avantages du XHTML, mais plus je lis sur le Web, plus je comprends qu’il ne salit souvent que de paresse intellectuelle. Il est un peu plus difficile d’aborder le CSS, mais il ne m’avait pas été plus facile d’apprendre à coder à la main mes pages en 1994. L’apparition d’application WYSIWYG de CSS va probablement faire taire les gens comme vous qui ne semblez pas comprendre l’utilisation de XHTML/CSS.
Voir en ligne : A Little History of the World Wide Web