Parsing/Vervanging Tidy/Veelgestelde vragen
Wat is Tidy?
Tidy is een bibliotheek die ooit gebruikt is door MediaWiki om enkele HTML-fouten in wiki-pagina's te corrigeren.
Pagina's met een fout in de 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 </small> na een <small>. 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. 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 waarmee?
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 is niet goed 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 al zeker sinds 2013 al om vervanging is 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 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 projecten van Wikimedia een enorme verzameling pagina's waarvan de opmaak nog uitgaat van aanpassingen door Tidy. Het is niet doenlijk om Tidy simpelweg te vervangen door bestaande HTML5-programmatuur van anderen, want die programmatuur zou de opmaak op een manier aanpassen die 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.
Als je nog meer technische details wilt hebben: lees phab:T89331 of Vervangen Tidy.
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 projecten van Wikimedia (40 wiki's van Wikipedia, Wikisource, Wiktionary en Wikivoyage) een deelverzameling van ongeveer 64.000 artikelen 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 projecten hebben we een aanpassing toegevoegd die doet of het lege tags zijn: <b /> wordt verwerkt als <b></b>. 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% was er geen verschil van betekenis. De resterende 3,1% 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 te verbeteren.
Wat gaat er gebeuren? Wanneer gaat er wat veranderen?
Zoals gezegd, we kunnen Tidy nog niet 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 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?
De extensie Linter is op alle wiki's beschikbaar. Lees deze pagina om fouten in wikitekst patterns en sjablonen te verbeteren. Ze zijn ingedeeld naar prioriteit op de Special:LintErrors pagina in je wiki. Per soort fout is er een pagina met voorbeelden die aangeven wat het probleem is wat het liefst aangepast moet worden Zie onderstaande instructies.
Om bewerkers te ondersteunen zijn de extensies Linter en ParserMigration beschikbaar, voor het bijwerken naar HTML5. 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 lay-out nu (Tidy) en straks (RemexHTML) ter vergelijking naast elkaar kunt zien. Je kunt ook hiermee ook bewerkingen vooraf bekijken en zien hoe die de opmaak van de pagina veranderen.
Wat zijn de gevolgen voor mijn wiki?
Lees wikitext hulpmiddel. In enkele gevallen slaat de teller op het aantal pagina's met dat probleem, maar dat is inclusief teksten die door sjablonen zijn gegenereerd. Met een correctie van één sjabloon kan dus de lijst met problemen flink afnemen. Pas dus eerst sjablonen aan om een beter overzicht te krijgen van de probleemgevallen. Er wordt aangewerkt om dit nog duidelijker te maken. U kunt de voortgang ook hier zien: Parsing/Replacing Tidy/Linter/Stats en de resultaten van visuele verschillen op de steekproef van circa ~73K artikelen van 60 wiki's op http://mw-expt-tests.wmflabs.org/ .
Vereenvoudigde instructies voor verbeteren van pagina's
Hier staan die instructies voor het afhandelen van de categorieën met de hoogste prioriteit. Enkele van de gelinkte helppagina's kunnen instructies bevatten om hulpmiddelen als WPCleaner te gebruiken.
Verwijder of herstel verkeerd geneste tabellen
{| <-- 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
|}
In dit voorbeeld verwijdert Tidy Table 2. In RemexHTML blijft deze table staan. Hierdoor zijn de pagina's er anders uit. Om dit te voorkomen zouden schrijvers de wikitext moeten aanpassen en Table 2 verwijderen. De volgende tag row hoeft niet weg, maar we bevelen het verwijderen daarvan wel aan. De close-tag is dan immers overbodig.
Je kunt ook een expliciete | cel op de row toevoegen die start bij de vorige regel voor het begin van Table 2 als je tables moet nesten. De juiste oplossing hangt af van per pagina. De voorkeur lijkt de eerste methode.
Oplossing voor de fout in de parser bij een huls om een alinea
Het lijkt bij de meeste wiki's, dat de meeste waarschuwingen bij de liniaal (linter) veroorzaakt worden door de sjablonen nowrap en nowrap begin. De eenvoudigste oplossing, die in de meeste gevallen zal werken, is een nieuwe regel toe te voegen voor de open tag <span> tag in het sjabloon zelf.
In de andere gevallen, als wikitext een span volgend op een blok-tags als div/td heeft en een white-space:nowrap CSS eigenschap, voeg dan een nieuwe regel toe na de tag 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>
Verbeteren ongeldige zelf-sluitende tags
Dit zijn tags als <div />, <span />, <b />, enz. die zijn niet geldig in HTML5.
Ze moeten aangepast worden naar wat de bedoeling zal zijn geweest. Soms is het een tikfout en wordt </b> bedoeld. In andere gevallen moeten ze worden verwijderd. In enkele gevallen moeten ze worden worden vervangen door een <nowiki />. Hier is een eigen helppagina voor.
Verbeteren pagina's met een fout in de Tidy whitespace
| Invoer wikitext | Tidy uitvoer | Remex uitvoer | Voorgestelde wikitext aanpassing |
|---|---|---|---|
<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>
|
Verbeteren problemen HTML5 met Tidy verkeerd geneste tags
Een voorbeeld van het probleem.
| Invoer wikitext | Tidy uitvoer | Remex uitvoer | Voorgestelde wikitext aanpassing |
|---|---|---|---|
<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.
tag font met attribuut color bevattende wikilinks
Here is an example to illustrate the problem.
| Wikitext | Tidy | Remex | Voorgestelde aanpassing |
|---|---|---|---|
<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.
Meerdere niet afgesloten opmaak tags
| Wikitext | Voorgestelde aanpassing |
|---|---|
<s>foo<s> bar
|
<s>foo</s> bar
|
HTML tabel met meerdere regels in lijsten
| Wikitext | Tidy | RemexHTML | Voorgestelde aanpassing |
|---|---|---|---|
* <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
|
Niet afgesloten quotes in kop
| Wikitext | Voorgestelde aanpassing |
|---|---|
text
==''foo==
bar
|
text
==''foo''==
bar
|
Waarschuwingen
- We weten op dit moment niet hoe we automatisch alle pagina's en sjablonen die aangepast moeten worden kunnen opsporen, maar we verwachten dat de lijst 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 <pre /> en vergelijkbare tags als je ze zelfsluitend gebruikt?
Antwoord: Zoals in T134423 aangegeven, de enige geldige zelfsluitende HTML-tags zijn: area, base, br, col, embed, hr, img, input, keygen, link, meta, param, source, track, wbr.
De wijziging heeft geen gevolgen voor zelfsluitende tags die niet bij HTML horen zoals <references /> en <nowiki />. Een bijzonder geval is <pre> - ook al is het een HTML-tag, in MediaWiki wordt het als een eigen tag behandeld zodat de wijziging hiervoor ook geen gevolgen heeft. Alle andere zelfsluitende HTML-tags moeten worden aangepast, en dat aanpassen loopt al.
Bij onze test zijn in veel pagina's zelfsluitende tags gevonden die na de overgang tot onverwachte effecten bij het renderen kunnen leiden, zoals <b /> dat opgevat gaat worden als <b> 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 <b /> wordt omgezet in <b></b>. 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. Lees dez pagina, en voeg het aan je bladwijzers toe, toekomstige verzoeken gaan via die pagina!
- Ik wil wel de uitbreiding ParserMigration wel testen.
- (hieronder je ondertekening toevoegen)
- ...
- ...
- Ik wel wel helpen om sjablonen aan te passen.
- 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)
- Ik wil wel helpen om aanpassingen van sjablonen uit te zoeken en met anderen te bespreken.
- 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)
- Ik wil wel helpen om mijn gemeenschap voor te lichten.
- (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)