This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24704 - @contenteditable, new lines and new paragraphs.
Summary: @contenteditable, new lines and new paragraphs.
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - HTML Editing APIs (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Aryeh Gregor
QA Contact: HTML Editing APIs spec bugbot
Depends on:
Reported: 2014-02-17 19:18 UTC by contributor
Modified: 2014-02-21 12:09 UTC (History)
4 users (show)

See Also:


Description contributor 2014-02-17 19:18:00 UTC

@contenteditable, new lines and new paragraphs.

Posted from: by
User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36
Comment 1 Andrea Rendine 2014-02-17 19:47:29 UTC
When an element has @contenteditable, visual UAs expose a basic editing interface (focused element and insertion cursor), like in <textarea>s but with the nodes inside the editable element keeping their formatting (of course). 
When the user inserts a newline (e.g. Shift+Enter in Windows), these user agents correctly insert a <br> element (representing line break). How are they expected to react when the user hits Enter, corresponding to "new paragraph" in most text editors? I tested it with Chrome and it seems to insert a new <div> element, which is not at all correct, as <p> fit better for a generic text-only content model. Moreover, it inserts the aforementioned <div> *inside* the editable element, even if its content model does not support <div>s (my editable element is a paragraph). 
This is not the real issue, as tagsoup-proof user agents can handle blocks inside paragraphs. Anyway, be it allowed or not, the insertion of such an element can cause problems in the visual rendering, both of the new element itself and of the whole page, especially if structural CSS selectors are used to style the page.
IMO the spec should clearly state that in absence of a defined editing interface with complete control over the commands, a UA is expected to insert nothing but <br>s as new markup. <br> is natively supported, does not rely on CSS and therefore cannot be adversely styled. And no block elements means no interference between styles. Maybe the difference between Shift+Enter and Enter could be the addition of a double <br> in the latter case (thus mimicking the extra margin between paragraphs).
Comment 2 Aryeh Gregor 2014-02-21 12:09:59 UTC
The specification requires that hitting Enter (or equivalent) is the same as the insertParagraph command, and Shift-Enter (or equivalent) is the same as insertLineBreak:

The insertParagraph command is specified here, with a rough summary in green at the top:

The short story is: this has been discussed a lot, and there are three basic approaches taken by browser engines.  The basic behavior that's currently specified (very simplified) is patterned after IE and Opera, and is: find the nearest ancestor that's a <div>/<p>/<li>/etc. and make a new one, if there is any; and if there isn't, make a new <p>.  So for instance, if you have


and you hit Enter in the middle, it becomes


or such.  Likewise <p>foo</p> will become <p>fo<p>o</p>, and so on.  If you start off with an empty editing host, or break out of a list or such, it will use <p>, but this can be changed to <div> via the defaultParagraphSeparator command.  This has been discussed a lot, multiple times, and I'm unlikely to change the spec to require <br> for Enter unless browser implementers want it, which is unlikely.  A good thread to read if you're interested is:

<br> for Enter is the Firefox behavior at the time of this writing, but I rejected it because it causes a lot of subtle headaches and bugs.  Particularly, it doesn't actually always create a line break: HTML like


displays identically to the same without the <br> -- try it and see.  So you have to write lots of magic to figure out when you need to insert extra <br>s to make the <br> do what you want.

Moreover, having each paragraph wrapped in its own tag is programmatically easier.  Sometimes you want code that affects an entire paragraph, and if it's in a <p> it's very easy.  With <br>s it's much more annoying.

As far as your example of <p contenteditable> -- this sort of thing is not well-supported right now, either in the spec or in browsers.  <span contenteditable> is even worse.  A ton of work would have to be done to get this sort of thing to behave right, and it's not realistically worth it, so I suggest sticking with <div> for contenteditable for now.

I hope this helps.  As I said, this is very unlikely to change to what you requested, but if you have more questions *after* reading the mailing list thread I linked to, please feel free to reopen this bug.