Currently RemexDriver does not implement validate(), so MWTidy:checkErrors() throws an exception. The function is used in MediaWikiTestCase::assertValidHtmlDocument() and OutputHandler (if $wgValidateAllHtml = true;).
|mediawiki/core||master||+7 -180||Immediately drop wgValidateAllHtml and related code|
|Resolved||Arlolra||T109897 Table parsing diffs: Parsoid adds implicit <td>s after a |- if explicit pipe is not present|
|Resolved||Arlolra||T109650 Minor P-wrapping diff between Parsoid & PHP Parser+Tidy combo|
|Resolved||Arlolra||T110004 DOM Pass for wrapping bare text found in <body> and other "block" (in html4-parlance) nodes like <blockquote>, <td>, <th>.|
|Declined||None||T65699 Parsoid and Tidy differ in how they deal with misnested tags|
|Declined||ssastry||T69452 Empty elements in DOM: PHP parser+tidy strips them; Parsoid doesn't|
|Resolved||ssastry||T175706 Progressively switch Wikimedia wikis from Tidy to RemexHTML|
|Open||None||T49544 <references/> list item must not wrap the text in <span>|
|Resolved||tstarling||T89331 Replace HTML4 Tidy in MW parser with an equivalent HTML5 based tool|
|Resolved||Jdforrester-WMF||T185753 MediaWiki should default to using RemexHtml for tidy|
|Resolved||Jdforrester-WMF||T191670 Determine future of MWTidy::checkErrors in a Remex world|
It isn't clear what "validate" is supposed to be doing. In the Tidy world, it seems to be checking that Tidy doesn't crash.
HTML5 spec has the notion of parse errors, but as expected, given that browsers encounter all kinds of html out in the wild, the html5 parser provides error recovery conditions for parse errors. Parse errors are only relevant for conformance checkers that might abort parsing on the first error, but is not a suitable response for browsers or wikitext parsers.
Looks like the capiunto extension uses this. As far as I can tell, the use in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/Capiunto/+/master/tests/phpunit/output/BasicRowTest.php#42 isn't really testing anything interesting. It seems like defensive code. BasicRowTest.lua just creates a table with a header and a row.
So, given that the lone use case is basically useless, I support legoktm's proposal to get rid of this mode from testing.