From: "Platonides" &lt;platonides(a)gmail.com&gt; Or of course: e) Render it literally without making it look ridiculous. Here's my thoughts on the above options: a) No - use (e) instead. b) Never refuse to save c) This is a possibility. However we would need to make this behaviour consistent across the whole parser, e.g. <pre> tags inside a paragraph should be treated as in-line as well. This would possibly be quite useful, but would no doubt break existing pages. It is also conceptually a bit confusing and may cause problems with the default styling rules (which add padding and borders etc. which may look pretty bad for in-line elements). d) I don't think this is a good idea - it almost certainly isn't what was wanted and makes the problem harder to track down. e) The one I would choose if (c) is not viable. - Mark Clements (HappyDog)

On 12/7/07, Mark Clements &lt;gmane(a)kennel17.co.uk&gt; wrote: Let's just rule this out once and for all. We're talking about how the parser renders code, so "refusing to save" never comes into it. The code is already there, saved, so how do we render it? The trouble with pretending that an in-line <pre> is actually an inline text is this: ---- Some text<pre>foo blah blah</pre> whatever. ---- I'm going to have to read up on the fine points between "inline" tags and "block" tags, but that one strikes me as a bit of both. A quick note on how I see <pre>: * <nowiki> turns off parsing, but renders normally * A space-indented block renders as <pre> but parses normally (at the mediawiki level) * <pre> renders as <pre> *and* turns off parsing. * <tt> renders sort of like <pre>, but the browser parses it normally (I think) So if inline <pre> is weird from a rendering point of view, how should it parse? Just like <nowiki>? Hmm. So are we saying that <pre> has to be at the start of a line, or just not in a caption, or what? It would seem reasonable to me that [[foo|<pre>blah</pre>]] render as a literal ...&lt;pre&gt;blah.... Is any useful behaviour likely to be lost? Steve