On 12/7/07, Mark Clements gmane@kennel17.co.uk wrote:
b) Never refuse to save
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?
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).
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>?
e) Render it literally without making it look ridiculous.
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 ...<pre>blah.... Is any useful behaviour likely to be lost?
Steve