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

[Markus Ernst]

Am 12.05.2011 22:28 schrieb Aryeh Gregor:
> 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>.

This is what people know from MS Word, too, and thus it should be 
considered as a de-facto standard. I don't have current versions of 
other office text editors installed right now, but I assume they will 
behave the same, or at least provide a setting to make them behave like 
that.

I have seen content management systems where text editors tweak the 
enter key to behave the same also in non-IE UAs (e.g. if you use 
Contenido with TinyMCE, Firefox produces the same output as IE when you 
hit enter).

I'd strongly suggest to spec this behaviour, or at least provide some 
kind of setting to force it.

> * 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).
>
> What behavior do we want?
>
> 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.  One
> real-world execCommand() user I looked at (vBulletin) sets p { margin:
> 0 } for its rich-text editor for this reason, and translates<p>  and
> <div>  to line breaks on the server side.  The usual convention in text
> editors is that hitting Enter only creates one line break, although
> Word 2007 seems to do two by default.

This is very presentational thinking. If you write a text, it should be 
possible to produce paragraphs by default. If you use <div> instead of 
<p>, there would be extra coding needed to make paragraphs available.

> 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.

The same applies e.g. for list items, UAs have to solve this problem 
anyway. One approach that I could imagine is to close and re-open the 
paragraph (resp. list item) at the boundaries of the element which is 
put inside it.