[whatwg] Pressing Enter in contenteditable: <p> or <br> or <div>?
Simetrical+w3c at gmail.com
Mon May 30 13:16:55 PDT 2011
On Thu, May 12, 2011 at 4:28 PM, 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
> * 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?
I ended up going with the general approach of IE/Opera:
It turns out WebKit and Opera make the insertParagraph command behave
essentially like hitting Enter, so I actually wrote all the
requirements there (IE's and Firefox's behavior for insertParagraph
was very different and didn't seem useful):
The basic idea is that if the cursor isn't wrapped in a single-line
container (address, dd, div, dt, h*, li, p, pre) then the current line
gets wrapped in a <p>. Then the current single-line container is
split in two, mostly. Exceptions are roughly:
* For pre and address, insert a <br> instead of splitting the element.
(This matches Firefox for pre and address, and Opera for pre but not
address. IE/Chrome make multiple pres/addresses.)
* For an empty li/dt/dd, destroy it and break out of its container, so
hitting Enter twice in a list breaks out of the list. (Everyone does
this for li, only Firefox does for dt/dd.)
* If the cursor is at the end of an h* element, make the new element a
<p> instead of a header. (Everyone does this.)
* If the cursor is at the end of a dd/dt element, it switches to dt/dd
respectively. (Only Firefox does this, but it makes sense.)
Like the rest of the spec, this is still a rough draft and I haven't
tried to pin corner cases down yet, so it's probably not advisable to
try implementing it yet as written. As always, you can see how the
spec implementation behaves for various input by looking at
More information about the whatwg