Analyse syntaxique/Remplacement de Tidy/FAQ
Qu'est-ce que Tidy ?
Tidy est une bibliothèque anciennement utilisée par Mediawiki pour corriger certaines erreurs HTML trouvées dans les pages wiki.
Le balisage mal formé est courant dans les pages wiki quand les contributeurs utilisent des balises HTML dans les modèles ou dans la page elle-même. (Exemple : les balises HTML non fermées, comme <small> sans </small>, sont fréquentes). Dans certains cas, MediaWiki peut aussi générer du code HTML erroné par lui-même.
Tidy corrige ces erreurs de balises, mais fait aussi de son côté du nettoyage non nécessaire à l’exactitude du code. Par exemple, il enlève les éléments vides et ajoute des espaces entre les balises HTML ce qui peut quelquefois modifier la présentation. Comme Tidy s'appuie sur la sémantique de HTML 4 et que le web est passé à HTML 5, il apporte aussi des modifications incorrectes au code HTML pour « corriger » les choses qui n’étaient auparavant pas permises ; par exemple, Tidy va, sans qu'on le souhaite, déplacer une liste à puces en dehors d'une zone de légende d’un tableau bien que cela soit autorisé.
Pourquoi le remplacez-vous ? Et par quoi ?
La technologie de Tidy date des années 1990, quand les navigateurs web n’étaient pas standardisés. Le comportement de Tidy est librement basé sur la sémantique HTML 4 mais ne correspond plus aux navigateurs modernes. Après des années passées sans réelle maintenance, Tidy a maintenant été remis à jour sous le nom de « tidy-html5 » avec un comportement très différent. L'ancien Tidy n'est plus empaqueté. Comme expliqué précédemment, Tidy fait du nettoyage de HTML sans lien avec les erreurs à corriger. Conjugués, tous ces problèmes ont conduit à créer beaucoup de bogues qui ont donné lieu à des tickets dans Phabricator, et une demande de son remplacement a été faite depuis au moins 2013. HTML 5 est le standard aujourd'hui, et l'algorithme d'analyse pour HTML 5 est clairement spécifié, ce qui a conduit à des implantations compatibles à travers les navigateurs et autres bibliothèques. Cet algorithme spécifie aussi clairement comment un balisage cassé devrait être corrigé. Dans ce nouveau paysage technologique, Tidy devrait réellement être remplacé par un analyseur HTML 5 qui corrigerait le code défectueux et en génèrerait un code HTML valide et bien formé d’une manière standard. Mais les wikis Wikimedia ont un énorme corpus de pages dont le codage dépend des corrections de Tidy. Remplacer immédiatement et directement Tidy par un autre outil basé sur HTML 5 n'est pas faisable, car un outil basé sur HTML 5 réparerait certaines balises différemment et ceci pourrait casser l'aspect des pages. Aussi nous remplaçons Tidy par notre propre outil basé sur les spécifications HTML5, mais qui apporte aussi quelques palliatifs pour la compatibilité avec Tidy, afin de minimiser l'impact du remplacement de celui-ci. Après avoir expérimenté 3 solutions différentes, nous nous sommes fixés sur RemexHTML, un analyseur HTML5 basé sur PHP par-dessus duquel nous avons écrit des couches compatibles avec Tidy afin de pouvoir retrouver certains comportements de Tidy, que nous avons besoin de fournir pour l'instant. A l'avenir, RemexHTML pourrait aussi être utilisé pour activer de nouvelles fonctionalités du noyau de MediaWiki, comme le renforcement de la robustesse de l'édition des sections, le support équilibré des modèles, et un rafraichissement plus efficace des pages après que les modèles aient été modifiés. Pour ceux qui se posent des questions, notez que l'utilisation de tidy-html5 ne nous empêchera pas d'avoir à corriger les erreurs HTML étant donné qu'une partie du nettoyage demandé est due au passage de la sémantique HTML4 à la sémantique HTML5. Il y a d'autres critères pour la gestion des modifications, qui nous ont conduits à préférer un outil interne, entre autre la possibilité d'activer d'autre fonctionalités, comme mentionné ci-dessus.
Si vous êtes intéressé par d'autres détails techniques, veuillez voir phab:T89331 ou Remplacer Tidy.
Quels tests avez-vous réalisés jusqu'ici ?
Pour identifier les conséquences du remplacement de Tidy par un outil s'appuyant sur le HTML5, nous avons utilisé une stratégie de test (en utilisant un outil appelé "VisualDiff") qui compare pixel par pixel l'image de sortie de MediaWiki avec Tidy activé, avec celle de l'image remplaçante. Assez tôt, nous avons vu qu'une différence commune résidait dans les modifications mineures des espaces blancs verticaux. En croyant que ceux-ci seraient soit non perceptibles, soit acceptables, nous avons écrit un outil appelé « UprightDiff » qui est capable d'identifier le déplacement vertical à l'intérieur d'une image et de réduire un tel déplacement pour les tests automatisés. Ceci nous a permis ainsi d'assigner une valeur numérique aux différences, et d'identifier immédiatement les différences les plus énormes. Nous avons exporté un sous-ensemble d'environ 64.000 articles (certains issus du flot de modifications récentes, et le reste choisi de manière aléatoire) venant de wikis Wikimedia différents (40 wikis parmi lesquels Wikipedia, Wikisource, Wiktionary, et Wikivoyage), que nous avons fait passer par Tidy et RemexHTML, et ensuite utilisé "UprightDiff" pour analyser le résultat. Ceci occupe beaucoup de cycles du processeur, de la mémoire, et de l'espace disque, et prend 2 jours pour parcourir l'ensemble des tests. Ceci limite la taille du corpus à tester main nous pensons que 64K est un échantillon suffisant pour mettre en évidence les types de corrections nécessaires.
Pour réduire le nombre de différences et l'impact des corrections qui seraient nécessaires aux éditeurs, nous avons ajouté des correctifs compatibles avec Tidy. En remarquant que les balises auto-fermantes étaient très utilisées sur les wikis wikimedia, nous avons ajouté une correction de compatibilité pour les traiter comme des balises vides (par exemple <b /> est synonyme de <b></b>). Nous avons également ajouté quelques autres schémas de compatibilité.
Après que tous ces correctifs aient été mis en place et que nous ayons répété nos tests, nous avons trouvé que 93,4% des pages ne présentaient pas de modification dans l'affichage. Et, 96,9% des pages n'avaient soit aucun pixel de différence (93,4%) soit seulement un décalage non perceptible dans l'espacement vertical (3,5% = 96,9 - 93,4). Le reste des 3,1% des pages (100 - 96,9) ont montré des différences de pixel mais pour d'autres raisons.
Sur la base de ces tests, nous avons identifié plusieurs classes d'erreurs de balisage qui provoquaient deux affichages différents. Pour l'une de ces classes d'erreurs (les balises auto-fermantes qui ne sont plus valides en HTML5), nous avons ajouté une catégorie maintenance que les éditeurs utilisaient déja pour corriger les modèles et les pages. Mais les autres classes d'erreurs de balisage ne sont pas faciles aujourd'hui à détecter automatiquement et l'aide des éditeurs est nécessaire pour les identifier et les corriger.
Qu'arrivera-t-il ? Quand ces modifications surviendront-elles ?
Comme indiqué antérieurement, nous ne pouvons cependant pas faire un remplacement ponctuel de Tidy avec un outil basé sur HTML5. Nous avons ajouté une catégorie de maintenance pour une classe d'erreurs de balisage, qui aidera les éditeurs à les corriger. Pour aider les éditeurs à identifier les autres erreurs de balisage, nous avons également écrit l'extension ParserMigration qui les aidera à comparer les sorties en production et à corriger les erreurs de balisage. En parallèle, nous avons aussi construit l'extension Linter pour identifier quelques-unes des corrections nécessaires.
Ainsi à la fin mars 2017, nous avons déployé les extensions ParserMigration sur tous les wikis. Au 20 juin 2017, Linter a été déployé sur tous les gros wikis. Via ces extensions, nous espérons permettre aux contributeurs de corriger les pages pour effectivement remplacer Tidy en 2017. Une fois qu’assez de corrections seront faites et que nous serons convaincu que l’impact sur les contributeurs et lecteurs sera faible, nous remplacerons enfin Tidy. Mais aussi, nous n'aimerions pas tirer ceci indéfiniment. Il serait donc idéal si les problèmes identifiés par l'extension Linter avec la priorité haute, soient résolus en premier lieu par les éditeurs.
Par ailleurs, les correctifs de compatibilité avec Tidy (mentionnés dans la section précédente) sont supposés être en place jusqu’à ce que nous remplacions Tidy. Après cela, nous commencerons le remplacement de ces correctifs progressivement en s’appuyant sur des tests et outillages similaires.
Que devront faire les éditeurs ?
L'extension Linter a été déployée sur tous les wikis. Comme il est dit sur la page d'aide, veuillez corriger les éléments wikitexte et les modèles identifiés parmi les catégories de haute priorité sur la page Special:LintErrors de votre wiki. Chaque élément dans cette catégorie a une page d'aide avec des exemples qui indiquent ce qui doit être corrigé. Voir les instructions simplifiées ci-dessous.
Pour aider les éditeurs dans la migration de leur texte wiki et vérifier les corrections qu'ils ont faites, nous avons déployé l'extension ParserMigration. Si vous activez "ParserMigration" dans vos préférences, un liens sera ajouté à la boîte à outils de tous les articles, qui pourra montrer côte à côte les sorties courantes (Tidy) et attendues (RemexHTML). Vous pouvez prévisualiser les modifications du texte des articles dans la même vue côte à côte et voir comment vos mises à jour modifient / corrigent l'affichage.
Quel est la conséquence sur mon wiki ?
Reportez-vous à l’outil pour le wikicode obsolète pour ces informations. Remarquez que dans plusieurs cas, le compteur indique les pages affectées, mais cela inclut les problèmes générés par les modèles. En d’autres termes, une fois qu’un modèle donné est corrigé, toutes les pages utilisant ce modèle disparaitront de la liste. Il est donc fort probable que vous n’ayez pas à corriger des milliers ou millions de pages, mais une poignée de modèles. [phab:T170874 Nous travaillons à rendre cela plus clair]. Vous pouvez aussi voir en partie la progression tracée sur Parsing/Replacing Tidy/Linter/Stats, et les résultats de tests d’écarts visuels sur un échantillon d’environ 73 000 articles de 60 wikis sur http://mw-expt-tests.wmflabs.org/ .
Instructions simplifiées pour corriger les pages
Il existe quelques instructions simplifiées pour gérer toutes les catégories linter de priorité haute. Certaines pages d'aides référencées peuvent contenir des instructions pour utiliser des outils d'assitance comme WPCleaner.
Supprimer OU corriger les tables mal imbriquées
{| <-- Table 1 starts here
| foo
|-
{| <-- Table 2 starts here. You can remove this code.
|- <-- Row for Table 2. You may remove this too if you wish so.
| bar
|} <-- this closing tag is now useless and should be removed too
|}
Dans cet exemple, Tidy supprimera le tableau 2 du dessus. Mais RemexHTML ne supprimera pas ce tableau. Cela peut changer l’apparence des pages. Pour empêcher cela, les contributeurs devraient corriger le wikicode et supprimer le tableau 2. Bien que les balises en ligne suivante ne nécessitent pas d’être supprimées, nous recommandons de le faire tout de même. Puisque la balise de fermeture du tableau n’est plus nécessaire, elle devrait être supprimée également.
Une autre solution est d’ajouter une cellule explicite | sur la rangée commençant par la ligne précédente avant le début du tableau 2 si vous souhaitez des tableaux imbriqués. La correction à appliquer dépend de la page, mais dans la plupart des cas, la suppression décrite ci-dessus sera la bonne correction.
Palliatif pour corriger un bogue de l'analyseur dans les cas de repli de paragraphe
Sur la plupart des wikis, il semble que le plus gros générateur de ces problèmes linter sont les modèles nowrap (pas de retour à la ligne) ou nowrap begin. Le correctif le plus simple qui corrigerait la plupart de ces erreurs lint est l’ajout d’une nouvelle ligne avant la balise ouvrante <span> dans le texte source de ces modèles.
Dans tous les autres cas, lorsque le wikicode a un span à côté d’une div ou td (et autres balises de type bloc similaires) et a la propriété CSS white-space:nowrap, ajoutez une nouvelle ligne après la balise div.
<div><span style='white-space:nowrap'> <!-- <== ADD NEWLINE AFTER THE <div>. -->
foo bar
</span>
</div>
- Note that this has the effect of enclosing the whole span in a paragraph element. Here the bug comes from newlines within the div element that cause a new paragraph to be generated for "foo".
- The alternative, if you don't want a paragraph element automatically inserted (with its additional margins) by MediaWiki to surrounding the "span" inside the "div", is to not use any newline at all in the content of the "div" element, or to "hide" these newlines within HTML comments:
<div><span style='white-space:nowrap'>foo bar</span></div>
<div><!--
--><span style='white-space:nowrap'><!--
-->foo bar<!--
--></span><!--
--></div>
Corriger les balises auto-fermantes invalides
Les balises auto-fermantes comme <div />, <span />, <b />, etc... ne sont pas valides en HTML5.
Elles doivent être corrigées en fonction de l'intention de l'éditeur. Dans certains cas, il s'agissait d'une faute de frappe où un </b> était attendu. Dans d'autres cas, elles ont dû être supprimées. Dans d'autres encore, elles ont dû être remplacées par <nowiki />. Veuillez vous reporter à la page d'aide détaillée pour cette catégorie.
Corriger les pages concernées par le problème des espaces dans Tidy
| Wikicode d'entrée | Sortie de Tidy | Sortie de Remex | Proposition de correction du wikicode |
|---|---|---|---|
<span class='nowrap'>a </span><span class='nowrap'>b</span>
|
<span class='nowrap'>a</span> <span class='nowrap'>b</span>
|
<span class='nowrap'>a </span><span class='nowrap'>b</span>
|
<span class='nowrap'>a</span> <span class='nowrap'>b</span>
|
Corriger les problèmes de balises mal imbriquées de HTML5 avec Tidy
Voici un exemple qui illustre le problème.
| Wikicode d'entrée | Sortie de Tidy | Sortie de Remex | Proposition de correction du wikicode |
|---|---|---|---|
<span>a
b</span>
|
<p><span>a</span></p>
<p><span>b</span></p>
|
<p><span>a</span></p>
<p>b</p>
|
<span>a</span>
<span>b</span>
|
That was just one example to demonstrate the problem. There are other instances - ''foo<sup>''bar</sup> (an enwiki talk page) or <span>\n*x</span> (many itwiki pages via the use of citazione necessaria template) are other instances.
balise de fonte avec l'attribut de couleur pour entourer les liens wiki
Here is an example to illustrate the problem.
| Wikicode | Tidy | Remex | Proposition de correction |
|---|---|---|---|
<font color="green">[[Foo]]</font>
|
<a href=".."><font color="green">Foo</font></a>
|
<font color="green"><a href="..">Foo</a></font>
|
[[Foo|<font color="green">Foo</font>]] or better yet, [[Foo|<span style="color:green;">Foo</span>]].
|
NOTE: Only a small set of font tags used on wikis are affected as explained above. All other uses don't need to be fixed. See the help page below for more details.
Plusieurs balises de formatage non fermées
| Wikicode | Proposition de correction |
|---|---|
<s>foo<s> bar
|
<s>foo</s> bar
|
Tableau HTML sur plusieurs lignes dans les listes
| Wikicode | Tidy | RemexHTML | Proposition de correction |
|---|---|---|---|
* <table>
<tr><td>foo</td></tr>
</table>
bar
|
<table>
<tr>
<td>foo</td>
</tr>
</table>
<p>bar</p>
|
<ul><li>
<table>
<tbody><tr><td>foo</td></tr>
</tbody></table>
<p>bar</p>
</li></ul>
|
<table>
<tr><td>foo</td></tr>
</table>
bar
|
Apostrophes non fermées dans les titres
| Wikicode | Proposition de correction |
|---|---|
text
==''foo==
bar
|
text
==''foo''==
bar
|
Avertissements
- Nous ne savons pas encore comment déterminer automatiquement toutes les pages affectées et modèles, mais nous espérons que la liste de modèle et suggestions sera plus complète lorsque nous serons au courant de problèmes n’ayant pas été détectés auparavant. Les Community Liaisons (personnels faisant le lien avec les communautés) se mettront en lien avec les experts modélistes, les habitués des bistrots, etc. pour s’assurer qu’ils soient au courant des changements nécessaires et des ressources qui pourraient les aider.
- Nous pensons à d'autres moyens faciles et durables pour soutenir les « gnomes » et tous les wikipédiens voulant participer à cet effort.
Autres FAQs
Q: Qu'arrive-t-il à <pre /> et aux balises similaires si elles sont utilisées dans une forme auto-fermante ?
A : Comme noté sur T134423, les seules balises HTML autofermantes autorisées sont : area, base, br, col, embed, hr, img, input, keygen, link, meta, param, source, track, wbr.
Les balises autofermantes non HTML (comme <references /> et <nowiki />) ne sont pas concernées par ce changement. <pre> est un cas à part car bien que ce soit une balise HTML, MediaWiki la traite comme une balise d’extension et elle n’est par conséquent pas affectée. Toutes les autres balises HTML autofermantes doivent être corrigées (et sont déjà en train de l’être, par les contributeurs).
Puisque cette syntaxe est utilisée dans de nombreuses pages de nos tests, dans le but d’éviter des conséquences inattendues sur le rendu (par exemple <b /> traitée comme <b> et mettant donc plus de texte en gras que souhaité), nous avons ajouté un correctif à l’analyseur syntaxique (parser) pour les convertir en balises vides (par exemple, <b /> sera converti en <b></b>). Mais nous n’avons pas l’intention de laisser ce correctif indéfiniment. Nous aimerions donc que les contributeurs continuent à corriger ces syntaxes obsolètes.
Q: Quels sont les résultats des tests pour les langues différentes de l'anglais, ou sur les projets frères ?
R: Il n'y a rien dans ce que Tidy et RemexHTML font, qui soit spécifique à Wikipedia ou à la langue anglaise. Ce projet concerne initialement un changement des sémantiques HTML4 en HTML5 et du désir de se débarasser de certains réarrangements faits sur le HTML par Tidy. Ces modifications concernent tous les projets et toutes les langues sans distinction, sauf si certains projets ou certaines langues ont tendance à avoir plus d'erreurs HTML, ou utilisent plus de balises auto-fermantes que d'autres.
Q: Quels sont les autres changements que les éditeurs pourraient voir, après ce remplacement ?
R : l'effet de cette substitution va d'abord toucher les lecteurs qui pourront éventuellement remarquer que la page ne s'affiche pas normalement (par exemple, des boîtes de navigation trop larges, sans retours à la ligne ni repli). Cependant, dans tous les cas, ceci pourrait amener le rendu visible dans l’éditeur visuel à correspondre bien davantage avec le rendu en lecture, puisque la sortie de Parsoid est conforme au HTML 5 depuis le début et nous travaillons maintenant à ce que le rendu en lecture devienne du HTML 5. Nous n’attendons aucune conséquence sur les modifications faites avec l’éditeur visuel, mais nous corrigerons rapidement tout bogue signalé concernant des différences inattendues. De plus, nous ne prévoyons pas d’ajouter des messages d’erreur ou d’avertissement sur les pages où les erreurs de balises ne seraient pas corrigées.
Q: Comment le remplacement garde-t-il les liens avec les autres projets sur lesquels vous travaillez ?
R : En autorisant le passage à la sémantique HTML5, voici un point concernant l'évolution des balises dans notre corpus à garder en accord avec le standard du web. Nous souhaitons également élever cet outil pour prendre en charge les sorties de modèles équilibrés. Par ailleurs, cela rendra les sorties de l’analyseur syntaxique PHP (utilisé pour la lecture) et de Parsoid (utilisé pour les modifications avec l’éditeur visuel et l’outil de traduction de contenu) plus cohérentes puisque Parsoid utilise déjà la sémantique du HTML5. Un de nos objectifs est de rendre les deux sorties complètement cohérentes entre elles et utiliser un unique analyseur pour la lecture et la modification à la fois.
Des volontaires disponibles pour soutenir cet effort
Les membres de liaison de la Communauté invitent les Wikimediens intéressés à bien vouloir ajouter leur nom dans les sections ci-dessous et à soutenir les efforts de la Communauté dans ses engagements. Merci. Comme avec les initiatives similaires par le passé, l'adhésion est optionnelle. Veuillez consulter Parsing/Get_involved, et le mettre dans vos favoris, car les demandes d'assistance utltérieures se feront par l'intermédiaire de cette page !
- Je suis disponible pour faire les tests avec l'outil ParserMigration (analyse de la migration).
- (ajoutez votre signature ici)
- ...
- ...
- Je suis disponible pour corriger les modèles.
- Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
- Samuele2002 (talk)
- TheDragonFire (talk)
- Stryn (talk) 14:22, 17 July 2017 (UTC)
- Already did some in fawiki Ladsgroup (talk) 15:40, 18 September 2017 (UTC)
- My bot can fix multiple-unclosed-formatting-tags error. --星耀晨曦 (talk) 07:19, 6 April 2018 (UTC)
- ネイ (talk) 09:36, 7 April 2018 (UTC)
- Been at it a long time already at en.Wikipedia. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 3 May 2019 (UTC)
- Je suis disponible pour étudier et discuter des corrections concernant les modèles.
- Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
- Been at it a long time already at en.Wikipedia. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 3 May 2019 (UTC)
- Je suis disponible pour diffuser les informations à ma communauté.
- (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
- See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)
- See this page. ネイ (talk) 09:36, 7 April 2018 (UTC)
- See meta:User:SMcCandlish/lint.css; w:Linter#User CSS tool: lint.css; w:Template:Mxt/User CSS for a monospaced coding font; etc. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:56, 3 May 2019 (UTC)