Can you give some examples of what should behave differently?  It is aware of CSS 'white-space' values, and in some places treats 'pre'/'pre-wrap'/etc. differently (at least for whitespace handling).  insertParagraph also treats address/listing/pre differently from other block elements.

Created attachment 1139 [details]
demo

(In reply to comment #1)
> Can you give some examples of what should behave differently?  It is aware of
> CSS 'white-space' values, and in some places treats 'pre'/'pre-wrap'/etc.
> differently (at least for whitespace handling).  insertParagraph also treats
> address/listing/pre differently from other block elements.

Sure. As you point out, white-space: pre, white-space: pre-wrap, etc... should be treated like pre here but, indent command for example should treat each line in pre so if we executed indent command with the following selection:

<pre>
[hello]
world
</pre>

We should get

<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
<pre>hello</pre>
</blockquote>
<pre>world</pre>

or
<pre>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">
hello
</blockquote>
world
</pre>

Gecko appears to indent the whole block (hello & world) but that doesn't seem right from user's perspective because there's no visual difference between the above markup and

<span style="white-space: pre">hello<br>
world</span>

with which Gecko gladly indents "hello".

Good point.  I was actually thinking about whether we want that behavior for <br>, though.  If I use Shift-Enter to get "<p>foo<br>bar</p>", should that really be treated as two blocks instead of one?  It is in browsers, but I'm not sure that makes sense.  "<li>foo<br>bar</li>" is treated as one block, but "<p>foo<br>bar</p>" is not . . .

I don't disagree, though.  As long as we have this behavior for <br>, we should have it for <pre>.  However, the spec and Gecko currently don't actually produce literal linebreaks in <pre>: hitting Enter inside <pre> generates <br>.  And WebKit splits it into multiple <pre>s, like <p> or <div>.  So the only way you'd get literal \n in <pre> is if the preexisting HTML had it, right?  This strikes me as a low-priority use-case.

(In reply to comment #3)
> Good point.  I was actually thinking about whether we want that behavior for
> <br>, though.  If I use Shift-Enter to get "<p>foo<br>bar</p>", should that
> really be treated as two blocks instead of one?

I think it should be. As far as naive users are concerned, "p" is a "br" with extra margins.

> It is in browsers, but I'm not
> sure that makes sense.  "<li>foo<br>bar</li>" is treated as one block, but
> "<p>foo<br>bar</p>" is not . . .

In the case of a list item, there is a bullet point (with default css), so it probably makes senes to treat each bullet pointed item as a single entity.

> I don't disagree, though.  As long as we have this behavior for <br>, we should
> have it for <pre>.  However, the spec and Gecko currently don't actually
> produce literal linebreaks in <pre>: hitting Enter inside <pre> generates <br>.
>  And WebKit splits it into multiple <pre>s, like <p> or <div>.  So the only way
> you'd get literal \n in <pre> is if the preexisting HTML had it, right?  This
> strikes me as a low-priority use-case.

I think I would be fine if you just inserted <br> at wherever \n appears as some sort of a pre-processing step. Once you support treating-br-as-paragraph-separator (misnomer but can't think of a better phrase), then it should just work regardless of whether we're in pre or not.