Il était écrit que la prochaine version de SPIP n'allait pas sortir avec un validateur limité. Je suis nul de ne pas y avoir pensé avant: pour vérifier les rares règles plus complexes que celle de la forme {{{(A|B|C|)*}}} il suffit de les compiler en une RegExp (ce qu'elles sont à peu près, il faut juste supprimer les virgules et normaliser l'usage des espaces) et appliquer celle-ci sur la suite des noms de balises rencontrées séparées par des espaces. Ainsi, la règle:
{{{
<!ELEMENT table
     (caption?, (col*|colgroup*), thead?, tfoot?, (tbody+|tr+))>
}}}
se compile en 
{{{
/^((caption )?((col )*|(colgroup )*)(thead )?(tfoot )?((tbody )+|(tr )+))$/
}}}
appliquer preg_match dessus et, par exemple, "tr caption tr ", permettra e refuser cette construction ce qui n'était pas le cas auparavant.

La règle sur head, que la DTD énonce en 2 coups:
{{{
<!ENTITY % head.misc "(script|style|meta|link|object|isindex)*">

<!ELEMENT head (%head.misc;,
     ((title, %head.misc;, (base, %head.misc;)?) |
      (base, %head.misc;, (title, %head.misc;))))>
}}}
est compilée en:
{{{
/^(((script )|(style )|(meta )|(link )|(object ))*(((title )((script )|(style )|(meta )|(link )|(object ))*((base )((script )|(style )|(meta )|(link )|(object ))*)?)|((base )((script )|(style )|(meta )|(link )|(object ))*((title )((script )|(style )|(meta )|(link )|(object ))*))))$/
}}}
ce qui assure qu'il y aura une et une seule balise Title et au plus une balise Base.

Seul défaut de cette stratégie hyper efficace: le message d'erreur mentionnera comme ligne fautive celle contenant la balise fermant la suite problématique, sans plus de précision. Cela dit ce n'est de toutes façons pas possible d'etre plus précis dans le cas général.

Suite de [8144]: le validateur verifie que toutes les balises devant etre non vides ne le sont pas (incomplet, mais suffisant pour XHTML 1.0). Et un pétouille non XML

Correction de #718 (fct indéfinie au chgt de rubrique de brèves), meilleur icone pour le validateur et Log dans celui-ci.

Suite de [8144]: le validateur vérifie que les balises vides sont vides (input, link etc) et que certaines non vides ne le sont pas (select et tr, mais pas table, c'est à améliorer encore)

Extension de la fonction sous_repertoire, qui accepte un appel de forme {{{sous_repertoire("d/f")}}} comme équivalent à {{{sous_repertoire("d", "f")}}}. Du coup, disparition d'une incohérence: la non utilisation de la constante _DIR_SKELS lors de la compilation d'un squelette.

Cet appel est aussi utilisé pour la création du répertoire de cache des DTD, celui-ci s'annonçant comme bien rempli à l'avenir.

Suite à [8184]: le validateur expanse les entités à tous les coins de DTD (mais ce serait bien d'en avoir une grammaire fiable).

{{{
for i in $(grep -l "<td width='.*%.*>" */*p)
do
	sed "s/<td width='/<td style='width: /" $i > x;
	mv x $i;
done
}}}

Suite de [8184]: permettre la surcharge de la phase finale du validateur. Et un cadre refermé trop tard.

Suite de [8144]: on charge maintenant les DTD appelées à l'intérieur d'une DTD, ce qui permet en particulier de charger celle définissant les entités symbol, special et lat1 réféncées dans la DTD XHTML

Suite à cela et à [8179] le validateur peut maintenant dénoncer des entités présentes dans la page et non déclarées dans la DTD et ses inclusions

Suite de [8149]: le validateur est plus modulaire et peut s'étendre par simple ajout de fonctions. Si une DTD contient un nouveau symbole S de type d'attributs (i.e. un symbole utilisé dans le meme contexte que ID, IDREF etc), le validateur appellera automatiquement la fonction validerAttribut_S censée vérifier que la valeur d'attribut est conforme à la rèlge associée à ce symbole.

Suite de [8090]: l'erreur de conception de SAX est à présent systématiquement contournée sans plus vérifier que la DTD HTMLSymbol était référencée, ce qui n'était de toutes façons qu'un pis aller. Au cas où cette transformation des entités dans le charset déclaré serait malencontreuse, il suffira de surcharger le validateur par une variante n'appelant pas html2unicode.

Suite de [8129]: vérifier qu'un ID est alphanumérique, et traiter le cas IDREFS en plus du cas IDREF de [8130]. Utile pour l'attribut {{{headers}}} de {{{th}}}.

Debut de conformité XHTML pour le mode accessibilité, alias spip_display=4, alias ecrire/oo (mais c'est pas fini). Et réapparition des numéros de lignes fautivees pour les balises illégitmées.

Retour du bon controle des idref (désolé Cédric, les objets en PHP c'est encore pire qu'ailleurs). Et donner la liste des attributs licites, mais au survol de la souris parce dit des dizaines de fois c'est insupportable tellement il y en a.

Simplification de l'interface à l'indenteur/validateur, d'une part pour que l'indenteur ne s'encombre pas des données du validateur, et pour qu'on puisse écrire des validateur meilleurs que celui du W3C en récupérant un maximum de code. Il y a peu de programmation objet, mais entre les incompatibilités de PHP4 et PHP5 sur la question, et la folie de la sémantique de référence dans les deux cas, c'est minimal.

A présent, il faut affecter dans mes_options.php une seule variable, qui sera le nom passé à charger_fonction à la fin de ecrire/index.php:

{{{
$GLOBALS['transformer_xml'] = 'indenter_xml';  // pour l'indenteur XML
$GLOBALS['transformer_xml'] = 'valider_xml';  // pour le validateur par DTD
}}}

Les spécifications de [8136] n'auront donc vécu que le temps de 13 dépots.

Afficher le nombre d'erreurs de validation, et des liens pour aller en debut et en fin du tableau des erreurs. Et faire des lignes html plus courtes.

En revanche, si le père est connu mais ne reconnait pas cet élément comme fils, on donne la liste des pères possibles. Au passage, on voit tout ceux qui sont effectivement acceptés par la DTD, le validateur du W3C ne montrant que ceux politiquement corrects. Il faut les voir pour le croire.

Suite à mon ignorance de la triple accolade dans le Wiki lors des dépots [8061] et [8067], je redonne les globales qu'il faut affecter dans mes_options.php pour utiliser ce validateur (et, en cas de réussite, aussi indenteur fiable depuique que [8090] a trouvé comment contourner le bug de conception de SAX):

{{{
$GLOBALS['xml_indent'] = 'sax'; // pour seulement le validateur XML
$GLOBALS['xml_validation'] = true; // pour le validateur selon la DTD
}}}

et je mets en commentaire dans inc/utils ligne 994 de quoi essayer XHTML 1.0 strict pour voir ce que ça donne  (pour la non stricte, on ne voit plus grand chose maintenant).

Présentation synthétique des erreurs de validation, avec liens du texte de l'erreur vers la ligne fautive et réciproquement (avec une ambiguité si une meme ligne a plusieurs erreurs, il y a intéret à faire des lignes courtes). Et on ne se plaint plus d'attributs inconnus d'une balise inconnue.

A signaler que le validateur du W3C dénonce plusieurs occurrences d'une meme erreur en plusieurs endroits, sauf si elles se suivent dans la liste des erreurs. Vachement clair. Et pour continuer le feuilleton [8129], sachez que la DTD xhtml dite scricte (http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd) trouve ceci valide:

{{{<form action='/'><div><form action='/'></form></div></form>}}}

Au moins la non stricte avait l'honneteté de le signaler en commentaire.
Ils sont décidément très forts les grammairiens du W3C.

Validateur intégré: dénoncer les IDREF inconnus (i.e. les attributs For de la balise Label qui n'ont pas pour valeur celle d'un attribut Id dans la page)

Dénonciation des ID déclarés plusieurs fois dans une meme page, sur la base du symbole ID indiqué dans la DTD comme type d'un attribut (en l'occurrence, uniquement "id"). 

Les seules différences avec la validation officielle résident donc dans quelques successions pathologiques non signalées, comme Body avant Head et autre improbabilités. De toutes façons, quand on lit dans les DTD de xhtml (meme la stricte: thttp://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd):

{{{
<!--
  Each label must not contain more than ONE field
  Label elements shouldn't be nested.
-->
<!ELEMENT label %Inline;>
<!ATTLIST label
  %attrs;
  for         IDREF          #IMPLIED
  accesskey   %Character;    #IMPLIED
  onfocus     %Script;       #IMPLIED
  onblur      %Script;       #IMPLIED
  >
}}}

on se dit que l'officiel n'est pas un gage de sérieux, et leur validateur se garde bien de corriger la paresse de la spécification par une implémentation respectant le commentaire, puisqu'il considère ceci comme valide:

{{{
<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 Strict//EN' 
'http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd'
><html lang='fr' dir='ltr'>
<head>
<title></title>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
</head>
<body>
<p id='x'><label for='x'><label>
<input />
label+label=les moches
<input />
</label></label></p>
</body>
</html>
}}}

''Note: The Validator XML support has some limitations.'': oui, et ses grammaires aussi...

Quand la DTD donne une RegExp comme valeur admise pour l'attribut, l'appliquer sur celui-ci à la validation. Et petite amélioration de présentation.

Suite de [8061]: contournement de la faute de conception de SAX (entité dans un attribut non distinguable des autres contextes) en remplaçant les entités HTML de lettres accentuées (mais pas les autres pour sécuriser les valeurs d'attributs) par leur valeur effective dans le charset du site. Cette opération n'est effectué que si la DTD de la page contient l'entité HTMLSymbol (definie en http://www.w3.org/TR/1999/REC-html401-19991224/HTMLsymbol.ent mais elle n'est pas chargée). L'analyse de la DTD a permis aussi d'améliorer l'indenteur, qui abrège <bal attributs></bal> en <bal attributs /> lorsque la DTD indique que l'ensemble des fils de la balise est à EMPTY (soit: base, meta, link, hr, br, basefont, param, img, area, input, isindex, col).

En résumé, l'indenteur intégré est à présent parfaitement opérationnel, et le validateur intégré à peine moins laxiste que l'officiel du W3C.

Sans aller jusqu'à une analyse syntaxique digne d'un vrai validateur, le petit validateur XML controle quand meme si une balise est une fille légitime de sa mère. Ca ne controle pas l'ordre (par exemple mettre Body avant Head ne sera pas dénoncé) mais ça controle bien la hiérarchie (Div après P interdit; P après Div accepté etc).

Le temps de calcul devenant perceptible, toute cette validation est désormais controlé par la globale:
$GLOBALS['xml_validation']= 'sax';
à mettre dans mes_options.php.

Placer le nom du répertoire à la fois par PHP et par JS au cas où celui-ci ne marcherait pas. Et un peu de conformité XHTML grace au mini-validateur qui lui) même améliore sa présentation.

Le petit validateur construit autour de SAX va à présent chercher la DTD indiqué par la page des espaces public ou privé, à analyser, et vérifie que toutes les balises de la page sont présentes dans la DTD, et que tous les attributs figurant dans une balise sont autorisés par la DTD.

Attention, cette analyse est seulement lexicale, pas syntaxique: on ne vérifie pas qu'un attribut obligatoire est présent, ni que la succession des balises est conforme (ça laisse passer des Form imbriqués par exemple). De plus, les entités déclarées externes ne sont pas traitées. Ca permet néanmoins de répérer les fautes les plus grossières sans passer par les validateurs externes complets, qui n'ont pas accès par URL aux pages calculées par les scripts de l'espace privé faute de Login. Cette vérification s'obtient en mettant:
$GLOBALS['xml_indent'] = 'sax';
dans mes_options.php.

A signaler à propos de ce validateur/indenteur, un bug non résolu mais à présent identifié. Le modèle SAX appelle une fonction définissable par le programmeur (le ''handler'', en français le ''preneur'') à chaque rencontre d'un lexème, en particulier les entités HTML comme "& eacute ;" etc. Ces entités se rencontrent dans les éléments Text et dans les attributs, ce qui provoque l'appel du preneur dans 2 contextes différents sans qu'il puisse les distinguer. Il s'ensuit que l'indenteur mettra à tort dans la dernière zone Texte les entités HTML (typiquement les lettres accentuées) présentes dans les attributs de la balise suivant cette zone. Si quelqu'un a une solution pour contourner ce bug de conception de SAX, je suis ... preneur.