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

On 11-05-13 1:26 PM, Aryeh Gregor wrote:
> If you're going to add pretty-printing, doesn't it make more sense to
> just add the text nodes directly to the DOM?  You're going to have to
> deal with the extra nodes anyway as soon as the content round-trips to
> a server.

We're not going to add pretty-printing for the purposes of this spec, 
are we?

> Only if the user intends it to be a paragraph.  Usually they'll intend
> that, but you don't know.<p>  is semantically inappropriate for
> marking up the lines of a poem or address, for instance.

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

> I've avoided splitting elements whenever possible, because it's a
> minefield.  What if it were<div id=foo>?  What if it were<div
> class=foo>  but the class applied some styles like borders that you'd
> change if you duplicated it?  What if it were<div data-foo=bar>?
> What if there was a script handler attached to the element?  Sometimes
> you have to do it anyway, but I don't unless there's no other way.

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

> In this case, I'd say it should become<div
> class="foo">bar<br>|</div>, or<div class="foo">bar<div>|</div></div>,
> or<div class="foo">bar<p>|</p></div>, as the case may be.

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

>> Would you elaborate, please?  Specifically, are you saying that in it's inferior to<div>  in this regard?
>
> Yes, much inferior.<div>  can contain any block elements.<p>  cannot
> contain almost anything else:<div>,<ol>,<ul>,<dl>,<p>,
> <blockquote>, etc., etc. cannot be put inside it at any nesting level.
>   So there's a greater risk of bugs.  For instance:
>
> * 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>.

> * If you give<p>[foo]</p>  to Opera 11.10 and run indent, it produces
> <p><blockquote>[foo]</blockquote></p>, which becomes
> <p></p><blockquote>[foo]</blockquote><p></p>  after round-tripping
> through text/html.

Firefox generates <p style="margin-left: 40px;">foo</p>.

> * If you give<ol><li><div>[foo]</div>bar</li></ol>  to IE9 and run
> "outdent", you get<p><div>[foo]</div>bar</p>, which round-trips to
> <p></p><div>[foo]</div>bar<p></p>.  (I didn't find a simpler scenario
> where it produced such DOMs, to its credit.)

A better form for output is <div>foo</div><div>bar</div> I think 
(Firefox handles this very badly: <ol><li>foobar</li></ol>).

> My algorithms contain bugs like this too, which I try to fix as I find
> them.  I didn't find any in Firefox yet, I don't think, but it would
> be hard to avoid them across the board.  Of course we want to behave
> correctly even if there are<p>s in the input for whatever reason, but
> not producing<p>s ourselves would at least mitigate the impact of
> such bugs.

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

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

> Anyway, at this point I'm against<p>  because of the margin and
> serializability issues, and undecided between<br>  and<div>.<br>  is
> harder to deal with, but we have to deal with it regardless, and it's
> both logical and succinct.<div>  is closer to what most browsers
> output by default (wrapping elements instead of using<br>), but it
> adds more clutter, and all browsers do output<br>  by default in some
> cases.  I guess I'm leaning toward using<br>  by default.  If any
> implementers feel strongly, now would be a good time to speak up.

The margin is a presentation issue, which can be fixed by adjusting the 
document style.  It _may_ even be desired in some cases.  As I said 
above, if we just generate the correct markup, we don't need to worry 
about serializability.

Cheers,
Ehsan

Received on Friday, 13 May 2011 15:29:51 UTC