Le coutre-courant arrière-gardiste et contre-productif
30 avril 2005, 00:26, par Spécialiste
J’étais déjà passé (février 2004) dans cet article et ses commentaires où je m’étais immiscé. Je suis étonné que son auteur l’ait
conservé en ligne - d’autant qu’à moins d’être définitivement devenu résistant au changement, il a dû se rendre compte entre-temps de l’incongruité de ses arguments.
Je reviens donc avec 2 petites ambitions : apporter une preuve (ou un fort indice) de la validité de la démarche de respecter les
standards W3C dans un petit exemple, et encourager les concepteurs de sites à connaître, utiliser et apprécier les standards pour ce qu’ils peuvent nous apporter.
Je m’adresse plus en réalité aux commentaires qui disaient "Ouais t’as raison Arno, soyons des rebelles..." en propageant l’idée erronée qu’XHTML était plus compliqué qu’HTML (donc réservé à une élite), ou que le couple XHTML/CSS (càd la séparation la plus complète possible entre contenu et présentation) aboutissait dans des sites graphiquement pauvres, forcément moches...
Un site au design contemporain. On aime ou pas, mais on sent qu’il y a une vraie direction artistique et que ce n’est pas l’oeuvre d’un seul freak codeur qui a son "XML Reference" à côté du clavier.
Clic-droit dans la page (voir le code source...) et vous verrez du code XHTML. Pour ceux qui auraient fait la même chose sur la homepage d’Uzine (qui est encore très propre), on comprend très vite que XHTML est plus simple que HTML... c’est son but même
: épurer HTML des codes de formatage lourdingue pour le renvoyer au fichier CSS où le travail et la maintenance purement
"présentationnelle" et graphique peut se faire dans une meilleure lisibilité.
Si vous pouvez désactiver les styles (avec Firefox par exemple) ou en prévisualisant l’impression (là c’est pas beau, mais ils n’ont pas fait l’effort d’une feuille de style spéciale "print"), vous comprendrez ce que veux dire vraiment séparation entre contenu et présentation.
XHTML n’est qu’une norme qui formalise déjà des recommandations valables pour HTML 4.01... c’est pourquoi la différence est bien plus petite qu’on le sous-entend dans tout cet article (donc passage facile de l’un à l’autre) mais qui offre des avantages peu nombreux mais bien réels (donc c’est le moment de s’y mettre) :
1/ Mode de rendu plus rapide grâce au DOCTYPE ! qui fait passer le navigateur en mode de rendu "standards" ;
2/ Validation plus complète (on peut vivre avec à des sites non valides, mais un outil de diagnostique nous aide à savoir ce qu’on
fait).
3/ Compatibilité ascendante : c’est le plus passionnant. XHTML est le standard des "netdevices" pour l’HTML, càd que tous ces
téléphones portables, PDA et autres futurs appareils reliés à Internet (qu’on ne vienne pas me dire que c’est un petit marché ou qu’il est en recul...) vont lire XHTML mais pas HTML 4.01, car leurs navigateurs ne disposent généralement pas de la puissance
mémoire nécessaire à l’interprétation/correction automatique des erreurs qu’ont nos navigateurs en mode "quirk/dégradé". Exemple : un grand site portail à la charte graphique colorée (interface flexible à 100%) dans Explorer ou Firefox, un mode dégradé sans ascenceurs sur le petit écran d’un PDA, des pages qui s’impriment avec un minimum de couleurs et sans les informations écran colonne de menu à gauche par exemple) ou avec des sauts de page logiques... J’ai essayé, on peut. Un seul contenu : XHTML, plusieurs styles CSS en fonction du média de sortie.
Vous connaissez Zengarden... j’en connais plein d’autres (de + en +, si si), des sites beaux et "valides" (ou presque - en tout cas
l’effort et les résultats sont là).
Grâce aux CSS, on peut faire beaucoup plus qu’avec ces tableaux imbriqués lourdingues et images découpées au pixel. CSS n’est
pas parfait, CSS2 n’est pas supporté à 100% par tous... mais aujourd’hui on peut vraiment faire des sites super pro avec un peu de méthode.
Qui plus est, le positionnement CSS nous apprend à envisager des pages plus intéressantes, plus adaptées au web (interface flexible, blocs flottants...) que la grille d’un tableau, paradigme du graphisme prépresse figé.
Et donc, j’encourage tout le monde à lire le bouquin de Zeldman "designing with web standards" (il vient de sortir en français :
Un site full-CSS demande des connaissances, comme d’ailleurs un site en tableaux pour celui qui n’en a jamais fait. Mais l’énorme
avantage est l’économie d’échelle. J’ai pris des semaines à mettre au point mon premier site parfaitement valide (je parle de conception codage XHTML front/end, les CSS, l’infographie et un de XSL... le reste c’est le boulot des développeurs du CMS
derrière et de leur XML auquel je ne touche pas). Le deuxième aura pris 4 jours, le dernier 2 jours... Quant au premier cité, on
prépare une nouvelle version (nouvelles rubriques, nouveau layout, nouvelles idées sur base des feedback utilisateurs) et c’est d’une facilité... Ce qui est bien conçu en XHTML/CSS peut évoluer en un tournemain !
Faites l’effort de comprendre de quoi vous parlez avant de parler de XHTML, de grâce !
La rhétorique de l’article d’Arno est basée sur un déni de l’organisme W3C (La prétendue mainmise du géant de Redmond est presque sous-entendue), et l’idée totalement fausse qu’HTML est un standard "du peuple", libre de tout auteur, norme, ce qui ferait sa force. On peut même penser qu’on va être obligé de faire bientôt des sites en XML et XSL, ce qui est très compliqué, bla bla bla ! Ne mélangeons pas tout : rien ne vaut XML pour stocker des données dans un mode standard très rapide à interpréter (machine
ou être humain), rien ne vaut XSL pour les extraire et en faire des pages (X)HTML, PDF ou bien d’autres, mais surtout arrêtons de
l’ouvrir quand on ne connait pas.
Et s’il existe des ménagères qui font leurs "petits" sites en HTML, aucune norme ne les empêchera de continuer, mais rien ne devrait s’opposer non plus à ce qu’elles fassent des "petits" sites en XHTML.
XHTML se borne à respecter la syntaxe XML (2 règles simples pour le balisage. Point), il n’en nécessite aucune autre connaissance.
J’étais déjà passé (février 2004) dans cet article et ses commentaires où je m’étais immiscé. Je suis étonné que son auteur l’ait
conservé en ligne - d’autant qu’à moins d’être définitivement devenu résistant au changement, il a dû se rendre compte entre-temps de l’incongruité de ses arguments.
Je reviens donc avec 2 petites ambitions : apporter une preuve (ou un fort indice) de la validité de la démarche de respecter les
standards W3C dans un petit exemple, et encourager les concepteurs de sites à connaître, utiliser et apprécier les standards pour ce qu’ils peuvent nous apporter.
Je m’adresse plus en réalité aux commentaires qui disaient "Ouais t’as raison Arno, soyons des rebelles..." en propageant l’idée erronée qu’XHTML était plus compliqué qu’HTML (donc réservé à une élite), ou que le couple XHTML/CSS (càd la séparation la plus complète possible entre contenu et présentation) aboutissait dans des sites graphiquement pauvres, forcément moches...
Un site au design contemporain. On aime ou pas, mais on sent qu’il y a une vraie direction artistique et que ce n’est pas l’oeuvre d’un seul freak codeur qui a son "XML Reference" à côté du clavier.
Clic-droit dans la page (voir le code source...) et vous verrez du code XHTML. Pour ceux qui auraient fait la même chose sur la homepage d’Uzine (qui est encore très propre), on comprend très vite que XHTML est plus simple que HTML... c’est son but même
: épurer HTML des codes de formatage lourdingue pour le renvoyer au fichier CSS où le travail et la maintenance purement
"présentationnelle" et graphique peut se faire dans une meilleure lisibilité.
Si vous pouvez désactiver les styles (avec Firefox par exemple) ou en prévisualisant l’impression (là c’est pas beau, mais ils n’ont pas fait l’effort d’une feuille de style spéciale "print"), vous comprendrez ce que veux dire vraiment séparation entre contenu et présentation.
XHTML n’est qu’une norme qui formalise déjà des recommandations valables pour HTML 4.01... c’est pourquoi la différence est bien plus petite qu’on le sous-entend dans tout cet article (donc passage facile de l’un à l’autre) mais qui offre des avantages peu nombreux mais bien réels (donc c’est le moment de s’y mettre) :
1/ Mode de rendu plus rapide grâce au DOCTYPE ! qui fait passer le navigateur en mode de rendu "standards" ;
2/ Validation plus complète (on peut vivre avec à des sites non valides, mais un outil de diagnostique nous aide à savoir ce qu’on
fait).
3/ Compatibilité ascendante : c’est le plus passionnant. XHTML est le standard des "netdevices" pour l’HTML, càd que tous ces
téléphones portables, PDA et autres futurs appareils reliés à Internet (qu’on ne vienne pas me dire que c’est un petit marché ou qu’il est en recul...) vont lire XHTML mais pas HTML 4.01, car leurs navigateurs ne disposent généralement pas de la puissance
mémoire nécessaire à l’interprétation/correction automatique des erreurs qu’ont nos navigateurs en mode "quirk/dégradé". Exemple : un grand site portail à la charte graphique colorée (interface flexible à 100%) dans Explorer ou Firefox, un mode dégradé sans ascenceurs sur le petit écran d’un PDA, des pages qui s’impriment avec un minimum de couleurs et sans les informations écran colonne de menu à gauche par exemple) ou avec des sauts de page logiques... J’ai essayé, on peut. Un seul contenu : XHTML, plusieurs styles CSS en fonction du média de sortie.
Vous connaissez Zengarden... j’en connais plein d’autres (de + en +, si si), des sites beaux et "valides" (ou presque - en tout cas
l’effort et les résultats sont là).
Grâce aux CSS, on peut faire beaucoup plus qu’avec ces tableaux imbriqués lourdingues et images découpées au pixel. CSS n’est
pas parfait, CSS2 n’est pas supporté à 100% par tous... mais aujourd’hui on peut vraiment faire des sites super pro avec un peu de méthode.
Qui plus est, le positionnement CSS nous apprend à envisager des pages plus intéressantes, plus adaptées au web (interface flexible, blocs flottants...) que la grille d’un tableau, paradigme du graphisme prépresse figé.
Et donc, j’encourage tout le monde à lire le bouquin de Zeldman "designing with web standards" (il vient de sortir en français :
http://standblog.org/blog/2005/04/07/93114105-version-francaise-du-livre-de-zeldman-designing-with-web-standards), je pense que tout concepteur sera tenté d’essayer, se cassera un peu la gueule avec du positionnement CSS avant d’en piger les limites actuelles (limites de compatibilité, avec IE5/mac par exemple), et retrouvera vite l’usage idéal (pour lui) des CSS.
Un site full-CSS demande des connaissances, comme d’ailleurs un site en tableaux pour celui qui n’en a jamais fait. Mais l’énorme
avantage est l’économie d’échelle. J’ai pris des semaines à mettre au point mon premier site parfaitement valide (je parle de conception codage XHTML front/end, les CSS, l’infographie et un de XSL... le reste c’est le boulot des développeurs du CMS
derrière et de leur XML auquel je ne touche pas). Le deuxième aura pris 4 jours, le dernier 2 jours... Quant au premier cité, on
prépare une nouvelle version (nouvelles rubriques, nouveau layout, nouvelles idées sur base des feedback utilisateurs) et c’est d’une facilité... Ce qui est bien conçu en XHTML/CSS peut évoluer en un tournemain !
Faites l’effort de comprendre de quoi vous parlez avant de parler de XHTML, de grâce !
La rhétorique de l’article d’Arno est basée sur un déni de l’organisme W3C (La prétendue mainmise du géant de Redmond est presque sous-entendue), et l’idée totalement fausse qu’HTML est un standard "du peuple", libre de tout auteur, norme, ce qui ferait sa force. On peut même penser qu’on va être obligé de faire bientôt des sites en XML et XSL, ce qui est très compliqué, bla bla bla ! Ne mélangeons pas tout : rien ne vaut XML pour stocker des données dans un mode standard très rapide à interpréter (machine
ou être humain), rien ne vaut XSL pour les extraire et en faire des pages (X)HTML, PDF ou bien d’autres, mais surtout arrêtons de
l’ouvrir quand on ne connait pas.
Et s’il existe des ménagères qui font leurs "petits" sites en HTML, aucune norme ne les empêchera de continuer, mais rien ne devrait s’opposer non plus à ce qu’elles fassent des "petits" sites en XHTML.
XHTML se borne à respecter la syntaxe XML (2 règles simples pour le balisage. Point), il n’en nécessite aucune autre connaissance.