Les problèmes résolus
- [corrigé depuis WikiNi 0.4.1] les attributs "onKeyDown" et "onClick" ne sont pas reconnus en XHTML Strict ; il faut écrire en bas de casse : "onkeydown" et "onclick" (facile à résoudre ; à corriger quoi qu'il arrive puisque ça ne mange pas de pain)
- [corrigé depuis WikiNi 0.4.1] les attributs "noshade" et "size" de <hr> (facile à résoudre)
- [corrigé depuis WikiNi 0.4.1] les CSS (wakka.css, wakka.basic.css) ont les noms des tags (BODY, H1...) en majuscules. Or le passage en XHTML rend les tags sensibles à la casse et ils doivent être en minuscules. -- 2004-02-20 OlivierMengu?é.
- [corrigé depuis WikiNi 0.5-CVS] il faut un élément bloc à l'intérieur de chaque formulaire pour que celui-ci soit valide : footer.php, acls.php (tableaux à virer), edit.php
- [corrigé depuis WikiNi 0.5-CVS] et pourquoi pas wakka.php avec ses formopen() et formclose(), ce serait encore plus simple non ? Il suffirait d'ajouter à cette méthode l'argument class et ensuite modifier les fichiers contenant cet appel de méthode :-) -- LordFarquaad
- [corrigé depuis WikiNi 0.5-CVS] l'attribut "wrap" dans le <textarea> d'édition du contenu.
- [corrigé depuis WikiNi 0.5-CVS] remplacer <i> par <em> et <b> par <strong> dans formatter/wakka.php -- 2004-02-27 OlivierMengu?é.
Les problèmes actuels de WikiNi
Voir sur Gna!
Bug 7830
Ordre d'ouverture/fermeture des balises et imbrication de celles-ci
- création d'une pile des balises ouvertes, ce qui permettra de les fermer dans l'ordre
- fait pour les balises de type "en ligne"
- permettre d'appeler la fonction callback avec un argument spécial affin de fermer toutes les balises ouvertes... (ou plus simple: intégrer la fonction callback comme une méthode d'une classe, et proposer une autre méthode pour faire cette opération)
- fait: la fonction callback est à présent une méthode
- à faire: fermeture de toutes les balises encore ouvertes après formatage (important pour corriger des erreurs dans les commentaires etc.)
- imbrication: souvent, ouverture d'une balise de présentation (emphase etc. -> de type "en-ligne") avec impact sur plusieurs lignes dans une liste, alors que les éléments de liste sont de type "bloc". Idéalement, lors du parsing de la liste, la balise de présentation devrait être ouverte et fermée
- solution: consulter la pile des balises ouvertes chaque fois qu'on veut ouvrir une balise de type "bloc", afin de s'assurer que la dernière balise n'est pas de type "en-ligne". Si c'est la cas, fermer la balise "en-ligne", ouvrir la balise "bloc", et rouvrir la balise "en-ligne".
- exemple incorrect :
- exemple correct :
Gérer les balises P et l'imbrication correcte
En première approche il semble qu'on peut résoudre tous les problèmes avec deux piles : les tags à ouvrir et les tags déjà ouverts. Lorsqu'un code de formatage est rencontré, au lieu de l'écrire directement en Html, il faudrait analyser la situation :
- s'il y a un tag correspondant dans la pile des tags ouverts
- vider la pile des tags à ouvrir
- fermer dans le Html tous les tags au-dessus du tag correspondant dans la pile des tags ouverts ainsi que le tag correspondant
- vider la pile des tags ouverts jusqu'au tag correspondant inclus
- sinon
- s'il y a des tags incompatibles dans la pile des tags à ouvrir (typiquement des inline alors qu'on ouvre un block), les éliminer de cette pile
- placer le nouveau tag dans la pile des tags à ouvrir
- s'il y a des tags incompatibles dans la pile des tags déjà ouverts (typiquement des inline alors qu'on ouvre un block), fermer ces tags
- s'il y a un tag correspondant dans la pile des tags à ouvrir -> éliminer ce tag correspondant dans la pile des tags à ouvrir (et rien de plus)
La pile des tags à ouvrir n'est vidée que lorsqu'on rencontre un texte ne commençant pas par un code de formatage. Dans ce cas il suffit d'écrire les tags dans le Html et de les transférer dans la pile des tags ouverts. Il subsiste un point délicat : la fin de ligne sert de tag final pour un certain nombre de tags, typiquement des tags de type block (P, LI, UL, OL, etc.). La fin de ligne doit donc être analysée en tant que fermeture potentielle d'un tag de la pile des tags déjà ouvert. A l'inverse, le début de ligne doit être analysé comme un début de tag P potentiel.
Cette approche semble résoudre tous les problèmes recensés :
- mauvaise imbrication des tags
- tags vides
- utilisation de BR à la place de P
- utilisation de tags de type block dans des tags de type inline
Divers
- l'usage de la fonction PHP highlight_string($text) génère du code qui n'est pas valide en XHTML Strict (usage notamment de la balise <font> qui est dépréciée)
Références