la personne utilisera un moteur tout fait pour faire un blog, un wiki ou autre (voir un site tout fait lui proposant de hoster son blog).
Jusqu'au jour où tu veux personnaliser la mise en page, et là il faut sortir l'éditeur wysiwyg (si le système de templates le permet) ou faire du code à la main.
Aujourd'hui le contexte est radicalement différent et maintenir un base de code énorme et lente dans les navigateur rien que pour essayer de corriger les erreurs automatiquement
Il ne s'agit pas forcément de "corriger les erreurs" (ce qui effectivement n'a pas de sens) mais au moins d'être capable de les ignorer pour s'intéresser à ce qui reste extractible. Au lieu de s'arrêter en sortant une erreur fatale. Or en HTML le texte du document reste toujours extractible, donc autant en faire quelque chose.
Il faut se réveiller : HTML n'est pas le seul domaine où l'on cherche à ne pas s'arrêter aux erreurs. Dans beaucoup de normes IETF, il est demandé aux implémentations d'ignorer les constructions qu'elles ne comprennent pas (tel en-tête inconnu dans le protocole, par exemple). Si on impose la validité d'un document XML (pas seulement son caractère bien formé), on devient d'un coup beaucoup plus strict que l'IETF.
Il y a sans doute peu de standards non-triviaux qui sont respectés à 100% par les principaux acteurs, même ceux de bonne foi. Récemment gcc avait un bug d'ABI C++. On peut certainement multiplier les exemples.
[^] # Re: IE, HTML à la papa et XHTML
Posté par Antoine . En réponse à la dépêche Tim Berners-Lee évoque l'avenir d'(X)HTML. Évalué à 3.
Jusqu'au jour où tu veux personnaliser la mise en page, et là il faut sortir l'éditeur wysiwyg (si le système de templates le permet) ou faire du code à la main.
Aujourd'hui le contexte est radicalement différent et maintenir un base de code énorme et lente dans les navigateur rien que pour essayer de corriger les erreurs automatiquement
Il ne s'agit pas forcément de "corriger les erreurs" (ce qui effectivement n'a pas de sens) mais au moins d'être capable de les ignorer pour s'intéresser à ce qui reste extractible. Au lieu de s'arrêter en sortant une erreur fatale. Or en HTML le texte du document reste toujours extractible, donc autant en faire quelque chose.
Il faut se réveiller : HTML n'est pas le seul domaine où l'on cherche à ne pas s'arrêter aux erreurs. Dans beaucoup de normes IETF, il est demandé aux implémentations d'ignorer les constructions qu'elles ne comprennent pas (tel en-tête inconnu dans le protocole, par exemple). Si on impose la validité d'un document XML (pas seulement son caractère bien formé), on devient d'un coup beaucoup plus strict que l'IETF.
Il y a sans doute peu de standards non-triviaux qui sont respectés à 100% par les principaux acteurs, même ceux de bonne foi. Récemment gcc avait un bug d'ABI C++. On peut certainement multiplier les exemples.