[whatwg] Pressing Enter in contenteditable: <p> or <br> or <div>?

On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor  
<Simetrical+w3c at gmail.com> wrote:

> Behavior for Enter in contenteditable in current browsers seems to be
> as follows:
>
> * IE9 wraps all lines in <p> (including if you start typing in an
> empty text box).  If you hit Enter multiple times, it inserts empty
> <p>s.  Shift-Enter inserts <br>.
> * Firefox 4.0 just uses <br _moz_dirty=""> for Enter and Shift-Enter,
> always.  (What's _moz_dirty for?)
> * Chrome 12 dev doesn't wrap a line when you start typing, but when
> you hit Enter it wraps the new line in a <div>.  Hitting Enter
> multiple times outputs <div><br></div>, and Shift-Enter always inserts
> <br>.
> * Opera 11.10 wraps in <p> like IE, but for blank lines it uses
> <p><br></p> instead of just <p></p> (they render the same).

I think the <br> is a filler so that there's something for the user to  
click and focus on to get the insertion point inside the <p>. IE use  
&nbps; for this instead. Opera has a bug where you have to press ENTER  
then backspace and then enter again to get rid of the <br> at the end of  
the element sometimes.

If the default content (innerHTML more or less) of the contentEditable  
element is <div><br></div> (like in  
<http://shadow2531.com/opera/testcases/designmode/000.html>), Opera will  
use DIVs when pressing enter (and <br> when pressing shift + enter).

> A problem with <p> is that it has top and bottom margins by default,
> so hitting Enter once will look like a double line break.

Ideally, users should realize that it's an editable part of a web page and  
that pressing ENTER once closes the current paragraph and starts a new  
one. They should also realize that the margins are part of the paragraphs,  
which causes them to be visually separated from other elements and that  
they don't need to do that manually by pressing ENTER again. These are not  
textareas or plain text editors after all.

> Another problem with <p> is that it's very easy to create
> unserializable DOMs with it.  I've seen cases where at least some
> browsers will put things inside <p> that will break out of the <p>,
> and I've done it myself by mistake too.

I think the browser/editor just shouldn't allow that in this case. (Not  
saying that it's easy to enforce it though.)

> What behavior do we want?

<p> makes the most sense ideally. However, if the editor needs to pose as  
a line-based text editor, <br> makes the most sense. But, <p> styled with  
0 margins or <div> would be better than <br> if there's a desire to group  
lines. If there is a desire to group lines, <p> will still be a little  
more semantic, but <div> will be easier as it can rely on default styles  
and doesn't have the unserializable dom issue. But, either way, <p></p> or  
<div></div> will still be used for blank lines, which doesn't seem ideal.

> So my current thought is to demarcate lines with <div>s consistently,
> only using <br> when there are multiple line breaks in a row.

So, if I type "Line 1" and press ENTER twice and then type "Line 3", I'd  
get:

<div>Line 1<br><br></div>
<div>Line 3</div>

?

-- 
Michael

Received on Friday, 13 May 2011 03:00:21 UTC