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

[Aryeh Gregor]

On Fri, May 13, 2011 at 6:29 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
> We're not going to add pretty-printing for the purposes of this spec, are
> we?

No, I didn't realize Boris wasn't talking about web-visible features.

> Sure, but how are we going to detect that?  Do you agree that they intend to
> add a paragraph most of the time?

Probably, yes.

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

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

>> * If you give the input<p>[foo]</p>  to Chrome 12 dev and run
>> insertOrderedList, it produces the DOM (expressed in XML)
>> <p><ol><li>[foo]<br /></li></ol></p>, which when you serialize to
>> text/html and unserialize becomes<p></p><ol><li>[foo]<br
>> /></li></ol><p></p>.
>
> Firefox generates <ol><li>foo</li></ol>.
> [etc.]

Yes, Firefox generates serializable DOMs in every <p>-related case
I've seen.  If you do createLink with value "def" on

  <a href=abc><b>foo[bar]baz</b></a>

it produces <a href=abc><b>foo<a href=def>bar</a>baz</b></a>, though,
which becomes <a href=abc><b>foo</b></a><b><a href=def>bar</a>baz</b>
when you serialize and unserialize it.  So the general problem of
unserializable DOMs occurs in some cases in all browsers.  That's not
a great reason by itself for not using <p>, but it's something to hold
against it.

> I guess I don't understand your reasoning.  If you're saying that existing
> implementations have bugs on this sort of thing, for sure, no discussion
> about that.  But I don't know if we can draw the conclusion that it's not
> possible to generate an HTML5 valid DOM if we used <p>.

It is possible, it's just more likely to cause bugs.

> I think the right way to decide between <p> and <div> is to ask ourselves
> this question: "What is the correct element to use?".

Isn't that circular?

On Fri, May 13, 2011 at 6:35 PM, Ehsan Akhgari <ehsan at mozilla.com> wrote:
> This is a very good point.  I know that <p> constitutes a UBA paragraph.
>  Does the same apply to <div> as well?

All CSS block boundaries constitute UBA paragraph breaks:

"""
User agents that support bidirectional text must apply the Unicode
bidirectional algorithm to every sequence of inline-level boxes
uninterrupted by a forced (bidi class B) break or block boundary. This
sequence forms the "paragraph" unit in the bidirectional algorithm.
"""
http://www.w3.org/TR/CSS21/visuren.html#direction

On Mon, May 16, 2011 at 9:33 AM, Markus Ernst <derernst at gmx.ch> wrote:
> This is what people know from MS Word, too, and thus it should be considered
> as a de-facto standard. I don't have current versions of other office text
> editors installed right now, but I assume they will behave the same, or at
> least provide a setting to make them behave like that.

I'm almost sure that wasn't the standard in older versions of Word,
like 1997.  I don't have any on hand to test, though.  OpenOffice.org
Writer (3.2.1, Ubuntu 10.10 version) inserts only a single line break
when you hit Enter.

> I have seen content management systems where text editors tweak the enter
> key to behave the same also in non-IE UAs (e.g. if you use Contenido with
> TinyMCE, Firefox produces the same output as IE when you hit enter).

I mentioned one forum (vBulletin) which used to set margin to 0 on
paragraphs so that IE looked the same as non-IE browsers.  So it's an
argument for giving authors an option, maybe, but it doesn't help us
decide what the default should be.

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

> The same applies e.g. for list items, UAs have to solve this problem anyway.

List items are much easier, since the only thing they can't contain is
other list items.  Paragraphs can't contain any block element.
Anyway, we can't avoid using list items.