This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 17241 - Editing API spec needs to be aware of PRE contents
Summary: Editing API spec needs to be aware of PRE contents
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-05-30 05:02 UTC by Ryosuke Niwa
Modified: 2013-02-04 02:14 UTC (History)
2 users (show)

See Also:


Attachments
demo (271 bytes, text/html)
2012-05-31 16:52 UTC, Ryosuke Niwa
Details

Description Ryosuke Niwa 2012-05-30 05:02:42 UTC
It appears that the current specification doesn't do anything special for PRE elements. It needs to be fully aware of PRE elements, and treat each line in PRE as a separate paragraph.
Comment 1 Aryeh Gregor 2012-05-31 11:32:46 UTC
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.
Comment 2 Ryosuke Niwa 2012-05-31 16:52:19 UTC
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".
Comment 3 Aryeh Gregor 2012-06-01 11:19:26 UTC
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.
Comment 4 Ryosuke Niwa 2012-06-01 18:11:17 UTC
(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.