Open Bug 1271835 Opened 9 years ago Updated 3 years ago

Enter for new Paragraph option should also create <p> when in blockquote

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Version:
45 Branch
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: realRaven, Unassigned)

References

Details

If the new option "Enter creates a new paragraph" is enabled, this should also apply when hitting enter within a <blockquote>. At the moment the <blockquote> is split, as expected but the new part is in "body" level. It should also be in <p> paragraph mode like in the top (bottom) part of the email.
That's certainly relevant when replying to a message inline within a quote, where you'd split the quote in that way to add comments to its individual parts. This may be tricky though, given that the <p> mode is enforced after the message body has been prepared for the editor, whereas in this case it happens during editing of the message.
Summary: Enter for new Paragrph option should also create <p> when in blockquote → Enter for new Paragraph option should also create <p> when in blockquote
As you are aware, that would need a change in the unowned and unmaintained M-C editor. Also, what you ask for is close to impossible. New paragraphs are created when you are already in a paragraph and you split it by hitting <enter>. If you split a block quote, how should the M-C editor know that TB has an option that requests paragraphs? Actually, it doesn't even have such an option. All it has is an option to drive the behaviour of the <enter> key in paragraph mode. That we start off in paragraph mode when the option is set, is perhaps a conflation of two issues. In SM they will have two options, one for the <enter> key behaviour and one for the format to start composing in. With the second option in place you may have a chance to do what you're asking for.
Severity: normal → enhancement
(In reply to Jorg K (PTO during summer, NI me) from comment #2) > As you are aware, that would need a change in the unowned and unmaintained > M-C editor. Yes - I am just describing "desired behavior" - I have no idea how to technically implement that. Without it I have to remember always to manually reach for the Paragraph style each time I reply inline; so it is purely a convenience feature. > > Also, what you ask for is close to impossible. New paragraphs are created > when you are already in a paragraph and you split it by hitting <enter>. If > you split a block quote, how should the M-C editor know that TB has an > option that requests paragraphs? I have no idea :) Could the editor code be forked to a "C-C editor" to make this possible? Otherwise we are putting this off again until such time that it is replaced by a completely different component, and there might not be any manpower for that to happen any time soon.
(In reply to Axel Grude [:realRaven] from comment #3) > Could the editor code be forked to a "C-C editor" to make this possible? Just for this feature? ugh... > Otherwise we are putting this off again until such time that it is > replaced by a completely different component, and there might not be > any manpower for that to happen any time soon. Which "completely different component" are you thinking of? Either we like such an upcoming hypothetical component or we fork editor then, if and when that comes at all.
While I cannot comment on the technical difficulty, my experience is similar to Axel. That is, when I first started using the paragraph feature, it seemed to be that sometimes Enter caused two lines, sometimes one line. I found it confusing. I've figured out it is related to quoting. But since I quote frequently, it takes a lot of effort now to check whether I am in paragraph mode or blockquote mode. I've tried manually changing to paragraph mode when quoting, but that takes a lot of effort. So although I like paragraph mode, this issue makes it less useful for me. Not sure what the solution is.
Like I commented in bug 1273841, there's not really a reason editor.CR_creates_new_p true would not create a new paragraph just because you're inside a blockquote. Yes it doesn't work atm, but there' no reason it should not. It doesn't even look like it might be that difficult to fix - http://mxr.mozilla.org/comm-central/source/mozilla/editor/libeditor/nsHTMLEditRules.cpp#6242
As the comment says: ReturnInParagraph: do the right thing for returns pressed in paragraphs This bug is about splitting blockquotes, not paragraphs. M-C editor bug fix volunteers, please raise your hands ;-) Actually, this is not even a bug, it's an enhancement. As I said, I reckon the bug is close to impossible to fix in the M-C editor. When splitting a block quote, why would it insert a <p> and not a, say, <pre>? In word processors, you can chose which style should follow another, for example, hitting enter after a heading doesn't create another heading by some other definable style. Note that the M-C editor already inserts a paragraph after a heading. Not bad, hey? To fix the bug, we'd need to implement a callback to ask for the tag to be inserted upon split, or we'd have to implement a listener in C-C code that catches blockquote splits and inserts the necessary <p>br></p>. But that should be driven off another preference, as I stated in bug 1273841 comment #16.
(In reply to Jorg K (PTO during summer, NI me) from comment #7) > As the comment says: > ReturnInParagraph: do the right thing for returns pressed in paragraphs > This bug is about splitting blockquotes, not paragraphs. > M-C editor bug fix volunteers, please raise your hands ;-) Actually, this is > not even a bug, it's an enhancement. Agreed. > > As I said, I reckon the bug is close to impossible to fix in the M-C editor. > When splitting a block quote, why would it insert a <p> and not a, say, > <pre>? Because in html, <p> should be the default for any new block level element. It should be the default after entering a <h1> and it should be the default after the signature. It should just be the default to avoid being in <body>. Because in HTML mail we are usually not building a web page but writing paragraphs. I thought that using the [x] paragraph option should be about this behavior. > In word processors, you can chose which style should follow another, for > example, hitting enter after a heading doesn't create another heading by > some other definable style. Note that the M-C editor already inserts a > paragraph after a heading. Not bad, hey? Yes and that it great. I think (as I described above) one "default tag" should be configurable, and <p> seems to be what a lot of online WYSIWYG editors (e.g. confluence, mdn) use. There are also other convenience hacks like hitting enter twice to close of a <ul> and return to <p> again. > > To fix the bug, we'd need to implement a callback to ask for the tag to be > inserted upon split, or we'd have to implement a listener in C-C code that > catches blockquote splits and inserts the necessary <p><br></p>. The <br> in there is something I never understood, <p> is already display:block, so <br> shouldn't be necessary. It is something to do with the way the editor is implemented and cannot really be avoided, or is there another reason for it? > But that > should be driven off another preference, as I stated in bug 1273841 comment > #16. That one is new to me - can we roll this into it?
Depends on: 1273841
(In reply to Axel Grude [:realRaven] from comment #8) > That one is new to me - can we roll this into it? Not really, the other bug is merely about untangling the two functions that editor.CR_creates_new_p currently has. It doesn't touch the actual implementation at all, just basing it off a 2nd pref.
(In reply to Axel Grude [:realRaven] from comment #8) > The <br> in there is something I never understood, <p> is already > display:block, so <br> shouldn't be necessary. It is something to do with > the way the editor is implemented and cannot really be avoided, or is there > another reason for it? The M-C editor strips empty paragraphs. Try it one day in ThunderHTMLedit. Insert <p></p>, switch back to the edit tab, do an edit, so the HTML will refresh, go back to the HTML, what you inserted is gone. > > But that should be driven off another preference, as I stated in > > bug 1273841 comment #16. > That one is new to me - can we roll this into it? No. I only suggested to use a different preference to drive the "default tag".
(In reply to Jorg K (PTO during summer, NI me) from comment #7) > As I said, I reckon the bug is close to impossible to fix in the M-C editor. > When splitting a block quote, why would it insert a <p> and not a, say, > <pre>? Because that would make no sense :) <p> is just a very reasonable default since what you ultimately do in "content" is write text and that is done in paragraphs. Even if the guess is wrong and you'd want to change to something else, it doesn't really matter if you swith from <body> to some other type, or from <p> to some other type. What we do know is that <body> is wrong. > In word processors, you can chose which style should follow another, for > example, hitting enter after a heading doesn't create another heading by > some other definable style. Note that the M-C editor already inserts a > paragraph after a heading. Not bad, hey? In word processors you *never* get into any <body> mode. You're not really supposed to put any content directly in <body> in html either, but of course it works (except it limits quite a bit how you can style things). That the editor already puts <p> after a heading is just proof that going into <p> after certain elements is the right thing to do.
From https://bugzilla.mozilla.org/show_bug.cgi?id=1273841#c18 > If we change the blockquote splitting, we should control it with the second > preference, which should perhaps read: > [ ] Use Paragraph format instead of Body Text by default. +1 for that. Whatever the default behavior is should apply to the start of an email and splitting any blockquotes. there might be other places (such as being before / after signature) basically everywhere where the old behavior would have dropped the cursor back up into <body> level; they could all be controlled by this new checkbox. Should the amount of vertical paragraph spacing be eventually controllable by UI?
(In reply to Axel Grude [:realRaven] from comment #12) > Should the amount of vertical paragraph spacing be eventually controllable > by UI? I don't think so, we've just discussed this in bug 1250051 comment #24.
FYI here, the new preference is mail.compose.default_to_paragraph (bug 1273841 just landed).
Apparently there's a special method just for mail quotes nsHTMLEditRules::SplitMailCites, so a fix should be around here: http://mxr.mozilla.org/comm-central/source/mozilla/editor/libeditor/nsHTMLEditRules.cpp#1741
Yes, it creates <br>s. The difficulty will be to communicate that we want <p> instead.
You'd need to add an attribute to nsIHTMLEditor.idl, say /// A boolean indicating if the default compose mode is <p> (as opposed to <body>). attribute boolean paragraphMode; ... and hook that up to mail.compose.default_to_paragraph in MsgComposeCommands.js
Good idea. Something we should be able to do for TB 52.
Note that in bug 1304365 people complained about the style changing after a horizontal line is added.
Sorry, correction: Note that in bug 1304366 people complained about the style changing after a horizontal line is added.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.