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

On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai <ojan@chromium.org> wrote:

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

Why?

> Also, I'd really like the "default
> single-line container name" to be configurable in some way.

I agree.

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

What is the use case for "br" that "div" doesn't cover?

> As one proof that this is valuable, the Closure
> editor supports these three with custom code and they are all used in
> different apps.

Which apps use "br"? Could they switch to "div" without losing some  
functionality?

> I'm tempted to say that any block type should be allowed,

I strongly disagree. Supporting any block type opens up for lots of bugs  
and weird cases. We should only support the types necessary to cover  
presented use cases.

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

Just use <ul contenteditable><li>|</li></ul>. "li" as defaultblock would  
result in invalid markup if there's no list (and when breaking out of a  
list, etc).

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


-- 
Simon Pieters
Opera Software

Received on Monday, 9 January 2012 08:00:24 UTC