Re: Pressing Enter in contenteditable: <p> or <br> or <div>?

BCC: whatwg, CC:public-webapps since discussion of the editing spec has
moved

I'm OK with this conclusion, but I still strongly prefer "div" to be the
"default single-line container name". Also, I'd really like the "default
single-line container name" to be configurable in some way. Different apps
have different needs and it's crappy for them to have to handle enter
themselves just to get a different block type on enter.

Something like document.execCommand("DefaultBlock", false, tagName). What
values are valid for tagName are open to discussion. At a minimum, I'd want
to see "div", "p" and "br". As one proof that this is valuable, the Closure
editor supports these three with custom code and they are all used in
different apps. I'm tempted to say that any block type should be allowed,
but I'd be OK with starting with the tree above. For example, I could see a
use-case for "li" if you wanted an editable widget that only contained a
single list.

Ojan

On Mon, May 30, 2011 at 1:16 PM, Aryeh Gregor <Simetrical+w3c@gmail.com>wrote:

> On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor <Simetrical+w3c@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).
> >
> > What behavior do we want?
>
> I ended up going with the general approach of IE/Opera:
>
>
> http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements
>
> 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):
>
>
> http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command
>
> 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
> autoimplementation.html:
>
> http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph
>