Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Thu, May 12, 2011 at 4:28 PM, Aryeh Gregor simetrical+...@gmail.com wrote: Behavior for Enter in contenteditable in current browsers seems to be as follows: * IE9 wraps all lines in p (including if you start typing in an empty text box). If you hit Enter multiple times, it inserts empty ps. Shift-Enter inserts br. * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) * Chrome 12 dev doesn't wrap a line when you start typing, but when you hit Enter it wraps the new line in a div. Hitting Enter multiple times outputs divbr/div, and Shift-Enter always inserts br. * Opera 11.10 wraps in p like IE, but for blank lines it uses pbr/p instead of just p/p (they render the same). What behavior do we want? I ended up going with the general approach of IE/Opera: http://aryeh.name/spec/editcommands/editcommands.html#additional-requirements It turns out WebKit and Opera make the insertParagraph command behave essentially like hitting Enter, so I actually wrote all the requirements there (IE's and Firefox's behavior for insertParagraph was very different and didn't seem useful): http://aryeh.name/spec/editcommands/editcommands.html#the-insertparagraph-command The basic idea is that if the cursor isn't wrapped in a single-line container (address, dd, div, dt, h*, li, p, pre) then the current line gets wrapped in a p. Then the current single-line container is split in two, mostly. Exceptions are roughly: * For pre and address, insert a br instead of splitting the element. (This matches Firefox for pre and address, and Opera for pre but not address. IE/Chrome make multiple pres/addresses.) * For an empty li/dt/dd, destroy it and break out of its container, so hitting Enter twice in a list breaks out of the list. (Everyone does this for li, only Firefox does for dt/dd.) * If the cursor is at the end of an h* element, make the new element a p instead of a header. (Everyone does this.) * If the cursor is at the end of a dd/dt element, it switches to dt/dd respectively. (Only Firefox does this, but it makes sense.) Like the rest of the spec, this is still a rough draft and I haven't tried to pin corner cases down yet, so it's probably not advisable to try implementing it yet as written. As always, you can see how the spec implementation behaves for various input by looking at autoimplementation.html: http://aryeh.name/spec/editcommands/autoimplementation.html#insertparagraph
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Wed, May 18, 2011 at 3:22 PM, Ehsan Akhgari eh...@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 derer...@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 divs are converted to ps 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 ps). 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 hsivo...@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.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Fri, May 13, 2011 at 12:26 PM, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa rn...@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=rtlhello/div, and inserted br as in div dir=rtlhellobr/div, then we preserve the RTL directionality. If we insert div on the other hand, div dir=rtlhello/divdiv/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=rtlhello/div, a new line should become div dir=rtlhellodiv/div/div, not div dir=rtlhello/divdiv/div. Disagree. I think it should be come div dir=rtlhellow/divdiv dir=rtl/div. Nesting seems really bad to me. It results in a more complicated DOM that makes scripting against the resultant DOM extremely difficult. On Mon, May 16, 2011 at 12:20 PM, Aryeh Gregor simetrical+...@gmail.comwrote: On Fri, May 13, 2011 at 6:29 PM, Ehsan Akhgari eh...@mozilla.com wrote: 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=xfoo[bar]baz/b then in Firefox 4.0 and Opera 11.10 you get b id=xfoo/bbarb id=xbaz/b (duplicate id), in Chrome 12 dev you get b id=xfoo/bbarbbaz/b (id lost on one element), and in IE9 you get strongfoo/strongbarstrongbaz/strong (both id's lost). The spec's algorithm produces span id=xbfoo/bbarbbaz/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. We need to address this case. For example, Google Docs, before it stopped using contentEditable, used IDs in the user-editable content to help scope what data needed syncing. The Google Closure Editor uses classnames and data attributes to store extra metadata (e.g. that a div is actually a container for an image+caption widget). Also, we should be preserving inline styles. We should copy all attributes and have a blacklist of uncopyable attributes. ID is the only one I can think of off the top of my head that needs blacklisting. On Fri, May 13, 2011 at 3:11 AM, Simon Pieters sim...@opera.com wrote: On Thu, 12 May 2011 22:28:47 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: * IE9 wraps all lines in p (including if you start typing in an empty text box). Can't reproduce. If I start typing in an empty body contenteditable, there's no p until I hit enter. Yes, but when you hit Enter it wraps the first line in a p too, not just the second line. In WebKit it only wraps the second line in a div. IMO, WebKit's behavior here is wrong. When you hit enter not in a block context, it should put all the inlines + text in two separate divs. 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. Opera's behavior here seems right to me. If I understand correctly here's what Opera does: enter without a parent block: wrap everything in two block elements as defined by the opera-defaultblock execCommand. enter with a parent block: split the parent block shift+enter: insert a BR enter inside a header: breaks out of the header and inserts a block as per the opera-defaultblock execCommand (this is just legacy we're stuck with from IE5+) I believe that most users expect the styling of the block to remain the same when they hit enter. If you
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Wed, May 18, 2011 at 2:09 PM, Ojan Vafai o...@chromium.org wrote: Disagree. I think it should be come div dir=rtlhellow/divdiv dir=rtl/div. Nesting seems really bad to me. It results in a more complicated DOM that makes scripting against the resultant DOM extremely difficult. If p is allowed as a block element, as it seems it will be (even if not by default), the argument becomes stronger. You can't nest the p's, so you have to clone them, and you don't want to behave inconsistently for divs and p's. So I guess I agree. We need to address this case. For example, Google Docs, before it stopped using contentEditable, used IDs in the user-editable content to help scope what data needed syncing. The Google Closure Editor uses classnames and data attributes to store extra metadata (e.g. that a div is actually a container for an image+caption widget). Do you have specific links to testcases I can look at and fiddle with? Also, we should be preserving inline styles. We should copy all attributes and have a blacklist of uncopyable attributes. ID is the only one I can think of off the top of my head that needs blacklisting. accesskey, itemid, and name (on a) seem potentially problematic too. It's also possible that custom attributes, data-* or otherwise, might be issues, depending on how they're used. I guess in that case it's better to duplicate it and let authors figure out the consequences if it's wrong, than to destroy the info about what attributes it originally had. So probably it's okay to just blacklist id and a name. IMO, WebKit's behavior here is wrong. When you hit enter not in a block context, it should put all the inlines + text in two separate divs. I agree. In particular, this is the only thing that makes sense if you're using something with margins or other style, like p. Otherwise it will look weird to the user. (I assume this is why WebKit behaves differently from IE/Opera, because WebKit uses div and IE/Opera use p by default.) Opera's behavior here seems right to me. If I understand correctly here's what Opera does: enter without a parent block: wrap everything in two block elements as defined by the opera-defaultblock execCommand. enter with a parent block: split the parent block shift+enter: insert a BR enter inside a header: breaks out of the header and inserts a block as per the opera-defaultblock execCommand (this is just legacy we're stuck with from IE5+) There's more magic than that. For instance, if you're in an li and hit Enter twice, all browsers will create a new li on the first Enter and then destroy it and move you outside the list on the second Enter. I believe that most users expect the styling of the block to remain the same when they hit enter. If you are in a paragraph with margins, hitting enter should give you two paragraphs with margins. However, I agree the the default expected behavior is that enter will insert a single linebreak, which is why I support DIV being the default block value. But if we make p the default, it's pretty trivial for authors to set its margins to 0. If we make div the default, it's hard for authors to add margins unless they're sure div isn't being used for anything but line grouping. The tricky bit here is what to do when the user copy-pastes. I think we should convert P to DIV or vice versa as per whatever the defaultblock value is. We should also give an execCommand to allow the website to disable this behavior. I don't know, maybe. Copy-paste is its own kettle of fish that I'll deal with later.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On 11-05-18 2:46 PM, Aryeh Gregor wrote: Also, we should be preserving inline styles. We should copy all attributes and have a blacklist of uncopyable attributes. ID is the only one I can think of off the top of my head that needs blacklisting. accesskey, itemid, and name (ona) seem potentially problematic too. It's also possible that custom attributes, data-* or otherwise, might be issues, depending on how they're used. I guess in that case it's better to duplicate it and let authors figure out the consequences if it's wrong, than to destroy the info about what attributes it originally had. I agree. So probably it's okay to just blacklist id anda name. What about itemid and accesskey? (There may be other examples that I'm forgetting right now). IMO, WebKit's behavior here is wrong. When you hit enter not in a block Opera's behavior here seems right to me. If I understand correctly here's what Opera does: enter without a parent block: wrap everything in two block elements as defined by the opera-defaultblock execCommand. enter with a parent block: split the parent block shift+enter: insert a BR enter inside a header: breaks out of the header and inserts a block as per the opera-defaultblock execCommand (this is just legacy we're stuck with from IE5+) There's more magic than that. For instance, if you're in anli and hit Enter twice, all browsers will create a newli on the first Enter and then destroy it and move you outside the list on the second Enter. Yes. Overall, this seems like a pretty sane basis on top of which we can build the algorithm. Cheers, Ehsan
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 16.05.2011 21:20 schrieb Aryeh Gregor: On Mon, May 16, 2011 at 9:33 AM, Markus Ernstderer...@gmx.ch wrote: 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. Right, but this does not answer the question about the best standard behavior for the enter key. For real WYSIYWYG, it would be necessary to introduce a mechanism to apply some CSS separate from the surrounding page to the contenteditable element, so CMS or forum authors can provide the styles of the output page in the input element. (This is actually the case in iframe-based RTEs such as Kevin Roth's Cross-Browser RTE or TinyMCE.) I assume there are use cases for both generating ps and brs. The IE/Opera approach has the advantage of allowing both, which is perfect for text and basic HTML editing. From a WYSIWYG POV it might be best to offer both options, so authors are not encouraged to add server-side processing to change the output, which would break WYSIWYG. If the behavior is settable, it might even be a good idea to leave the choice of the standard behavior to the UAs. Authors who have a reason to care can set their preferred behavior, while other authors might prefer to leave it as it was, so there is no change for their existing users.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 13.05.2011 12:00 schrieb Michael A. Puls II: On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor simetrical+...@gmail.com wrote: Another problem with p is that it's very easy to create unserializable DOMs with it. I've seen cases where at least some browsers will put things inside p that will break out of the p, and I've done it myself by mistake too. I think the browser/editor just shouldn't allow that in this case. (Not saying that it's easy to enforce it though.) As an author or CMS implementor I'd be happy to see UAs solve this for me, creating a valid sequence of paragraphs. OTOH, if you use divs in order to keep the output serializable, this might lead to kind of messy code. Imagine a content of the contenteditable element like: divdivpFoo/p/div/div divpBar/p/div The user puts the caret to the end of the first line and clicks Enter. With a strict p/br behavior, this is a well-defined action, adding a new paragraph resp. inserting a newline. But if you go with divs, this will possibly mess up the code in a way that is hard to fix (though it is valid and serializable HTML).
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Tue, May 17, 2011 at 3:04 AM, Markus Ernst derer...@gmx.ch wrote:
If the behavior is settable, it might even be a good idea to leave the
choice of the standard behavior to the UAs. Authors who have a reason to
care can set their preferred behavior, while other authors might prefer to
leave it as it was, so there is no change for their existing users.
We can't leave the default behavior undefined for something like this.
It affects interoperability, and there's no reason browsers should
differ (we can't make up our mind is not a good enough reason).
On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
I completely disagree. As a user, I want semantics when I write my blog
entry on WordPress so that I can tweak presentation afterwards. e.g. I have
frequently used em {font-style: normal; font-weight:bold;} strong
{text-decoration:underline; font-weight: normal;} in the past.
Then the commands will completely break no matter what you do, because
they're tied to the CSS, not the HTML element. For instance, in this
test case:
!doctype html
style
em { font-style: normal; font-weight: bold }
/style
div contenteditableemHello/em/div
script
var text = document.querySelector(em).firstChild;
getSelection().collapse(text, 1);
getSelection().extend(text, 4);
document.execCommand(bold);
/script
Chrome 12 dev produces emHspan class=Apple-style-span
style=font-weight: normal;ell/spano/em. If you change the
command from bold to italic, it becomes emHiell/io/em.
These commands are specifically presentational, tied to CSS rather
than HTML, which is reflected both in their name and function.
There are other commands that are semantic, like heading or
insertOrderedList. But you definitely cannot sanely use em for bold
with this API. We'd have to add new commands like emphasize to
allow that.
And when I press enter, I want a paragraph separator NOT a line break.
WebKit outputs div, but a paragraph separator should be p.
On Tue, May 17, 2011 at 3:26 AM, Markus Ernst derer...@gmx.ch wrote:
Imagine a content of the contenteditable element like:
divdivpFoo/p/div/div
divpBar/p/div
The user puts the caret to the end of the first line and clicks Enter. With
a strict p/br behavior, this is a well-defined action, adding a new
paragraph resp. inserting a newline. But if you go with divs, this will
possibly mess up the code in a way that is hard to fix (though it is valid
and serializable HTML).
Yeah, p has the advantage over div that div is used for lots of
things, and it might be nice to distinguish. I don't know. Since
there are no really good arguments I can see in any direction, I guess
it makes the most sense to standardize the plurality position, namely
some variant of IE/Opera (p on Enter and br on Shift-Enter), with
switches to allow authors to change from the default. I added it as
an issue to the spec, and will probably look at it reasonably soon:
http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=70be7878
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Tue, May 17, 2011 at 12:50 PM, Aryeh Gregor simetrical+...@gmail.comwrote:
On Tue, May 17, 2011 at 3:19 AM, Ryosuke Niwa rn...@webkit.org wrote:
I completely disagree. As a user, I want semantics when I write my blog
entry on WordPress so that I can tweak presentation afterwards. e.g. I
have
frequently used em {font-style: normal; font-weight:bold;} strong
{text-decoration:underline; font-weight: normal;} in the past.
Then the commands will completely break no matter what you do, because
they're tied to the CSS, not the HTML element. For instance, in this
test case:
No, I apply those CSS styles only on readonly published pages so my editor
isn't affected by those rules.
- Ryosuke
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines inp (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter insertsbr.
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 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'd strongly suggest to spec this behaviour, or at least provide some
kind of setting to force it.
* Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a line when you start typing, but when
you hit Enter it wraps the new line in adiv. Hitting Enter
multiple times outputsdivbr/div, and Shift-Enter always inserts
br.
* Opera 11.10 wraps inp like IE, but for blank lines it uses
pbr/p instead of justp/p (they render the same).
What behavior do we want?
A problem withp is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translatesp and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
This is very presentational thinking. If you write a text, it should be
possible to produce paragraphs by default. If you use div instead of
p, there would be extra coding needed to make paragraphs available.
Another problem withp is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things insidep that will break out of thep,
and I've done it myself by mistake too.
The same applies e.g. for list items, UAs have to solve this problem
anyway. One approach that I could imagine is to close and re-open the
paragraph (resp. list item) at the boundaries of the element which is
put inside it.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
Am 16.05.2011 15:33 schrieb Markus Ernst:
Am 12.05.2011 22:28 schrieb Aryeh Gregor:
A problem withp is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translatesp and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
I am sorry I overread this last sentence when writing my previous
message. I have a swiss-german installation of Word 2007, I did not
change the settings. Hitting enter produces paragraphs here, and applies
the spaces above and/or below that are specified in the paragraph style.
This is the behaviour I have known from Word for years. Maybe there are
regional differences in the defaults of Word.
This is very presentational thinking.
Re-reading my message I am afraid this sentence could be read as an
offense. There was absolutely no offense intended (I am sorry I had to
go pick up my daughter and sent too quickly). I wanted to state that
what CSS people apply should not matter to the question of creating p,
div or br.
The vBulletin example shows that there is a use case for applying br.
I state that there is a use case for applying p for enter and br for
shift-enter.
IMO an ideal solution would provide both (or, if there are use cases for
div, all three) possibilities, settable with a flag or an attribute.
The standard should be what office users expect from their everyday
experience.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Fri, May 13, 2011 at 6:29 PM, Ehsan Akhgari eh...@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=xfoo[bar]baz/b then in Firefox 4.0 and Opera 11.10 you get b id=xfoo/bbarb id=xbaz/b (duplicate id), in Chrome 12 dev you get b id=xfoo/bbarbbaz/b (id lost on one element), and in IE9 you get strongfoo/strongbarstrongbaz/strong (both id's lost). The spec's algorithm produces span id=xbfoo/bbarbbaz/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 inputp[foo]/p to Chrome 12 dev and run insertOrderedList, it produces the DOM (expressed in XML) polli[foo]br //li/ol/p, which when you serialize to text/html and unserialize becomesp/polli[foo]br //li/olp/p. Firefox generates ollifoo/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=abcbfoo[bar]baz/b/a it produces a href=abcbfooa href=defbar/abaz/b/a, though, which becomes a href=abcbfoo/b/aba href=defbar/abaz/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 eh...@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 derer...@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,
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Thu, 12 May 2011 22:28:47 +0200, Aryeh Gregor
simetrical+...@gmail.com wrote:
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box).
Can't reproduce. If I start typing in an empty body contenteditable,
there's no p until I hit enter.
If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a line when you start typing, but when
you hit Enter it wraps the new line in a div. Hitting Enter
multiple times outputs divbr/div, and Shift-Enter always inserts
br.
* Opera 11.10 wraps in p like IE, but for blank lines it uses
pbr/p instead of just p/p (they render the same).
It doesn't render the same. Empty ps should be collapsed per CSS. (Dunno
what IE does.)
What behavior do we want?
A problem with p is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translates p and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
Opera 11.10 has introduced
document.execCommand('opera-defaultblock','','div') to switch to using
divs instead of ps. ('p' is also allowed to switch back.) Apparently
WebKit considers implementing this as well.
https://bugs.webkit.org/show_bug.cgi?id=59961
Another problem with p is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things inside p that will break out of the p,
and I've done it myself by mistake too.
The problem with br is that it's a pain to deal with. It forces you
to deal with lines as sequences of adjacent sibling nodes instead of
as a single node. Also, sometimes br doesn't do anything, like
(usually) a single br at the end of a block box, but when you add
something after it it suddenly starts doing something. If lines
aren't wrapped in block elements, then whenever you have to move
around some text, you need to be sure that you check that you're not
removing a br or failing to move one and thereby running two lines
together, or leaving an extra br someplace so there are now two in a
row. I've seen bugs to this effect in multiple browsers, where they
don't insert a br when they should (but behave fine with div/p),
and have made the mistake a lot myself.
So my current thought is to demarcate lines with divs consistently,
only using br when there are multiple line breaks in a row. This is
unlike any current browser, since everyone uses br at least for
Shift-Enter. If this is the way we want to behave, then I'll also
have commands normalize nearby brs to divs where it makes things
easier, like I normalize other types of markup.
Feedback appreciated.
--
Simon Pieters
Opera Software
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Thu, 12 May 2011 16:28:47 -0400, Aryeh Gregor simetrical+...@gmail.com wrote: Behavior for Enter in contenteditable in current browsers seems to be as follows: * IE9 wraps all lines in p (including if you start typing in an empty text box). If you hit Enter multiple times, it inserts empty ps. Shift-Enter inserts br. * Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) * Chrome 12 dev doesn't wrap a line when you start typing, but when you hit Enter it wraps the new line in a div. Hitting Enter multiple times outputs divbr/div, and Shift-Enter always inserts br. * Opera 11.10 wraps in p like IE, but for blank lines it uses pbr/p instead of just p/p (they render the same). I think the br is a filler so that there's something for the user to click and focus on to get the insertion point inside the p. IE use nbps; for this instead. Opera has a bug where you have to press ENTER then backspace and then enter again to get rid of the br at the end of the element sometimes. If the default content (innerHTML more or less) of the contentEditable element is divbr/div (like in http://shadow2531.com/opera/testcases/designmode/000.html), Opera will use DIVs when pressing enter (and br when pressing shift + enter). A problem with p is that it has top and bottom margins by default, so hitting Enter once will look like a double line break. Ideally, users should realize that it's an editable part of a web page and that pressing ENTER once closes the current paragraph and starts a new one. They should also realize that the margins are part of the paragraphs, which causes them to be visually separated from other elements and that they don't need to do that manually by pressing ENTER again. These are not textareas or plain text editors after all. Another problem with p is that it's very easy to create unserializable DOMs with it. I've seen cases where at least some browsers will put things inside p that will break out of the p, and I've done it myself by mistake too. I think the browser/editor just shouldn't allow that in this case. (Not saying that it's easy to enforce it though.) What behavior do we want? p makes the most sense ideally. However, if the editor needs to pose as a line-based text editor, br makes the most sense. But, p styled with 0 margins or div would be better than br if there's a desire to group lines. If there is a desire to group lines, p will still be a little more semantic, but div will be easier as it can rely on default styles and doesn't have the unserializable dom issue. But, either way, p/p or div/div will still be used for blank lines, which doesn't seem ideal. So my current thought is to demarcate lines with divs consistently, only using br when there are multiple line breaks in a row. So, if I type Line 1 and press ENTER twice and then type Line 3, I'd get: divLine 1brbr/div divLine 3/div ? -- Michael
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Thu, May 12, 2011 at 4:51 PM, Boris Zbarsky bzbar...@mit.edu wrote: It's used when serializing: things with _moz_dirty are prettyprinted even if the serialization is trying to preserve the original whitespace layout of the HTML in general. The fact that it's an actual content attribute is a bug dating back to when there was no other good way to associate state to an element in Gecko; we just need to fix that. See https://bugzilla.mozilla.org/show_bug.cgi?id=459212 So it's an attribute that affects serialization in a nonstandard way? What sort of serialization does it affect? I just tested innerHTML, and I found it stripped the attribute, but it didn't seem to add any whitespace around br, ol, or li. 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. On Thu, May 12, 2011 at 6:30 PM, Ehsan Akhgari eh...@mozilla.com wrote: But it also has the semantic property of being a paragraph, which is an advantage I think. 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. There is also one more question to answer. If we're already in a block level element, what should happen when pressing Enter? For example, for div class=foobar|/div, what should happen after pressing enter? I think the sane thing to do is to create div class=foobar/divdiv class=foo|/div (since the div might be styled on the page, and not preserving the block's tag or class attr would take that away. 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. In this case, I'd say it should become div class=foobarbr|/div, or div class=foobardiv|/div/div, or div class=foobarp|/p/div, as the case may be. 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) polli[foo]br //li/ol/p, which when you serialize to text/html and unserialize becomes p/polli[foo]br //li/olp/p. * If you give p[foo]/p to Opera 11.10 and run indent, it produces pblockquote[foo]/blockquote/p, which becomes p/pblockquote[foo]/blockquotep/p after round-tripping through text/html. * If you give ollidiv[foo]/divbar/li/ol to IE9 and run outdent, you get pdiv[foo]/divbar/p, which round-trips to p/pdiv[foo]/divbarp/p. (I didn't find a simpler scenario where it produced such DOMs, to its credit.) 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 ps in the input for whatever reason, but not producing ps ourselves would at least mitigate the impact of such bugs. br is considered to be the standard way of representing line breaks, which are part of the content. About the problems that you're mentioning, I think we need to address them anyways, since brs might already be in the content even without having them assigned to Shift+Enter. Yeah, I guess so, unless we normalized aggressively. I think we want to keep using brs, but I'm not convinced if div is a better choice than p. I'm not completely decided at this point, but am now leaning toward br. Currently my spec uses br where some type of break is needed (e.g., de-indenting an inline node when that would make it the sibling of some other inline node), because that's the shortest markup in simple cases. On Fri, May 13, 2011 at 3:11 AM, Simon Pieters sim...@opera.com wrote: On Thu, 12 May 2011 22:28:47 +0200, Aryeh Gregor simetrical+...@gmail.com wrote: * IE9 wraps all lines in p (including if you start typing in an empty text box). Can't reproduce. If I start typing in an empty body contenteditable, there's no p until I hit enter. Yes, but when you hit Enter it wraps the first line in a p too, not just the second line. In WebKit it only wraps the second line in a div. It doesn't render the same. Empty ps should be collapsed per CSS. (Dunno what IE does.) Peculiar. An empty p will leave a blank line equal to the height of its top or bottom margin, whichever
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregor simetrical+...@gmail.comwrote: I'm not completely decided at this point, but am now leaning toward br. Currently my spec uses br where some type of break is needed (e.g., de-indenting an inline node when that would make it the sibling of some other inline node), because that's the shortest markup in simple cases. 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=rtlhello/div, and inserted br as in div dir=rtlhellobr/div, then we preserve the RTL directionality. If we insert div on the other hand, div dir=rtlhello/divdiv/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. I guess I'm leaning toward using br by default. If any implementers feel strongly, now would be a good time to speak up. 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. - Ryosuke
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On 5/13/11 1:26 PM, Aryeh Gregor wrote: So it's an attribute that affects serialization in a nonstandard way? Far as I can tell, yes. What sort of serialization does it affect? Gecko has way too many serialization modes, most of them not web-exposed (to support writing decent HTML editors and the like). See the various flags in http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIDocumentEncoder.idl The _moz_dirty flag affects most of those modes, but see below. I just tested innerHTML, and I found it stripped the attribute, but it didn't seem to add any whitespace aroundbr,ol, orli. 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. If you're going to add pretty-printing, doesn't it make more sense to just add the text nodes directly to the DOM? Dunno; I didn't write the editor and don't have much experience with its internals. You're going to have to deal with the extra nodes anyway as soon as the content round-trips to a server. This code exists for an HTML editor. There's no round-tripping involved. You're just editing some HTML. -Boris
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Fri, May 13, 2011 at 1:48 PM, Ryosuke Niwa rn...@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=rtlhello/div, and inserted br as in div dir=rtlhellobr/div, then we preserve the RTL directionality. If we insert div on the other hand, div dir=rtlhello/divdiv/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=rtlhello/div, a new line should become div dir=rtlhellodiv/div/div, not div dir=rtlhello/divdiv/div. As far as I understand it, we don't have interop on bidi handling for br, so that's an argument against it: http://www.w3.org/Bugs/Public/show_bug.cgi?id=10828 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 brs produced at all. On Fri, May 13, 2011 at 2:25 PM, Boris Zbarsky bzbar...@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.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On 5/13/11 3:26 PM, Aryeh Gregor wrote: א --br-- ב In IE and WebKit the arrows point right, in Gecko and Opera they point left. I _think_ we consider that a bug in Gecko. 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. Sure; I did say we need to make that attribute go away. ;) -Boris
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Fri, May 13, 2011 at 3:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: I _think_ we consider that a bug in Gecko. It does violate a should in HTML5, added a while back in reply to that bug: A br element should separate paragraphs for the purposes of the Unicode bidirectional algorithm. http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-br-element
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On 11-05-13 2:25 PM, Boris Zbarsky wrote: I just tested innerHTML, and I found it stripped the attribute, but it didn't seem to add any whitespace aroundbr,ol, orli. 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. I think that's true, as we don't expose pretty printed serialization of the DOM to the web to the best of my knowledge. Cheers, Ehsan
Re: [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 werediv id=foo? What if it werediv class=foo but the class applied some styles like borders that you'd change if you duplicated it? What if it werediv 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 becomediv class=foobarbr|/div, ordiv class=foobardiv|/div/div, ordiv class=foobarp|/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 todiv 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 inputp[foo]/p to Chrome 12 dev and run insertOrderedList, it produces the DOM (expressed in XML) polli[foo]br //li/ol/p, which when you serialize to text/html and unserialize becomesp/polli[foo]br //li/olp/p. Firefox generates ollifoo/li/ol. * If you givep[foo]/p to Opera 11.10 and run indent, it produces pblockquote[foo]/blockquote/p, which becomes p/pblockquote[foo]/blockquotep/p after round-tripping through text/html. Firefox generates p style=margin-left: 40px;foo/p. * If you giveollidiv[foo]/divbar/li/ol to IE9 and run outdent, you getpdiv[foo]/divbar/p, which round-trips to p/pdiv[foo]/divbarp/p. (I didn't find a simpler scenario where it produced such DOMs, to its credit.) A better form for output is divfoo/divdivbar/div I think (Firefox handles this very badly: ollifoobar/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 areps in the input for whatever reason, but not producingps 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 againstp because of the margin and serializability issues, and undecided betweenbr anddiv.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 usingbr), but it adds more clutter, and all browsers do outputbr by default in some cases. I guess I'm leaning toward usingbr 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
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On 11-05-13 1:48 PM, Ryosuke Niwa wrote: On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregorsimetrical+...@gmail.comwrote: Note that br and div affect UBA differently so we must consider what bidirectional text users want as well. For example, if we haddiv dir=rtlhello/div, and inserted br as in div dir=rtlhellobr/div, then we preserve the RTL directionality. If we insert div on the other hand,div dir=rtlhello/divdiv/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. This is a very good point. I know that p constitutes a UBA paragraph. Does the same apply to div as well? 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. I agree that we should use br for Shift+Enter, but I'm not sure if I agree with your rationale on using div for Enter. Backwards compatibility is not a strong argument if you consider Gecko for example. And I'm not sure if we need to comply with what Google web properties expect. The result of the final spec is going to be different to what each browser implements today, so web apps might need to change anyway. Furthermore, such web products would not work correctly in Gecko if the code is expecting divs today. Cheers, Ehsan
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On Fri, May 13, 2011 at 3:35 PM, Ehsan Akhgari eh...@mozilla.com wrote: On 11-05-13 1:48 PM, Ryosuke Niwa wrote: On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregorsimetrical+...@gmail.com wrote: Note that br and div affect UBA differently so we must consider what bidirectional text users want as well. For example, if we haddiv dir=rtlhello/div, and inserted br as in div dir=rtlhellobr/div, then we preserve the RTL directionality. If we insert div on the other hand,div dir=rtlhello/divdiv/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. This is a very good point. I know that p constitutes a UBA paragraph. Does the same apply to div as well? Yes. Any block element will do. - Ryosuke
[whatwg] Pressing Enter in contenteditable: p or br or div?
Behavior for Enter in contenteditable in current browsers seems to be
as follows:
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a line when you start typing, but when
you hit Enter it wraps the new line in a div. Hitting Enter
multiple times outputs divbr/div, and Shift-Enter always inserts
br.
* Opera 11.10 wraps in p like IE, but for blank lines it uses
pbr/p instead of just p/p (they render the same).
What behavior do we want?
A problem with p is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translates p and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
Another problem with p is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things inside p that will break out of the p,
and I've done it myself by mistake too.
The problem with br is that it's a pain to deal with. It forces you
to deal with lines as sequences of adjacent sibling nodes instead of
as a single node. Also, sometimes br doesn't do anything, like
(usually) a single br at the end of a block box, but when you add
something after it it suddenly starts doing something. If lines
aren't wrapped in block elements, then whenever you have to move
around some text, you need to be sure that you check that you're not
removing a br or failing to move one and thereby running two lines
together, or leaving an extra br someplace so there are now two in a
row. I've seen bugs to this effect in multiple browsers, where they
don't insert a br when they should (but behave fine with div/p),
and have made the mistake a lot myself.
So my current thought is to demarcate lines with divs consistently,
only using br when there are multiple line breaks in a row. This is
unlike any current browser, since everyone uses br at least for
Shift-Enter. If this is the way we want to behave, then I'll also
have commands normalize nearby brs to divs where it makes things
easier, like I normalize other types of markup.
Feedback appreciated.
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
On 5/12/11 4:28 PM, Aryeh Gregor wrote: * Firefox 4.0 just usesbr _moz_dirty= for Enter and Shift-Enter, always. (What's _moz_dirty for?) It's used when serializing: things with _moz_dirty are prettyprinted even if the serialization is trying to preserve the original whitespace layout of the HTML in general. The fact that it's an actual content attribute is a bug dating back to when there was no other good way to associate state to an element in Gecko; we just need to fix that. See https://bugzilla.mozilla.org/show_bug.cgi?id=459212 -Boris
Re: [whatwg] Pressing Enter in contenteditable: p or br or div?
* IE9 wraps all lines in p (including if you start typing in an
empty text box). If you hit Enter multiple times, it inserts empty
ps. Shift-Enter inserts br.
* Firefox 4.0 just uses br _moz_dirty= for Enter and Shift-Enter,
always. (What's _moz_dirty for?)
* Chrome 12 dev doesn't wrap a line when you start typing, but when
you hit Enter it wraps the new line in a div. Hitting Enter
multiple times outputs divbr/div, and Shift-Enter always inserts
br.
* Opera 11.10 wraps in p like IE, but for blank lines it uses
pbr/p instead of just p/p (they render the same).
What behavior do we want?
A problem with p is that it has top and bottom margins by default,
so hitting Enter once will look like a double line break. One
real-world execCommand() user I looked at (vBulletin) sets p { margin:
0 } for its rich-text editor for this reason, and translates p and
div to line breaks on the server side. The usual convention in text
editors is that hitting Enter only creates one line break, although
Word 2007 seems to do two by default.
But it also has the semantic property of being a paragraph, which is an
advantage I think.
There is also one more question to answer. If we're already in a block level
element, what should happen when pressing Enter? For example, for div
class=foobar|/div, what should happen after pressing enter? I think the
sane thing to do is to create div class=foobar/divdiv
class=foo|/div (since the div might be styled on the page, and not
preserving the block's tag or class attr would take that away.
Another problem with p is that it's very easy to create
unserializable DOMs with it. I've seen cases where at least some
browsers will put things inside p that will break out of the p,
and I've done it myself by mistake too.
Would you elaborate, please? Specifically, are you saying that in it's
inferior to div in this regard?
The problem with br is that it's a pain to deal with. It forces you
to deal with lines as sequences of adjacent sibling nodes instead of
as a single node. Also, sometimes br doesn't do anything, like
(usually) a single br at the end of a block box, but when you add
something after it it suddenly starts doing something. If lines
aren't wrapped in block elements, then whenever you have to move
around some text, you need to be sure that you check that you're not
removing a br or failing to move one and thereby running two lines
together, or leaving an extra br someplace so there are now two in a
row. I've seen bugs to this effect in multiple browsers, where they
don't insert a br when they should (but behave fine with div/p),
and have made the mistake a lot myself.
br is considered to be the standard way of representing line breaks, which are
part of the content. About the problems that you're mentioning, I think we
need to address them anyways, since brs might already be in the content even
without having them assigned to Shift+Enter.
So my current thought is to demarcate lines with divs consistently,
only using br when there are multiple line breaks in a row. This is
unlike any current browser, since everyone uses br at least for
Shift-Enter. If this is the way we want to behave, then I'll also
have commands normalize nearby brs to divs where it makes things
easier, like I normalize other types of markup.
I think we want to keep using brs, but I'm not convinced if div is a better
choice than p.
Cheers,
--
Ehsan Akhgari
eh...@mozilla.com
http://ehsanakhgari.org/
