Si on parle de notre soupe de balise HTML alors le terme "liberté" est basé sur une méprise. Il n'a jamais été question d'interdire. Il s'agit d'inciter ou d'informer dans le cas de nos amateurs passionnés.
Par contre, l'information ça passe aussi par dire que le code est mauvais quand il est mauvais. Ca ne sert à rien de se voiler la face ou de dire "oh il est joli ..." comme si on s'adressait au brouillon d'un enfant de deux ans. Il n'y a pas de mal en tant qu'amateur a faire un code qui ne soit pas très joli, mais il faut l'assumer : il n'est effectivement pas bon. Dire "c'est normal et c'est très bien comme ça" non seulement ne fait pas avancer le shmilblick mais en plus le fait reculer.
Les seuls cas où la validité devrait être une règle (et loin d'être la seule) c'est pour le cas de services publics, ou d'entreprises de services de base. Parce que là ça peut se révéler une nécessité, et que ça devrait être fait par des gens du métier, qui eux n'ont pas de justification à faire n'importe quoi.
Si on parle de XHTML alors la question méritait d'être posée. Les dégat de la soupe de balise interprétée différement partout, faute de savoir quoi en faire, on a déjà les dégats sur le Web.
L'idée c'est de dire que le code xhtml est simple, même quand il est bien fait. Faire du code valide n'est pas complexe. Parti de là si ton amateur il voit que le code ne fonctionne pas dans le navigateur lors des tests, il va tout de suite corriger. Un peu comme si son ciment ne tient pas, il le refera.
Si on part du principe que le XHTML est simple, que faire attention à faire du code valide avec les bons outils n'impose pas une barrière à l'écriture, alors des navigateurs qui bloquent à la première erreur fatale sont une bonne chose. Il n'y a pas d'existant à maintenir, il n'y a pas de pages mal faite dont on risquerait d'empêcher la lecture.
Les erreurs fatales du XHTML permettent justement à notre auteur amateur d'avoir la barrière à l'entrée minimum. Au lieu de produire une page et de devoir la lancer partout pour vérifer que sa soupe n'a pas d'implication différente, il sait que le passage sur un navigateur lui garantira qu'au minimum la structure sera la même partout. Oui, théoriquement c'est ce qui devrait être fait avec un validateur plutot qu'un navigateur mais les gens utilisent le navigateur pour ça, alors évoluons aussi.
Pour le HTML c'est trop tard, justement à cause de l'existant. Pour le XHTML je pense que ce cas là est jouable, sérieusement. Si IE7 était sorti avec un support réel du XHTML tout en restant laxiste, ma position changerait. Ce n'est pas arrivé, et j'espère que ça n'arrivera pas (entendre: s'il supporte le xhtml ça sera en traitant les erreurs fatales comme fatales).
Mais globalement "être laxiste" ce n'est pas si simple que ça. Etre laxiste c'est accepter que la structure "lue" par les navigateurs soient différente sur chaque navigateur, justement parce que par définition un document mal formé ne peut pas toujours être compris sans ambiguité.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Éric (site web personnel) . En réponse à la dépêche Tim Berners-Lee évoque l'avenir d'(X)HTML. Évalué à 8.
Si on parle de notre soupe de balise HTML alors le terme "liberté" est basé sur une méprise. Il n'a jamais été question d'interdire. Il s'agit d'inciter ou d'informer dans le cas de nos amateurs passionnés.
Par contre, l'information ça passe aussi par dire que le code est mauvais quand il est mauvais. Ca ne sert à rien de se voiler la face ou de dire "oh il est joli ..." comme si on s'adressait au brouillon d'un enfant de deux ans. Il n'y a pas de mal en tant qu'amateur a faire un code qui ne soit pas très joli, mais il faut l'assumer : il n'est effectivement pas bon. Dire "c'est normal et c'est très bien comme ça" non seulement ne fait pas avancer le shmilblick mais en plus le fait reculer.
Les seuls cas où la validité devrait être une règle (et loin d'être la seule) c'est pour le cas de services publics, ou d'entreprises de services de base. Parce que là ça peut se révéler une nécessité, et que ça devrait être fait par des gens du métier, qui eux n'ont pas de justification à faire n'importe quoi.
Si on parle de XHTML alors la question méritait d'être posée. Les dégat de la soupe de balise interprétée différement partout, faute de savoir quoi en faire, on a déjà les dégats sur le Web.
L'idée c'est de dire que le code xhtml est simple, même quand il est bien fait. Faire du code valide n'est pas complexe. Parti de là si ton amateur il voit que le code ne fonctionne pas dans le navigateur lors des tests, il va tout de suite corriger. Un peu comme si son ciment ne tient pas, il le refera.
Si on part du principe que le XHTML est simple, que faire attention à faire du code valide avec les bons outils n'impose pas une barrière à l'écriture, alors des navigateurs qui bloquent à la première erreur fatale sont une bonne chose. Il n'y a pas d'existant à maintenir, il n'y a pas de pages mal faite dont on risquerait d'empêcher la lecture.
Les erreurs fatales du XHTML permettent justement à notre auteur amateur d'avoir la barrière à l'entrée minimum. Au lieu de produire une page et de devoir la lancer partout pour vérifer que sa soupe n'a pas d'implication différente, il sait que le passage sur un navigateur lui garantira qu'au minimum la structure sera la même partout. Oui, théoriquement c'est ce qui devrait être fait avec un validateur plutot qu'un navigateur mais les gens utilisent le navigateur pour ça, alors évoluons aussi.
Pour le HTML c'est trop tard, justement à cause de l'existant. Pour le XHTML je pense que ce cas là est jouable, sérieusement. Si IE7 était sorti avec un support réel du XHTML tout en restant laxiste, ma position changerait. Ce n'est pas arrivé, et j'espère que ça n'arrivera pas (entendre: s'il supporte le xhtml ça sera en traitant les erreurs fatales comme fatales).
Mais globalement "être laxiste" ce n'est pas si simple que ça. Etre laxiste c'est accepter que la structure "lue" par les navigateurs soient différente sur chaque navigateur, justement parce que par définition un document mal formé ne peut pas toujours être compris sans ambiguité.