Parsing/Replacing Tidy/FAQ/nl

Wat is Tidy?
Tidy (en) is programmatuur die MediaWiki op dit moment gebruikt om fouten in HTML op pagina's in een wiki op te lossen. Pagina's met foutief HTML komen vaak voor in een wiki wanneer bewerkers HTML-tags gebruiken in sjablonen of direct op de pagina. Een voorbeeld: vaak wordt een afsluitende HTML-tag vergeten, zoals een  na een. Er zijn ook gevallen waarin MediaWiki zelf fouten in HTML kan maken. Tidy repareert deze fouten, maar doet ook eigen "poetswerk" waarbij het niet om fouten gaat. Het haalt bijvoorbeeld HTML-elementen zonder inhoud weg en voegt witruimte tussen HTML-tags toe, waardoor de weergave soms verandert (en). Omdat Tidy nog uitgaat van HTML4 maar op internet HTML5 gangbaar is geworden, doet het ook een paar onjuiste aanpassingen om dingen te 'repareren' die vroeger niet goed waren: hoewel je een lijst met bullets in het kopje van een tabel mag zetten, zal Tidy die zomaar daaruit halen.

Waarom vervangen? En waardoor?
De technologie van Tidy komt uit de jaren 90, toen webbrowsers niet gestandaardiseerd waren. Wat Tidy doet gaat min of meer uit van HTML4, maar spoort niet met een hedendaagse browser. Na jaren zonder actief onderhoud is Tidy nu aan een nieuw leven begonnen als "tidy-html5", dat heel anders werkt. Het oude Tidy zit niet meer in het MediaWikipakket. Zoals gezegd doet Tidy ook eigen poetswerk aan HTML, los van fouten. Dit alles maakte dat er op Phabricator veel bugs in Tidy werden gemeld en sinds in ieder geval2013 wordt al om vervanging gevraagd. HTML5 is de standaard van nu en voor HTML5 is duidelijk stap voor stap vastgelegd hoe HTML-code naar een beeld vertaald moet worden ('parsen'). Dit heeft geleid tot browsers en andere programmatuur die met elkaar overeenkomende resultaten geven. Dit beschrijving stap voor stap geeft ook precies aan hoe fouten in HTML-code moeten worden opgelost. In deze nieuwe technologische omgeving moet Tidy echt worden vervangen door een HTML5-parser die netjes volgens de standaard fouten in HTML-code oplost en een geldige, correct beschreven HTML-opmaak oplevert. Maar ondertussen hebben de Wikimediaprojecten een enorme verzameling pagina's waarvan de opmaak nog uitgaat van aanpassingen door Tidy. Het is niet doenlijk om Tidy ineens simpelweg te vervangen door bestaande HTML5-programmatuur van anderen, want die programmatuur zou de opmaak op een andere manier aanpassen en dat kan verstoren hoe de pagina's eruitzien. Daarom gaan we Tidy vervangen door eigen programmatuur gebaseerd op HTML5 met een paar Tidy-achtige aanvullingen om de overgangsproblemen zo klein mogelijk te maken. Na proeven met drie verschillende oplossingen zijn we uitgekomen op RemexHTML, een HTML5-parser gebaseerd op PHP, die we hebben aangevuld met eigen routines die sommige acties van Tidy nadoen die we nu nodig hebben. In de toekomst zou RemexHTML ook gebruikt kunnen worden om nieuwe mogelijkheden in MediaWiki in te bouwen, zoals het betrouwbaarder kunnen werken met secties, ondersteuning voor sjablonen die paarsgewijs gebruikt moeten worden en het efficiënter vernieuwen van pagina's nadat een sjabloon bewerkt is. Voor de volledigheid: ook als we tidy-html5 bleven gebruiken zouden we foutieve HTML-code moeten aanpakken, want een deel van de aanpassingen heeft te maken met een verandering in de betekenis van HTML-code van versie 4 naar 5. Andere overwegingen rond het beheersbaar houden van veranderingen, waaronder de hiervoor genoemde nieuwe mogelijkheden, leiden tot de keuze voor eigen programmatuur.

Voor andere technische details, zie phabricator.wikimedia.org/T89331 (en) of Replacing Tidy (en)'''

Wat hebben jullie tot nu toe getest
Om een beeld te krijgen van het effect van de vervanging van Tidy door op HTML5 gebaseerde programmatuur is de MediaWiki-output van beide als plaatje pixel voor pixel vergeleken, met behulp van het programmaatje "VisualDiff". Al in het begin zagen we dat er vaak kleine verschillen waren in verticaal gebruikte witruimte. Vanuit de gedachte dat deze verschillen niet zouden opvallen of niet zouden storen, hebben we het programmaatje "UprightDiff" geschreven dat verticale verschuivingen in het beeld kan signaleren en negeren bij het automatisch testen. Dit liet ons ook de verschillen in een cijfer uitdrukken en de ernstigste verschillen aanwijzen. We hebben uit verschillende Wikimediaprojecten (40 wiki's van Wikipedia, Wikisource, Wiktionary en Wikivoyage) een deelverzameling van ongeveer 64.000 artikelen in wikitext gehaald: een aantal uit de 'Recente wijzigingen' en de rest willekeurig gekozen. Deze pagina's zijn zowel met Tidy als met RemexHTML gerenderd en daarna hebben we "UprightDiff" gebruikt om het resultaat te analyseren. Dit vraagt veel capaciteit van processoren, werkgeheugen en vaste schijven en één testronde duurt twee dagen. Dit beperkt hoe groot de verzameling artikelen in de test kan zijn, maar we denken dat een steekproef van 64.000 groot genoeg is om uit te maken wat voor aanpassingen nodig zijn.

Om de verschillen zo klein mogelijk te houden en de noodzakelijke aanpassingen door bewerkers zo beperkt mogelijk te houden hebben we nog wat meer Tidy-achtige aanpassingen aan RemexHTML toegevoegd. Aangezien we ontdekten dat zelfsluitende HTML-tags heel vaak voorkomen op Wikimediaprojecten hebben we een aanpassing toegevoegd die doet of het lege tags zijn:  wordt verwerkt als . Zo hebben we nog een paar aanpassingen toegevoegd. Toen we de test herhaalden nadat we al deze aanpassingen hadden doorgevoerd, bleek er bij 93,4% van de pagina's geen enkel verschil in rendering te zijn. Bij 3,5% waren er alleen maar niet storende verticale verschuivingen door verschil in witruimte, dus 96,9% (93,4% + 3,5%) was er geen verschil van betekenis. De resterende 3,1% (100%-96,9%) van de pagina's vertoonde andersoortige verschillen.

Op basis van deze tests kunnen we een paar soorten fouten in de HTML-opmaak aangeven die leiden tot verschillen in rendering. Voor één soort fouten (zelfsluitende tags die in html5 niet meer geldig zijn) hebben we een onderhoudscategorie toegevoegd die bewerkers al hebben gebruikt om sjablonen en pagina's bij te werken. Maar de andere soorten fouten in de HTML-opmaak zijn op dit moment niet gemakkelijk automatisch te achterhalen en de hulp van bewerkers is noodzakelijk om ze te vinden en recht te zetten.

Wat gaat er gebeuren? Wanneer gaat er wat veranderen?
Zoals gezegd, we kunnen Tidy nog niet pardoes door programmatuur op basis van HTML5 vervangen. We hebben voor één soort fouten in de HTML-opmaak een onderhoudscategorie toegevoegd, die bewerkers helpt om ze te herstellen. Om bewerkers te helpen bij het vinden en herstellen van andere opmaakfouten hebben ook de uitbreiding ParserMigration ontwikkeld, die hen helpt te vergelijken hoe de pagina er uiteindelijk uitziet en fouten in HTML-code te herstellen. Daarnaast hebben we ook de uitbreiding Linter (en) ontwikkeld die een deel van de noodzakelijke correcties aangeeft.

Eind maart 2017 hadden we de uitbreiding ParserMigration op alle Wikimediaprojecten beschikbaar gemaakt. De uitbreiding Linter is op het ogenblik beschikbaar op de kleine en middelgrote Wikimediaprojecten. We hopen Linder medio mei ook op grote Wikimediaprojecten beschikbaar te hebben. Met deze uitbreiding willen we bewerkers in staat stellen om pagina's te corrigeren voordat Tidy in de loop van 2017 wordt vervangen. Wanneer er genoeg gecorrigeerd is en wij ervan overtuigd zijn dat de effecten voor bewerkers en lezers gering en aanvaardbaar zijn zullen we verder gaan en Tidy vervangen. Maar we voelen er ook niet voor dit eindeloos te laten duren. Het is daarom ideaal als bewerkers prioriteit geven aan punten met hoge prioriteit in de uitbreiding Linter.

Los hiervan is het de bedoeling dat de Tidy-achtige aanpassingen die we in de vorige paragraaf noemden blijven werken totdat we Tidy vervangen. Daarna gaan we deze aanpassingen geleidelijk vervangen waarbij we op een vergelijkbare manier tests en hulpprogrammaatjes zullen gebruiken.

Wat moet ik doen?

 * We verwachten dat sommige sjablonen bijgewerkt moeten worden. Bij de tests op zichtbare verschillen (en) staan voorbeelden van sjablonen die aangepast moeten worden. Er is ook een soort fouten in HTML-code waarbij de uitbreiding Linter, die informatie uit Parsoid laat zien, naar verwachting goed zal helpen om de sjablonen aan te wijzen waar het probleem zit. We weten op dit moment niet hoe we automatisch alle sjablonen die aangepast moeten worden kunnen opsporen, maar we verwachten dat de lijst van sjablonen en voorgestelde oplossingen vollediger zal worden naarmate we problemen tegenkomen die nog niet eerder gesignaleerd waren. De afdeling Community Liaisons ('Contacten met de Gemeenschap') zal contact opnemen met sjabloonexperts en mensen die vaak meedoen aan discussies over de technische kant van een project om ervoor te zorgen dat zij weten van de noodzakelijke aanpassingen en de hulpmiddelen die hen daarbij ten dienste staan.
 * As mentioned above, to assist editors in migrating wikitext to the new rules, we have deployed the Linter and ParserMigration extensions. If you enable "ParserMigration" in your preferences, a link will be added to the toolbox of all articles, which can show the current (Tidy) and expected (RemexHTML) output side-by-side. You can preview article text changes in the same side-by-side view and see how your edits changes / fixes rendering.
 * We hope to have the Linter extension enabled on all wikis by mid-May 2017. As indicated on the help page, this identify wikitext patterns in pages and templates that need to be fixed.
 * We are thinking about other easy, sustainable ways in which we may support "gnomes" and all the Wikimedians willing to help with this effort.

Other FAQs
Q: What happens to  and similar tags if they are used in self-closed form?

A: As noted in T134423, the only valid self-closed HTML tags are:,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,. Non-HTML self-closing tags (like  and  ) are not affected by this change. is a special case because while it is a HTML tag, MediaWiki treats it like an extension tag and hence remains unaffected. All other self-closing HTML tags should be fixed (and are already being fixed by editors at this time).

Since this usage is found in a lot of pages in our testing, in order to prevent unexpected rendering effects (e.g.  being treated as    and causing more text being bolded than intended), we added a fix to the parser to convert them to an empty tag (eg.   will be converted to  ). But, we don't intend to retain this fix indefinitely. So, we would like for editors to continue fixing this deprecated usage.

Q: What were the results of tests on languages other than English, or on sister projects?

A: There is nothing in what Tidy, RemexHTML do that is specific to Wikipedia or English. This project is primarily about a change from HTML4 to HTML5 semantics and getting rid of some Tidy cleanups of HTML. These changes affects all projects and languages equally, except if some projects and languages tend to have more markup errors or use more self-closed tags than others.

Q: What other changes are editors likely to see, after this replacement?

A: The effect of this replacement is primarily going to affect readers, as they may notice that the page doesn't look right (for example, excessively wide navboxes without line breaks or wrapping). However, if anything, this might lead to the rendering seen in VisualEditor to match the rendering seen outside it much more than before, since Parsoid's output has been HTML5-compliant since the beginning, and we are now moving the read output to HTML5. We do not expect any impact on VisualEditor edits, but we will promptly address any bugs reported with respect to dirty diffs. In addition, we do not plan to add any error messages or warnings displayed on pages if the markup errors are not fixed.

Q: How does the replacement relate to other projects you are working on?

A: By enabling the move to HTML5 semantics, this is one of the steps evolving markup in our corpus to keep up with web standard. We also expect to leverage this tool to support well-balanced template output. Separately, but relatedly, this will also make the output of the PHP parser (used for reads) and the output of Parsoid (used for edits in VE, Content Translation) more consistent since Parsoid already uses HTML5 semantics. One of our goals is to make the two outputs fully consistent with each other and use one parser for both reads and edits.

--The Parsing Team

Volunteers available to support this effort
''Community Liaisons invite interested Wikimedians to please add their name in the sections below and support their community engagement efforts. Thank you. As with similar past initiatives, signing up is optional.''
 * 1) I am available to test with the ParserMigration tool.
 * 2) (add your signature here)
 * 3) I am available to fix templates.
 * 4) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 5) Samuele2002 (talk)
 * 6) I am available to study and discuss fixes to templates.
 * 7) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 8) I am available to spread the word among my community.
 * 1) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 2) I am available to spread the word among my community.