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(a)gmail.com> wrote:
On 8/12/15, MZMcBride <z(a)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:
*
https://phabricator.wikimedia.org/T4542
*
https://phabricator.wikimedia.org/T56617
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l