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

[Aryeh Gregor]

On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Note that br and div affect UBA differently so we must consider what
> bidirectional text users want as well.
> For example, if we had <div dir="rtl">hello</div>, and inserted br as in
> <div dir="rtl">hello<br></div>, then we preserve the RTL directionality.  If
> we insert div on the other hand, <div dir="rtl">hello</div><div></div>, then
> new paragraph will have the containing block's direction.
> This will be a tricky issue when people want to mix LTR/RTL paragraphs in
> the same editable region.

If we had <div dir=rtl>hello</div>, a new line should become <div
dir=rtl>hello<div></div></div>, not <div
dir=rtl>hello</div><div></div>.  As far as I understand it, we don't
have interop on bidi handling for <br>, so that's an argument against
it:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10828

Test-case courtesy of Aharon Lanin:

א --><br>--> ב

In IE and WebKit the arrows point right, in Gecko and Opera they point
left.  With a <div>, they point right in all browsers.

But this is an argument against using <br> at all, even for Shift-Enter.

> I strongly feel that we should default to div for the backward
> compatibility.  And this is the preferred paragraph separator in many Google
> products as far as I know because div allows developers to easy apply style,
> add class, etc... to a paragraph.  And there seems to be a long history of
> browsers inserting inserting p/div on Enter and inserting br on Shift+Enter
> (on Windows), and changing that behavior will confuse users who are used to
> this behavior.

Gecko has never done this, so there can't be very bad back-compat
issues (any more than any standardization here poses).  Having Enter
and Shift+Enter produce exactly the same visual effect but different
markup, as WebKit does, seems very confusing.  If we were to go with
<div>, it should be across the board, with no <br>s produced at all.

On Fri, May 13, 2011 at 2:25 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> innerHTML uses OutputRaw which ensures that no prettyprinting happens ever,
> no matter what, even if a gun is held to the serializer's head. In
> particular, it overrides the _moz_dirty flag.
>
> Similar for copy/paste.
>
> I would suspect that there is no web-observable serialization behavior that
> depends on _moz_dirty.

Hmm, okay.  So it's not an issue I have to care about.  (Although of
course when I eventually write a real test suite, this will make Gecko
fail lots of tests.  But everyone will fail pretty much all the tests
at first anyway, given the state of contenteditable today, so . . .)

> This code exists for an HTML editor.  There's no round-tripping involved.
>  You're just editing some HTML.

In web content, pretty much the only reason people have HTML editors
is so they can submit the content to a server, presumably using
innerHTML.  The story for non-web-exposed stuff is of course
different, but it's not relevant to specs.