[whatwg] Pressing Enter in contenteditable: <p> or <br> or <div>?
Simetrical+w3c at gmail.com
Fri May 13 12:26:27 PDT 2011
On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Note that br and div affect UBA differently so we must consider what
> bidirectional text users want as well.
> For example, if we had <div dir="rtl">hello</div>, and inserted br as in
> <div dir="rtl">hello<br></div>, then we preserve the RTL directionality. If
> we insert div on the other hand, <div dir="rtl">hello</div><div></div>, then
> new paragraph will have the containing block's direction.
> This will be a tricky issue when people want to mix LTR/RTL paragraphs in
> the same editable region.
If we had <div dir=rtl>hello</div>, a new line should become <div
dir=rtl>hello<div></div></div>, not <div
dir=rtl>hello</div><div></div>. As far as I understand it, we don't
have interop on bidi handling for <br>, so that's an argument against
Test-case courtesy of Aharon Lanin:
א --><br>--> ב
In IE and WebKit the arrows point right, in Gecko and Opera they point
left. With a <div>, they point right in all browsers.
But this is an argument against using <br> at all, even for Shift-Enter.
> I strongly feel that we should default to div for the backward
> compatibility. And this is the preferred paragraph separator in many Google
> products as far as I know because div allows developers to easy apply style,
> add class, etc... to a paragraph. And there seems to be a long history of
> browsers inserting inserting p/div on Enter and inserting br on Shift+Enter
> (on Windows), and changing that behavior will confuse users who are used to
> this behavior.
Gecko has never done this, so there can't be very bad back-compat
issues (any more than any standardization here poses). Having Enter
and Shift+Enter produce exactly the same visual effect but different
markup, as WebKit does, seems very confusing. If we were to go with
<div>, it should be across the board, with no <br>s produced at all.
On Fri, May 13, 2011 at 2:25 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> innerHTML uses OutputRaw which ensures that no prettyprinting happens ever,
> no matter what, even if a gun is held to the serializer's head. In
> particular, it overrides the _moz_dirty flag.
> Similar for copy/paste.
> I would suspect that there is no web-observable serialization behavior that
> depends on _moz_dirty.
Hmm, okay. So it's not an issue I have to care about. (Although of
course when I eventually write a real test suite, this will make Gecko
fail lots of tests. But everyone will fail pretty much all the tests
at first anyway, given the state of contenteditable today, so . . .)
> This code exists for an HTML editor. There's no round-tripping involved.
> You're just editing some HTML.
In web content, pretty much the only reason people have HTML editors
is so they can submit the content to a server, presumably using
innerHTML. The story for non-web-exposed stuff is of course
different, but it's not relevant to specs.
More information about the whatwg