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

[Aryeh Gregor]

On Wed, May 18, 2011 at 2:09 PM, Ojan Vafai <ojan at chromium.org> wrote:
> 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.

If <p> is allowed as a block element, as it seems it will be (even if
not by default), the argument becomes stronger.  You can't nest the
p's, so you have to clone them, and you don't want to behave
inconsistently for divs and p's.  So I guess I agree.

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

Do you have specific links to testcases I can look at and fiddle with?

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

accesskey, itemid, and name (on <a>) seem potentially problematic too.
 It's also possible that custom attributes, data-* or otherwise, might
be issues, depending on how they're used.  I guess in that case it's
better to duplicate it and let authors figure out the consequences if
it's wrong, than to destroy the info about what attributes it
originally had.

So probably it's okay to just blacklist id and <a name>.

> 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 agree.  In particular, this is the only thing that makes sense if
you're using something with margins or other style, like <p>.
Otherwise it will look weird to the user.  (I assume this is why
WebKit behaves differently from IE/Opera, because WebKit uses <div>
and IE/Opera use <p> by default.)

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

There's more magic than that.  For instance, if you're in an <li> and
hit Enter twice, all browsers will create a new <li> on the first
Enter and then destroy it and move you outside the list on the second
Enter.

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

But if we make <p> the default, it's pretty trivial for authors to set
its margins to 0.  If we make <div> the default, it's hard for authors
to add margins unless they're sure <div> isn't being used for anything
but line grouping.

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

I don't know, maybe.  Copy-paste is its own kettle of fish that I'll
deal with later.