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 veroorzaakt. 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 definities uit 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 de definities uit 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 snel werkende sjablonen waarin elke begintag ook een eindtag heeft 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 definities van HTML4 naar HTML5. 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-uitvoer 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 bij 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-code 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. 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 moeten bewerkers doen?
We hopen dat de uitbreiding Linter medio mei 2017 op alle projecten beschikbaar is. Zoals de Helppagina (en) aangeeft spoort deze uitbreiding stukjes wikitext in pagina's en sjablonen op die verbeterd moeten worden.

Zoals hiervoor gezegd hebben we de uitbreidingen Linter en ParserMigration beschikbaar gesteld om bewerkers te helpen om wikitext aan HTML5 aan te passen. Als je onder Voorkeuren / Bewerken de optie 'Parser migratiehulpmiddel inschakelen' aanvinkt vind je in de linkerbalk onder Hulpmiddelen een optie 'Edit with migration tool' waarmee je de output nu (Tidy) en straks (RemexHTML) ter vergelijking naast elkaar kunt zien. Je kunt ook hiermee ook bewerkingen vooraf bekijken en zien hoe die de output veranderen (repareren).

What is the impact on my wiki?
Please see the wikitext deprecation tool for this information. Note that in several cases the count refers to pages affected, but that includes template-generated issues. In other words, once a given template is fixed, all the pages featuring that template will disappear from the list. So it's highly likely that you won't have to fix thousands or millions pages, but a handful of templates. We are working to make this even more clear. You can also see some progress on Parsing/Replacing Tidy/Linter/Stats/July31.

Simplified instructions for fixing pages
Here are some simplified instructions for handling all the high-priority linter categories. Some of the linked help pages may contain instructions to use assisting tools such as WPCleaner.

Delete OR fix badly nested tables
In this example, Tidy will delete Table 2 above. But, RemexHTML will not delete that table. This can change how pages look. To prevent this, editors should fix the wikitext and remove Table 2. While the following row-tag need not be removed, we recommend removing it. Since the closing table tag is no longer needed, it should be removed as well.

Alternatively, add an explicit  cell on the row started by the previous line before the start of Table 2 if you need nested tables. What is the correct fix depends on the page. But, in most cases deletion as above is going to be the right fix.


 * Help:Extension:Linter/deletable-table-tag

Work around a parser bug for paragraph wrapping
On most wikis, it looks like the biggest generator of these linter warnings are the nowrap or nowrap begin templates. The simplest fix that will handle the vast majority of these linter cases is to add a newline before the opening &lt;span&gt; tag in the template source of these templates.

In all other cases, when wikitext has a span next to a div/td (and other such "block" tags) and has a  CSS property, please add a newline after the div tag.


 * Help:Extension:Linter/pwrap-bug-workaround

Fix invalid self-closing tags
Self-closing tags like &lt;div/>, &lt;span/>, &lt;b/>, etc are not valid in HTML5. They need to be fixed according to what the editor intent might have been. In some cases, it is a typo where a &lt;/b> is intended. In other cases, they need to be deleted. In some other cases, they need to be replaced with a &lt;nowiki/>. Please see the detailed help page for this category.


 * Help:Extension:Linter/self-closed-tag

Caveats

 * 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.
 * We denken nog na of we andere eenvoudige en duurzame ondersteuning kunnen bieden aan "kabouters" en alle Wikimedianen die bij deze operatie willen helpen.

Andere veelgestelde vragen
Vraag: Wat gebeurt er met  en vergelijkbare tags als je ze zelfsluitend gebruikt?

Zoals in T134423 aangegeven, de enige geldige zelfsluitende HTML-tags zijn:,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,  ,   en. De overgang heeft geen gevolgen voor zelfsluitende tags die niet bij HTML horen zoals  en. Een bijzonder geval is  - ook al is het een HTML-tag, in MediaWiki wordt het als een eigen uitbreidingstag behandeld zodat de overgang hiervoor ook geen gevolgen heeft. Alle andere zelfsluitende HTML-tags moeten worden aangepast - en worden nu al door bewerkers aangepast.

Bij onze test zijn in veel pagina's zelfsluitende tags gevonden die na de overgang tot onverwachte effecten bij het renderen kunnen leiden, zoals  dat opgevat gaat worden als   waardoor veel meer tekst vet wordt dan de bedoeling was. Om dit te voorkomen hebben de een aanpassing aan de parser toegevoegd om ze op te vatten als een lege tag, zodat  wordt omgezet in. Maar we hebben deze aanpassing niet bedoeld voor altijd. Daarom hebben we graag dat bewerkers deze niet meer aanvaarde vorm blijven corrigeren.

Vraag: Wat waren de uitkomsten van de test bij andere talen dan Engels of op andere projecten dan Wikipedia?

Niks van wat Tidy en RemexHTML doen is specifiek afgestemd op Wikipedia of op Engels. In dit project gaat hoofdzakelijk om een overgang van de definities uit HTML4 naar die in HTML5 en het beëindigen van het poetswerk van Tidy in de HTML-code. Deze veranderingen raken alle projecten en talen op dezelfde manier, tenzij sommige projecten of talen relatief meer fouten in HTML-code hebben of meer gebruik maken van zelfsluitende tags.

Vraag: Welke veranderingen kunnen bewerkers nog meer verwachten na deze overgang?

Deze overgang raakt in de eerste plaats de lezers, omdat hun misschien opvalt dat een pagina er niet goed uitziet (bijvoorbeeld: overdreven brede navigatieboxen met regels die niet worden afgebroken). Als bewerkers al iets merken dan zou het zijn dat de rendering in VisualEditor en daarbuiten veel beter overeen gaat komen, aangezien Parsoids uitvoer van meet af aan in overeenstemming met HTML5 is geweest en dat geldt straks ook voor de uitvoer voor lezers. We verwachten dat er bij het bewerken met VisualEditor geen enkel verschil zal zijn, maar bij bugmeldingen dat die toch optreden zullen we daar meteen iets tegen doen. We zijn verder niet van plan om op pagina's waarin de HTML-code niet in orde is foutmeldingen of waarschuwingen te zetten.

Vraag: Is er verband tussen deze overgang en andere projecten waar jullie aan werken?

De overgang naar de definities van HTML5 is een van de stappen waardoor de opmaak van alle informatie op Wikimediaprojecten blijft voldoen aan de standaards voor het web. We verwachten de nieuwe programmatuur ook te gebruiken om snellere sjablonen waarin elke begintag ook een eindtag heeft beter te ondersteunen. Daarnaast, maar wel: daarbij, zal de overgang de uitvoer van de PHP-parser (die lezers zien) en de uitvoer van Parsoid (die bewerkers in VisualEditor of Content Translation zien) meer in overeenstemming brengen, omdat Parsoid al de definities van HTML5 aanhoudt.

--The Parsing Team (Het Parsingteam)

Vrijwilligers die bij deze operatie willen helpen
''Community Liasons (de afdeling Contacten met de gemeenschap) nodigt belangstellende Wikimedianen graag uit om hun naam onder de volgende hoofdjes toe te voegen en te helpen bij het betrekken van de gemeenschap. Bij voorbaat dank! Net als bij vergelijkbare acties voorheen kun je ook meedoen zonder je naam hieronder te zetten. Please see Parsing/Get_involved, and add it to your bookmarks, as future requests for assistance will go through that page!
 * 1) Ik wil wel de uitbreiding ParserMigration wel testen.
 * 2) (hieronder je ondertekening toevoegen)
 * 3) Ik wel wel helpen om sjablonen aan te passen.
 * 4) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 5) Samuele2002 (talk)
 * 6) TheDragonFire (talk)
 * 7) Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 8) Ik wil wel helpen om aanpassingen van sjablonen uit te zoeken en met anderen te bespreken.
 * 9) Jonesey95 (talk) 16:10, 14 November 2016 (UTC)
 * 10) Ik wil wel helpen om mijn gemeenschap voor te lichten.
 * 11) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 12) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)
 * 1) (See this page) --Sannita (talk) 18:02, 8 July 2017 (UTC)
 * 2) See this page. Stryn (talk) 14:22, 17 July 2017 (UTC)