Add __NOTIDY__ magic word for template testing and troubleshooting
Closed, DeclinedPublic

Description

Tidy is a great piece of software which takes much of the burden of worrying about correct markup off of the average editor. At the same time, though, there are areas where Tidy provides broken output, especially when combined with MediaWiki's parser, which itself outputs invalid HTML in some circumstances (the proof for this is the requirement for Tidy in the first place - a perfect parser would be able to turn even the most ugly, broken, scrambled wikimarkup into 100% valid HTML, and a very good one would be able to cover 99% of common wikimarkup cases).

These problems become most readily obvious in template editing, particularly when it is used to supplement or fix various built-in features of MediaWiki, such as cite.php - for an example of this, see [[User_talk:Gadget850/Reference_templates#Highlight]]. Per Gadget850's comment there, then, I'd like a NOTIDY magic word implemented which disables the page output being passed through Tidy prior to delivery to the end user.


Version: unspecified
Severity: enhancement

bzimport added a project: MediaWiki-Parser.Via ConduitNov 21 2014, 11:03 PM
bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz22786.
Dinoguy1000 created this task.Via LegacyMar 9 2010, 8:06 PM
bzimport added a comment.Via ConduitMar 16 2010, 12:31 AM

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.

bzimport added a comment.Via ConduitMar 16 2010, 1:42 PM

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".

bzimport added a comment.Via ConduitMar 16 2010, 4:51 PM

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]].

bzimport added a comment.Via ConduitMar 16 2010, 5:04 PM

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.

Dinoguy1000 added a comment.Via ConduitMar 16 2010, 9:34 PM

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.

Chad added a comment.Via ConduitMar 16 2010, 9:39 PM

(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 ;-)

Dinoguy1000 added a comment.Via ConduitMar 17 2010, 1:39 AM

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.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.