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

Tue May 17 12:50:26 PDT 2011

On Tue, May 17, 2011 at 3:04 AM, Markus Ernst <derernst at gmx.ch> wrote:
> If the behavior is settable, it might even be a good idea to leave the
> choice of the standard behavior to the UAs. Authors who have a reason to
> care can set their preferred behavior, while other authors might prefer to
> leave it as it was, so there is no change for their existing users.

We can't leave the default behavior undefined for something like this.
 It affects interoperability, and there's no reason browsers should
differ ("we can't make up our mind" is not a good enough reason).

On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> I completely disagree. As a user, I want semantics when I write my blog
> entry on WordPress so that I can tweak presentation afterwards.  e.g. I have
> frequently used em {font-style: normal; font-weight:bold;} strong
> {text-decoration:underline; font-weight: normal;} in the past.

Then the commands will completely break no matter what you do, because
they're tied to the CSS, not the HTML element.  For instance, in this
test case:

<!doctype html>
<style>
em { font-style: normal; font-weight: bold }
</style>
<div contenteditable><em>Hello</em></div>
<script>
var text = document.querySelector("em").firstChild;
getSelection().collapse(text, 1);
getSelection().extend(text, 4);
document.execCommand("bold");
</script>

Chrome 12 dev produces <em>H<span class="Apple-style-span"
style="font-weight: normal;">ell</span>o</em>.  If you change the
command from "bold" to "italic", it becomes <em>H<i>ell</i>o</em>.
These commands are specifically presentational, tied to CSS rather
than HTML, which is reflected both in their name and function.

There are other commands that are semantic, like heading or
insertOrderedList.  But you definitely cannot sanely use <em> for bold
with this API.  We'd have to add new commands like "emphasize" to
allow that.

> And when I press enter, I want a paragraph separator NOT a line break.

WebKit outputs <div>, but a paragraph separator should be <p>.

On Tue, May 17, 2011 at 3:26 AM, Markus Ernst <derernst at gmx.ch> wrote:
> Imagine a content of the contenteditable element like:
>
> <div><div><p>Foo</p></div></div>
> <div><p>Bar</p></div>
>
> The user puts the caret to the end of the first line and clicks Enter. With
> a strict <p>/<br> behavior, this is a well-defined action, adding a new
> paragraph resp. inserting a newline. But if you go with <div>s, this will
> possibly mess up the code in a way that is hard to fix (though it is valid
> and serializable HTML).

Yeah, <p> has the advantage over <div> that <div> is used for lots of
things, and it might be nice to distinguish.  I don't know.  Since
there are no really good arguments I can see in any direction, I guess
it makes the most sense to standardize the plurality position, namely
some variant of IE/Opera (<p> on Enter and <br> on Shift-Enter), with
switches to allow authors to change from the default.  I added it as
an issue to the spec, and will probably look at it reasonably soon:

http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=70be7878