To repro: 1. Create a contentEditable region with a blockquote. 2. Put your cursor in the blockquote. 3. Hit [enter] Expected Result: There should be one blockquote. Actual Result: There are two blockquotes! Notes: Behaves as expected on IE6 and FF3 The demo here http://www.nick-santos.com/tests/content_editable_contents.html provides an easy interface to see this problem. You can also see it on: http://notebook.google.com/ when you put your cursor in the blue region of a note and hit [enter]
This is a dup of https://bugs.webkit.org/show_bug.cgi?id=17460. Sorry, I don't know how to properly mark as dup.
Sorry, I was confused. This is not a dupe.
(In reply to comment #1) > This is a dup of https://bugs.webkit.org/show_bug.cgi?id=17460. Sorry, I don't > know how to properly mark as dup. Well, that bug is about how we clone <h{1,5}> tags. The report here is about how we clone blockquotes... The other browsers break out of blockquotes? Perhaps we should adopt this behavior. We do it for the blockquotes that Apple Mail creates...
(In reply to comment #0) > You can also see it on: > http://notebook.google.com/ > when you put your cursor in the blue region of a note and hit [enter] I don't see it here. Has the issue already been worked around?
On http://notebook.google.com/, you have to hit the "comment" button to see the blue region of a note. The other browsers create a line break by changing the blockquote to: <blockquote>before line break <p>after line break</blockquote>
(In reply to comment #5) > The other browsers create a line break by changing the blockquote to: > <blockquote>before line break <p>after line break</blockquote> My testing shows that FireFox uses a <br> and IE uses a nested paragraph element (it also apparently wraps the "before line break" in a <p> element. IE will use a <br> on shift return. Is there one behavior that's preferable here? Personally I think that we want the ability to both add a newline inside the blockquote and to split it (as Google Mail's editor and Apple Mail does). As for how the first is implemented internally, I'm not sure which is better.
(In reply to comment #6) > (In reply to comment #5) > > The other browsers create a line break by changing the blockquote to: > > <blockquote>before line break <p>after line break</blockquote> > > My testing shows that FireFox uses a <br> and IE uses a nested paragraph > element (it also apparently wraps the "before line break" in a <p> element. IE > will use a <br> on shift return. Is there one behavior that's preferable here? > > Personally I think that we want the ability to both add a newline inside the > blockquote and to split it (as Google Mail's editor and Apple Mail does). When I say "split" here I mean that pressing return here: <blockquote>before^after</blockquote> would create something like: <blockquote>before</blockquote> <div>^<br></div> <blockquote>after</blockquote>
(In reply to comment #6) > My testing shows that FireFox uses a <br> and IE uses a nested paragraph > element (it also apparently wraps the "before line break" in a <p> element. IE > will use a <br> on shift return. Is there one behavior that's preferable here? Ah, you're correct. I know that the Google products that really really care about this behavior actually cancel the default enter-handling in IE, and manually insert a <br> . So I'm tempted to say the <br> is better. Julie will know lots more about this than I do though... > Personally I think that we want the ability to both add a newline inside the > blockquote and to split it (as Google Mail's editor and Apple Mail does). As > for how the first is implemented internally, I'm not sure which is better. It'd be wonderful if browsers natively supported both splittable and unsplittable blockquotes. Maybe there should be a magic CSS style for it? (e.g., -webkit-blockquote-split: {on, off})
Big thanks to Ben Pew for helping me test this in IE.
I'm not certain if this is considered as a bug to fix because if we always insert a br or other element, then how do we get out of a blockquote? In Firefox 3.5, there does not seem anyway to get out of a blockquote. In addition, WebKit DOES insert BR for Control+Enter. WebKit's behavior is better since we let a user chose which behavior to use.
Specification: http://aryeh.name/spec/editing/editing.html#the-insertparagraph-command Currently it defines the idea of a "single-line container", which means: "address", "div", "h1", "h2", "h3", "h4", "h5", "h6", "listing", "p", "pre", "xmp", "li", "dt", or "dd". When you hit enter, the nearest single-line container is generally split, except for address/listing/pre, where I add a <br>. I do *not* define blockquote as a single-line container. It's meant to contain multiple lines. If you have <blockquote>foobar</blockquote> and insert a line in between "foo" and "bar", you get <blockquote><p>foo</p><p>bar</p></blockquote> per my spec currently. This matches IE/Opera, and IMO makes the most sense. Consecutive <blockquote>s don't make sense any more than consecutive <b>'s make sense -- they should be merged. If you want to split a blockquote, my spec says that hitting Backspace (or running the delete command, same thing) at the beginning of an indented line outdents that line. This is how Word 2007 behaves, and OpenOffice.org, but browsers currently don't. So in other words, if you have <blockquote><p>foo</p><p>[]bar</p><p>baz</p></blockquote> and backspace, you get <blockquote><p>foo</p></blockquote><p>[]bar</p><blockquote><p>baz</p></blockquote> Are there any problems with the spec's behavior here? Should it change? What do the mail programs referred to in comment #6 and comment #8 do and want to do? AFAICT, Chrome's current behavior allows no way to break out of blockquotes at all.