Some years back I was importing a large number of complex templates to a wiki that didn't have tidy enabled. The results were nothing short of horrendous in a substantial number of cases. Wiki authors will generally stop worrying about their code as long as the results look right. For good or ill, tidy does a remarkable job of localizing unclosed tags, and often that is enough to effectively fix the appearance of broken HTML syntax so it doesn't spill over into other sections. Without Tidy (or its equivalent) there will be a lot of template garbage that needs to be repaired.
The garbage in -> garbage out approach might seem appealing in principle, but any transition to such a condition is going to dredge up a lot of malformed HTML code created by wiki editors that we've been hiding for many years. If one is going to replace Tidy with something substantially different in execution, I would suggest that one needs a significant test suite of complex pages in order to judge how bad the collateral damage is likely to be, and ideally some set of tools to help editors fix it.
-Robert Rohde
On Thu, Aug 13, 2015 at 7:51 AM, Brian Wolff bawolff@gmail.com wrote:
On 8/12/15, MZMcBride z@mzmcbride.com wrote:
Tim Starling wrote:
https://phabricator.wikimedia.org/T89331
Running the output of the MediaWiki parser through HTML Tidy always seemed like a nasty hack. The effects on wikitext syntax are arbitrary and change from version to version. When we upgrade our Linux distribution, we sometimes see changes in the HTML generated by given wikitext, which is not ideal.
[...]
We can get nearly the same effect in MediaWiki by replacing the Tidy transformation stage with an HTML 5 parse followed by serialization of the DOM back to HTML. This would stabilize wikitext syntax and resolve several important syntax differences compared to Parsoid.
Related tasks:
It's not clear to me which behaviors from Tidy we want to keep. Looking
at
the various bugs that Tidy has caused, it's apparent that there a number of behaviors we want to disable/avoid.
My understanding is that Tidy is not responsible for output sanitization and it's not responsible for preprocessing or parsing. MediaWiki handles all of that elsewhere. If Tidy is only needed for mismatched HTML elements, we could possibly catch and disallow or gracefully handle that specific use-case in MediaWiki. What other beneficial behavior of Tidy would we need to replicate?
Or could we replace Tidy with nothing? Relying on the principle of "garbage in, garbage out" seems reasonable in some ways. And modern browsers are fairly adept at handling moderately bad HTML.
MZMcBride
The main thing tidy does (imo), is ensure that mismatched html fails are localized. When somebody makes a mistake, it can cause the entire skin to go whacko. We ideally want to have markup mistakes only affect the user generated content (and preferably, only around the area where the mistake is).
--bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l