[Wikitext-l] The <pre> tag

[Steve Bennett]

On 12/7/07, Mark Clements <gmane at 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 ...&lt;pre&gt;blah.... Is
any useful behaviour likely to be lost?

Steve