thecentercannothold wrote:

I'll add that I have had problem with tidy repeatedly when dealing with div-based templates. As nearly as I can figure, if a template transcludes a div that contains a carriage return, like so:

<div style="border:thin blue solid;">
this is the transcluded text
</div>

and then that template is indented using wikitext:

:{{template call}}

the resulting HTML will muck up the div tags, adding spurious opening or closing divs; something like, for example:

<dl>
<dd>
<div style="border:thin blue solid;">
</dd>
</dl>
<div>
this is the transcluded text
</div>

I've seen the same effect with other tags - for instance:

:<pre>line one
line two
line three</pre>
will close the pre block after the first line rather than continuing through to the closing pre tag that is given.

conrad.irwin wrote:

While it sounds like it might be fun to have, this would not acheive anything; granted, you'd be able to blame Tidy more accurately, but you can do this pretty well anyway, it seems.

The main problem with this is that NOTIDY would get included onto articles containing templates that work with Tidy running, which would break them.

If you want to see how MediaWiki works without tidy, just install a MediaWiki, you can get them for free, or find a wiki that doesn't enable tidy and borrow their sandbox.

Fixes to the parser are always appreciated, but don't forget that there's almost certainly a few billion templates on en.wikipedia that are built to work correctly by using every existing "bug".

ayg wrote:

Concur with Conrad, we don't want to serve non-Tidied pages on production sites. A special page or API parameter that would render a given page without Tidy might be a good idea, though, like [[Special:ExpandTemplates]].

happy.melon.wiki wrote:

An option on ExpandTemplates would be sufficient. Concur that allowing such a switch to get out 'into the wild' would be a Bad Idea.

After further thought, I also have to agree that the switch approach is not a good idea in this case, and would be happy with the suggested switch on Special:ExpandTemplates.

However, I do have to disagree with a couple things Conrad said: First, this most certainly *would* achieve something, since many of our most complicated - and most ported - templates rely on Tidy to display correctly, it requires reusers to either install Tidy, or to find a version of the template designed to work without it (or, more often, to develop such a version themselves). And second, Tidy only influences output, it doesn't have any effect on how the parser works (and fixing only the parser's output should not (in theory) break any template which relies on bugs in how the parser handles input). Therefore, while disabling Tidy would, in some cases, break output, it would not change how templates actually work.

(In reply to comment #5)

After further thought, I also have to agree that the switch approach is not a
good idea in this case, and would be happy with the suggested switch on
Special:ExpandTemplates.

However, I do have to disagree with a couple things Conrad said: First, this
most certainly *would* achieve something, since many of our most complicated -
and most ported - templates rely on Tidy to display correctly, it requires
reusers to either install Tidy, or to find a version of the template designed
to work without it (or, more often, to develop such a version themselves). And
second, Tidy only influences output, it doesn't have any effect on how the
parser works (and fixing only the parser's output should not (in theory) break
any template which relies on bugs in how the parser handles input). Therefore,
while disabling Tidy would, in some cases, break output, it would not change
how templates actually work.

It won't change how they work, but it will change the output, and that's all that matters to users. We've been fixing output with Tidy for years, and people have come to rely on it, whether they know it or not. Should we all write templates that don't rely on Tidy? Yep. Would be nice if we didn't need Tidy? Of course.

I do think a toggle on ExpandTemplates would be very useful, though. Wouldn't be surprised if we find some parser bugs long-obscured by Tidy after opening this up ;-)

We already know of a few parser bugs that Tidy corrects; edit notices and system messages, for instance, get served to the user verbatim, without a Tidy run - this results in things like bug 17486.