WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
19416
Hitting [enter] inside a blockquote creates a new blockquote
https://bugs.webkit.org/show_bug.cgi?id=19416
Summary
Hitting [enter] inside a blockquote creates a new blockquote
Nick Santos
Reported
2008-06-06 14:46:09 PDT
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]
Attachments
Add attachment
proposed patch, testcase, etc.
Julie Parent
Comment 1
2008-06-06 14:54:19 PDT
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.
Julie Parent
Comment 2
2008-06-06 15:00:53 PDT
Sorry, I was confused. This is not a dupe.
Justin Garcia
Comment 3
2008-06-06 15:01:51 PDT
(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...
Justin Garcia
Comment 4
2008-06-06 15:04:05 PDT
(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?
Nick Santos
Comment 5
2008-06-06 15:08:42 PDT
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>
Justin Garcia
Comment 6
2008-06-11 15:27:01 PDT
(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.
Justin Garcia
Comment 7
2008-06-11 15:30:24 PDT
(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>
Nick Santos
Comment 8
2008-06-14 16:17:05 PDT
(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})
Justin Garcia
Comment 9
2008-06-19 22:16:51 PDT
Big thanks to Ben Pew for helping me test this in IE.
Ryosuke Niwa
Comment 10
2010-03-19 10:14:48 PDT
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.
Aryeh Gregor
Comment 11
2011-08-19 12:16:34 PDT
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug