Je suis dans une position un peu délicate dans toute cette histoire à propos des standards, car je suis pris entre deux feux. D'une part Luc est un ami que je respecte et que j'admire, de l'autre, j'ai fait la promotion des standards depuis plus de 4 ans. Enfin, je sais plus des dessous de l'affaire que la plupart de mes collègues pro-standards. Car dans cette affaire, le contexte est essentiel, et je ne sais pas dans quelle mesure je peux rendre public ce que je sais. Heureusement, Luc s'est longuement expliqué dans un commentaire sur Embruns.net, que je vous encourage à lire (merci à Karl pour avoir calmé le débat, équipé de sa casquette du W3C). Voici un extrait commenté et caviardé par votre serviteur en vue de le rendre plus concis et plus clair. J'ai donc retiré beaucoup d'incises, espérant respecter la pensée de Luc tout en allant droit au but :

Le problème auquel j'ai été confronté (...) est que si d'un côté l'idée des standards est bien installée, de l'autre la conception du web dans la tête de certains décideurs, est restée celle du petit truc qu'on fait vite facilement avec des outils qui pondent de la page.

Au fond ce ne serait pas grave si cela (dans mon cas précis) n'avait pas de conséquence sur le temps alloué. L'objet de mon post (...) était (que) lorsqu'on place quelqu'un dans des conditions de bricolage, l'implémentation des standards devient un enfer et à tout prendre, le vilain web à l'ancienne (basé sur la notion de page et pas celle de site) est presque plus jouable...

Ce que j'ai osé dire, le tabou que j'ai osé citer c'est que ce serait bien maintenant que les standards sont (ou commencent à être) acceptés, de faire la même promotion pour que des gens ne se retrouvent pas dans des conditions de bricolage, et qu'il soit communément admis qu'un projet web conforme est un vrai projet informatique et pas une vague étape de design vite fait.

Luc a tout à fait raison la-dessus ! Dans le projet qu'il décrit, les standards étaient un pré-requis (ce qui est une bonne chose), mais l'approche était incompatible, car on comptait coder les pages au fur et à mesure, sans réflexion préalable, trouvant le consensus au fur et à mesure de la rédaction du site.

Ma sensation est la suivante :

Avant : à l'époque de ce que j'ai appelé le HTML (et qu'il faut lire « comme à l'époque ou l'unité en HTML était la page et ou donc les problèmes étaient limités à une page ») il était possible de bricoler. C'est mal, c'est tout ce qu'on veut, mais vraiment ça s'est fait beaucoup.

Oh que oui...

Aujourd'hui : si on veut implémenter intelligemment les standards du Web (lire XHTML et CSS) l'unité au niveau de CSS n'est plus la page mais le site.

Plutôt que de dire "XHTML et CSS", je préfère parler de séparation Structure/présentation (après, que ça soit HTML 4.01 Strict ou XHTML 1.0 Strict, c'est quasiment un détail). Mais sinon, je suis d'accord avec Luc.

La conséquence c'est que le bricolage n'est plus permis et qu'un projet qui se tient doit (...) comporter les mêmes phases grosso modo qu'un projet informatique standard et surtout, ce dernier point est très important pour moi, une phase de réflexion qui ne soit pas basée sur la version que va être développée mais sur la structure globale du site.

Oui, oui et oui ! C'est même l'un des plus gros avantages des standards (quand on les aborde au sens "spération structure/présentation") : ils permettent une approche plus rationelle, (oserais-je écrire "industrielle" ?) du développement Web. On quitte le domaine de la bidouille pour en faire une discipline que d'aucuns trouveront plus "noble". Mais ça n'est pas la noblesse qui m'intéresse, c'est plutôt le potentiel qui va avec.

Si ce dernier point n'est pas respecté (NdT : "une phase de réflexion sur la structure globale du site"), la promesse d'une modification « facile » et évidente de la présentation n'est pas tenable (ou à minima ne le sera que difficilement).

En fait, on prend une technologie et on l'utilise à rebrousse-poils. C'est possible, mais forcément moins efficace. On peut bien sûr "surspécifier" les éléments à grands renforts d'id et de class, mais c'est contraire à l'esprit de la technologie.

Je pense donc qu'à côté de la promotion de standards, il faudrait faire évoluer la culture, la vision de ce qu'est le développement web (et ce développement web, s'il a une mauvaise image c'est aussi de sa faute, il est vrai qu'il s'est fait beaucoup de bricolages dans les développements web), changer donc cette culture pour que les commanditaires, ne se contentent pas de lancer « on veut des standards » comme s'il s'agissait d'une formule magique, mais « on va lancer un projet dans des conditions qui nous permettent de mettre en œuvre intelligemment les standards ».. ce qui est TRES différent.

Amen. Tout est dit.

La doc. Pour ce qui est de la doc c'est simple, le CSS est victime de ce dont le HTML a été victime à ses débuts : l'incompatibilité des navigateurs.

C'est bien pour ça que ça fait des années que je fais la promotion des standards aussi auprès de Microsoft, et que je soutiens le projet Mozilla. Microsoft se bouge aujourd'hui car Firefox l'y oblige !

Il suffit de voir le nombre de bricolages pour faire marcher IE qu'on peut trouver à droite et à gauche. Le projet sur lequel je travaille actuellement s'affiche impeccablement sous firefox et dans une certaine mesure Safari sur Mac, mais horriblement avec MIE et pour régler ça, c'est un enfer.

Oui, mais c'est quelque chose qui s'apprend. Dans le cas où on découvre ça dans un projet, on apprend même à la dure... Mais l'essentiels des problèmes de compatibilité IE peuvent être contournés avec quelques bonnes habitudes (hacks - un article Openweb est prévu sur ce sujet-, utilisation ad-hoc du box model, etc.)

Ca n'est pas la faute du W3C, ce n'est la faute de personne mais c'est comme ça.

Euh, sans vouloir tirer sur l'ambulance, on peut quand même pudiquement affirmer que c'est la faute de l'acteur dominant qui a contribuer à édicter les standards du W3C et a finalement décidé d'abandonner le développement de son navigateur. On peut aussi se réjouir des promesses de changement.

Je trouve en, revanche que les formulations en matière de doc sont beaucoup trop axées sur le sentencieux verbeux et pas assez sur le concret (dire que c'est super ce n'est pas suffisant, ce qui est intéressant c'est le comment ça marche).

C'est effectivement le reproche qu'on pourrait faire au bouquin de Zeldman, qui est orienté sur sa première moitié vers les décideurs et la théorie. Par contre, ça n'est pas le cas des livres d'Eric Meyer ni de celui de Raphaël Goetter.

(...) Lorsqu'on travaille sur un gros projet avec plein de class et autres id, ce qui manque (ce qui ME manque) c'est un système qui gérerait ces éléments, qui me permettrait de trouver d'un clic « quelle est la class qui gère la position du div de la page X », qui me permettrait de faire des modifs en m'indiquant à la volée que cette modif est incompatible avec le navigateur X ou contradictoire avec la class Y etc..

Le DOM Inspector de Firefox fait cela très bien, mais n'indique pas, il est vrai, la compatibilité avec les navigateurs, ce qui est plutôt l'apanage d'outils comme TopStyle (sous Windows).

(...) Concrètement j'ai essayé Dreamweaver et NVU (...) et j'ai fini à la main (BBEdit/HomeSite)

L'éditeur de texte est probablement l'outil le plus utilisé par les développeurs de sites conformes aux standards. Le XHTML s'accommode très bien de cela, et pour ce qui est des CSS, chacun a sa recette (la Web Developer Toolbar, associé au DOM Inspector est une bonne combinaison à mon sens). L'outil miracle reste à trouver, et c'est bien pour cela que le WaSP a une DreamWeaver Task Force, pour inciter et aider DreamWeaver à améliorer le support des standards.

En conclusion

Il me reste un point à aborder, une précision très importante quant au projet de Luc. J'espère ne pas révéler d'information confidentielle en précisant qu'il s'agit d'un site événementiel conçu avec des délais très courts. Or, la véritable valeur des standards a tendance à se révéler avec le temps : les coûts de mise à jour sont plus faibles, le client est plus autonome, le site est souvent plus vivant et il est plus rapide à télécharger (donc moins coûteux en bande passante). Le prix à payer est une meilleure planification du projet, et des outils qui n'ont pas encore atteint le niveau de maturité d'un DreamWeaver, historiquement très lié à l'ancien mode de développement. De plus, un supplément d'expérience dans le domaine des standards n'aura pas nui ;-)

Enfin, je laisse les commentaires ouverts sur ce billet. J'attends des réflexions de qualité si le coeur vous en dit. Par contre, les jugements de valeurs, les procès d'intention et autres tentative de nourrir les différents trolls seront traquées sans pitié. Relisez-vous avant de répondre !