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

Wed May 18 11:09:39 PDT 2011

On Fri, May 13, 2011 at 12:26 PM, Aryeh Gregor <Simetrical+w3c at gmail.com>
 wrote:

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

Disagree. I think it should be come <div dir=rtl>hellow</div><div
dir=rtl></div>. Nesting seems really bad to me. It results in a more
complicated DOM that makes scripting against the resultant DOM extremely
difficult.

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

> On Fri, May 13, 2011 at 6:29 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
> > I think this is a problem that we should solve anyway, since we can't
> avoid
> > splitting nodes in the general case.  Once we have an algorithm for that,
> we
> > can just use it wherever necessary, right?
> >
> > You can look at the nsEditor::SplitNodeImpl algorithm used in Gecko here:
> > <
> http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/base/nsEditor.cpp#2698
> >.
> >  I'm sure WebKit includes a similar algorithm...
>
> I've got an algorithm, but since it can cause problems, I'd prefer to
> use it only where really necessary.  So far I've gone to some pains to
> avoid it, and for inline markup I've succeeded across the board.
> E.g., if you run "bold" on
>
>  <b id=x>foo[bar]baz</b>
>
> then in Firefox 4.0 and Opera 11.10 you get <b id=x>foo</b>bar<b
> id=x>baz</b> (duplicate id), in Chrome 12 dev you get <b
> id=x>foo</b>bar<b>baz</b> (id lost on one element), and in IE9 you get
> <strong>foo</strong>bar<strong>baz</strong> (both id's lost).  The
> spec's algorithm produces <span id=x><b>foo</b>bar<b>baz</b></span>,
> which I think preserves the markup about as well as you possibly
> could, although of course it's a bit longer.
>
> But to be honest, the only way to decide correct behavior here is to
> try figuring out what authors are using these extra attributes for,
> and what they expect to happen.  I can't imagine it's common to use
> id's in contenteditable, and I don't really know what the expected
> behavior is if you do.  Maybe we shouldn't worry about it.
>

We need to address this case. For example, Google Docs, before it stopped
using contentEditable, used IDs in the user-editable content to help scope
what data needed syncing. The Google Closure Editor uses classnames and data
attributes to store extra metadata (e.g. that a div is actually a container
for an image+caption widget). Also, we should be preserving inline styles.

We should copy all attributes and have a blacklist of uncopyable attributes.
ID is the only one I can think of off the top of my head that needs
blacklisting.

> On Fri, May 13, 2011 at 3:11 AM, Simon Pieters <simonp at opera.com> wrote:
> > On Thu, 12 May 2011 22:28:47 +0200, Aryeh Gregor <
> Simetrical+w3c at gmail.com>
> > wrote:
> >> * IE9 wraps all lines in <p> (including if you start typing in an
> >> empty text box).
> >
> > Can't reproduce. If I start typing in an empty <body contenteditable>,
> > there's no <p> until I hit enter.
>
> Yes, but when you hit Enter it wraps the first line in a <p> too, not
> just the second line.  In WebKit it only wraps the second line in a
> div.
>

IMO, WebKit's behavior here is wrong. When you hit enter not in a block
context, it should put all the inlines + text in two separate divs.

> I don't really think we want to nest stuff here, it leads into weird
> markups
> > and most likely werid layouts (think of an editable area with a
> margin-left
> > for paragraphs/divs.)
>
> Adding margins to paragraphs and divs wouldn't behave very reliably
> unless they were inserted around text very consistently.  Otherwise
> you'd have some text indented and some not.  So I guess we can ask a
> further question: if we use <div> or <p>, do we want to try
> guaranteeing that all runs of text will be wrapped in the chosen
> element?  For instance, WebKit doesn't wrap in <div> very consistently
> at all, IE and Opera don't nest <p> inside <li>.  So you can't depend
> on all your text being wrapped in the element anyway.
>

Opera's behavior here seems right to me. If I understand correctly here's
what Opera does:
enter without a parent block: wrap everything in two block elements as
defined by the opera-defaultblock execCommand.
enter with a parent block: split the parent block
shift+enter: insert a BR
enter inside a header: breaks out of the header and inserts a block as per
the opera-defaultblock execCommand (this is just legacy we're stuck with
from IE5+)

I believe that most users expect the styling of the block to remain the same
when they hit enter. If you are in a paragraph with margins, hitting enter
should give you two paragraphs with margins. However, I agree the the
default expected behavior is that enter will insert a single linebreak,
which is why I support DIV being the default block value.

The tricky bit here is what to do when the user copy-pastes. I think we
should convert P to DIV or vice versa as per whatever the defaultblock value
is. We should also give an execCommand to allow the website to disable this
behavior.

> On Mon, May 16, 2011 at 9:33 AM, Markus Ernst <derernst at gmx.ch> wrote:
> > This is very presentational thinking.
>
> Correct.  This API was designed and is used presentationally, not
> semantically.  Both authors and users want presentational formatting
> here.  That's why it's called "What You *See* Is What You Get".

As I've said on the other related thread. I agree contentEditable is only
good as a WYSIWYG api. When the users interact with rich-text (e.g. in an
email product), they are not thinking semantically. Some small percentage
(mostly programmers!) do perhaps, but in general the browser has no idea
what kind of content the user will put in the new block, so we just don't
know that using a paragraph is correct either from an HTML or semantic
perspective.

Ojan