Quel est l'avantage du code valide ?

Bonjour à tous, malgré ce titre vendredÿ-esque, je commence à me demander l'intérêt de produire du code valide...

Depuis plusieurs jours, je m'amuse à coder un petit bot IRC qui entre autre valide des pages web et, pour le fun, conserve les pages avec le plus d'erreur pour faire un Top du pire)...

Et là c'est le drame, une page vidéo Youtube est 2ème du classement Css avec 752 erreurs (en premier, http://yvettesbridalformal.com/ pas loin devant c'est pour dire) et dans la catégorie Html, amazon est en tête avec 587 erreurs...

Ma question est donc : Pourquoi ces gros sites qui font pas mal d'argent sur internet semble se foutre autant de la validité de leur code, alors qu'ils sont très pointilleux sur d'autres sujets comme les performances ou l'utilisabilité de leurs pages...

Peut être qu'en fait produire du code valide n'a pas spécialement d'avantages, peut être que ça n'apporte rien de particulier, ou alors que ça ne vaut pas le coup de prendre le temps de s'y attacher. Franchement j'en sais rien mais je me demande.

Pour ma part, je fais en sorte de produire du code valide autant que faire se peut, accessible si possible, enfin plein de compromis de partout, mais au moins je fais attention, mais je ne saurai dire pourquoi... Parce que c'est comme ça. Peut être qu'au final il n'y a pas de raison et que le plus simple c'est de se contenter de ce qui passe dans les navigateurs et pas dans le validator...

J'en appelle à vos avis, je m'égare vers le côté obscur, mais franchement tous ces gros sites (notamenet la home de google) pleins d'erreurs me laissent vraiment dubitatif quant à l'intérêt réel du code valid si ce n'est pas mettre une petite image en bas de page "valid html & css"...

Bonjour,

J'aimerais avoir un peu plus de temps pour débattre des avantages d'un code valide, mais hélas, je dois partir bientôt pour le boulot. En attendant, voici un point de départ.

À la base il y a le fait qu'il est possible de faire un site fonctionnel avec du code pas terrible. Surtout si tu ne fais rien de très complexe côté front-end, et que tu as du temps à dépenser en tests et en corrections diverses (quitte à faire du bon vieux browser sniffing). Le code ne sera pas optimal, et on perd sans doute de l'argent à faire aujourd'hui un site sur cette base, mais perdre de l'argent sur un poste de dépense marginal (le développement front-end) ça ne mets pas en danger un business.

Pour expliquer ce qu'on trouve sur certains grands sites, trois pistes:
1. L'incompétence. Ouais, même chez Google ou Amazon ou qui on veut. Parfois aussi la rigidité des outils en place, des processus, etc.
2. Un code ancien. Quand tu as un site critique et que le moindre changement peut te faire perdre des ventes, tu ne vas pas modifier un code sale mais fonctionnel juste pour le plaisir de faire un code propre.
3. Une culture d'entreprise qui s'en fout, ou promeut des pratiques contestables avec des arguments parfois pertinents, parfois infondés.

Pour Google certains ont parfois avancé des arguments du type «ils économisent sur le moindre octet donc ils préfèrent un code invalide à un code un poil plus long». Foutaises. La vraie raison c'est que les codeurs et ingénieurs de Google ont une culture de merde en la matière. Ils vont prétexter gagner des picosecondes par ces micro-optimisations dérisoires, et à côté de ça ils vont charger 40ko de JS pour un Google Doodle qui permet de jouer à Pac-Man. Je rigole.

Pour Amazon, ils existent depuis des lustres, avaient des pages en mode Quirks + tableaux au départ, et ils ne font évoluer le design et le code de leurs pages que de manière incrémentale. Je ne sais pas si leur code est pas valide mais sensé et robuste ou alors pas valide, mal fichu, bourré de rustines et ça marche uniquement parce qu'ils ont des ressources à mettre dans des tas de tests techniques qui permettent de repérer où il faut mettre des rustines. Il faudrait analyser en détail ou demander à des gens chez eux qui connaissent un peu leurs processus et leur culture technique d'entreprise.

HammHetfield a écrit :
Peut être qu'au final il n'y a pas de raison et que le plus simple c'est de se contenter de ce qui passe dans les navigateurs et pas dans le validator...

Bien sûr, on ne rappellera jamais assez que la validation est un outil, pas une fin en soi.
Quand je vois une page de site complexe avec 30 ou 50 erreurs de validation, ça ne me choque pas. Est-ce qu'on corriger des bugs présents ou prévenir des bugs futurs en corrigeant une partie de ces erreurs de validation? Sans doute. Est-ce que c'est l'optimisation prioritaire à faire sur la page ou le site en question? Pas forcément.
Modifié par fvsch (12 Apr 2011 - 15:21)

Bonjour,

une possibilité est qu'ils ont des ressources infinies, que leur code s'affiche nickel sur 99,9% des navigateurs même très vieux ou très exotique et qu'à chaque nouveau navigateur, ils patchent pour que ça fonctionne puis recommencent au prochain nouveau navigateur. Par contre ils se servent pas de leurs ressources infinies pour avoir une base saine, qui peut-être aurait une compatibilité légèrement plus faible.
Je sais pas comment travaille Amazon niveau intégration mais pour Google, j'imagine sans peine que chacun est responsable de son projet sans nécessairement un intégrateur dans l'équipe. On t'apprend pas les CSS à Stanford ou autre prestigieuse université américaine. Ces développeurs sont très forts dans leur domaine, vont produire une beta convaincante qui peut tourner sur les serveurs Google (c'est-à-dire encaisser le choc de passer de 10 utilisateurs à un million ou cent million en suivant les exigences très pointilleuses pour scaler) mais niveau HTML/CSS hum bah c'est une beta. Et 3 ans plus tard c'est toujours le même code côté client et tout le monde s'en fout, le produit a du succès.
Modifié par Felipe (12 Apr 2011 - 17:21)

Felipe a écrit :
une base saine, qui peut-être aurait une compatibilité légèrement plus faible

Pour préciser: une base saine (sans multiples correctifs) aurait une compatibilité plus faible avec les anciens navigateurs, mais réduirait fortement les correctifs à faire à chaque sortie de nouvelles versions des navigateurs.

Ouai donc au final, comme je le pensais, du code valide, ou invalide dans une mesure raisonnable, c'est bien, sauf pour certains qui ont les moyens de s'en foutre ou pour qui c'est trop risqué de tout changer...

Vous m'avez ramené du côté clair de la Force.

Parfois aussi tu utilises des fonctionnalités qui sont bien supportées par les navigateurs mais qui ne sont pas intégrées au standard (d'ailleurs plein de trucs qui fonctionnent bien depuis des lustres ne sont pas valides en XHTML1/HTML4 mais sont maintenant valides en HTML5).

Selon une étude américaine, les intégrateurs qui font des sites valides ont 79% plus de succès auprès de la gent féminine, et comme disait Jacques Séguela : si à 50 ans on n'a pas fait de site valide, on a raté sa vie.

Plus sérieusement, en tant qu'integrateur, mon principal avantage de produire du code valide est d'être sur de baser mon intégration sur qqch de correct et stable : j'ai de meilleure chance d'éviter des erreurs de rendu si mon code est correctement formé.

Surtout que sur un site récent, il va y avoir :
- la surcouche Jquery
- la version smartphone et print

Donc autant que la structure soit aussi béton que possible, ça évite les mauvaises surprises.
Après il y a erreur de validation et erreur de validation : un br auquel il manque un slash est moins grave qu'une div non fermée amha.

Bonjour,

Par code valide , il faut penser HTML en premier lieu et bien évidement : doctype

Un exemple récent parmi d'autre : http://forum.alsacreations.com/topic-4-55167-1.html
(un dessin c'est toujours mieux , et il y en a d'autres sur le forum )

Une structure valide et cohérente permet d'appliquer styles et JavaScript de façon optimale (ainsi que pour d'autres aspects). DOM !

Un code valide ne peut rien au défaut d'un navigateur, mais un code invalide a toute les chances de les amplifier et en génèrer d'autre.

Vouloir corriger un defaut de style ou s'acharner sur un script qui bizarrement ne marche plus est une perte de temps ou peine perdu si le document à la base ne tient pas la route coté standard .

Cordialement, GC