Développement et Technologies
Validation et mode "quirks"
11 janvier 2008
...et mode quoi ?
Valider un document web (en terme de specs un "site web" n'existe pas : rien ne vient le définir comme tel, il s'agit au mieux d'un ensemble de documents réunis sous un nom de domaine unique, et on ne peut donc pas "valider un site") consiste à faire vérifier par un outil d'analyse automatique que la syntaxe de ses balises est correcte. En terme de non-discriminance la validation d'un document est importante : dans l'impossibilité où nous sommes de savoir quels outils de consultation (UA) seront utilisés, la seule chose qu'on puisse faire c'est s'assurer que les informations envoyées seront correctement comprises.
Si dans la communication sociale interhumaine une syntaxe légèrement défaillante (erreurs grammaticales, fautes d'accords et de conjugaisons, construction de propositions bancales, etc.) n'a pas, ou alors très rarement, d'incidences sur l'interlocuteur qui finit toujours par comprendre ce qu'on lui dit parce qu'il y a par derrière une intelligence au travail capable de reconstruire en temps réel le sens du discours, la communication entre machines est nettement moins souple : la moindre erreur syntaxique peut déclencher des contre-sens, des aberrations, des bugs, etc. Quand un UA (navigateur internet ou autre) reçoit un flux de contenus, il se comporte dans un premier temps comme un être humain : il cherche à détecter en quelle langue on lui parle. Pour cette raison, commencer un document par un Doctype correctement renseigné (Html4, xHtml1.0, xHtml1.1, strict ou transitionnal, lang=fr ou autre, etc ...) facilite la négociation de contenu qui va suivre.
Une fois détecté le langage qu'on lui sert, l'UA va d'abord analyser l'ensemble du code servi puis commencer le processus de restitution (un affichage sur écran, par exemple). Pour ce faire, pour chaque balise rencontrée il va aller piocher dans son moteur de rendu pour déterminer quel aspect ou quel emplacement tel ou tel objet balisé aura dans l'espace de restitution final. A partir de là il y a deux solutions : soit l'UA comprend tout ce que le serveur de contenu lui envoie, soit il ne comprend pas tout. S'il comprend tout (document valide), pas de problème particulier ; c'est quand il ne comprend pas tout que ça se complique : l'UA en effet va basculer en "mode quirks", c'est-à -dire que dans le doute (comment dois-je réagir à cette erreur ?) il va tenter d'interpréter au mieux ce qu'il croit percevoir de l'intention de l'auteur. Le processus de traitement d'erreur qui se met alors en route, propre à chaque UA, ne peut ni être anticipé, ni interrompu, ni influencé dans un sens ou un autre. Le processus par lequel "quirks" réagit n'étant soumis à aucune norme ou spécification, il ne relève que de l'idée que son concepteur s'en fait.
Par exemple :
Etant donné que le contenu existant sur le web n'est pas conforme aux standards ou apparaitrait de manière inattendue dans un navigateur respectant les standards [...] en mode quirks l'affichage imite le comportement non standard de Netscape Navigator 4 et Microsoft Internet Explorer pour Windows qui est nécessaire pour ne pas rendre inutilisable le contenu existant sur le Web... [page Mode Quirks de Mozilla (extrait) ]
...qui est un choix comme un autre.
C'est là que les ennuis commencent parce que tout dépend du type d'erreur commise et détectée. Si dans la majorité des cas l'erreur se corrige très naturellement (par exemple une balise <p> non-fermée sera automatiquement refermée, le tout sans aucune incidence sur la restitution finale du contenu), dans certains cas limites l'affichage peut être interrompu (page blanche) ou aberrant (objets déplacés, retaillés, superposés, disparus, inutilisables, etc.) ou carrément bloqué (bug de l'UA).
La structure finale du document (ce qui est affiché à l'écran) n'est donc jamais la structure produite par l'auteur du document : c'est cette structure initiale, réinterprétée soit strictement soit en mode"quirks" par l'UA, qui va constituer l'arbre à partir duquel les objets pourront être directement utilisables, par CSS, par Javascript ou par tout autre langage du web. Le code final est donc intimement dépendant de la part d'interprétation de l'UA : plus elle est importante plus les problèmes sont critiques. Un code valide garantit que l'UA n'aura pas à interpréter les erreurs en "quirks" et garantit donc du même coup une restitution conforme aux attentes de l'auteur. Il garantit également au destinataire une utilisabilité optimale, ce qui devrait à être le but de tout projet web :-)
La citation ci-dessus de la fondation Mozilla - les développeurs de Firefox - nous permet de comprendre pourquoi les 95 ou 96% des sites web sont encore aujourd'hui consultables quoique non-valides : il y a par derrière tout un travail de développements en rétro-compatibilité et toute une équipe d'ingénieurs qui travaille à faire que ça se passe ainsi. Le jour - de plus en plus proche - où les développements de modes "quirks" ou "almost standard" (presque standards) inutiles et coûteux seront arrêtés, vous comprendrez pourquoi s'engager dès aujourd'hui dans des contenus normalisés est réellement l'un des investissements les plus rentables du web.
