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

[Aryeh Gregor]

On Wed, May 18, 2011 at 3:22 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
> What about itemid and accesskey?  (There may be other examples that I'm
> forgetting right now).

accesskey is unlikely to occur in contenteditable, and duplicates are
technically allowed.  itemid is even less likely to occur in
contenteditable, and copying other microdata attributes on the element
will probably break the meaning of the microdata anyway (by making it
two items instead of one).  I'd prefer to avoid magic lists of
attributes if possible, because they tend to bitrot.  Although in some
cases I'm suspecting I can't avoid it.

On Thu, May 19, 2011 at 3:39 AM, Markus Ernst <derernst at gmx.ch> wrote:
> I don't think we should convert anything on paste by default. Some
> contentEditable applications are designed as full-page editors; full pages
> are likely to break if <div>s are converted to <p>s or vice versa. I don't
> think any algorithm can reliably figure out whether a <div> is part of the
> page structure, or part of a series of paragraphs in every case (this is
> also why I vote for using <p>s). Cleaning up the code is good and necessary,
> but it should be left to authors, and I agree that access to the paste event
> is crucial here.

Good point.  I agree.

On Thu, May 19, 2011 at 8:11 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> Furthermore, I think it makes no sense for the spec to pretend to have a hard line against presentationalism (to the point of trying to define <i> and <b> to mean something other than italic and bold) while supplying a built-in mechanism for creating totally presentational markup.

Well, currently Ian is editing HTML5 and I'm editing the editing
commands spec, and I disagree with his hard line against
presentationalism, so . . . :)  (But really, the API is unavoidably
presentational.)

> In other words, I think the old IE behavior makes sense and I think the Gecko and WebKit behaviors of creating a soup of <br> and style="..." are unfortunate.

The old IE behavior of <b>/<i>/etc. is required by default in the
current spec, with execCommand("styleWithCSS") available to toggle to
a <span style=""> mode for those who want it.  (E.g., if you want to
validate, you'll need to switch it off before using commands like
foreColor that would otherwise generate <font>.)

> That libraries feel the need to fix e.g. Gecko output in JS to get more IE-ish behavior is indication that the Gecko/WebKit approach isn't good.

No, it's just an indication that they want consistent output.  To make
Gecko match other browsers, document.execCommand("styleWithCSS",
false, false); document.execCommand("insertBrOnReturn", false, false);
works pretty well, but you can't do much to make other browsers match
Gecko.