Closed
Bug 285873
Opened 19 years ago
Closed 19 years ago
Pref "editor.CR_creates_new_p" should default to true
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: ilya.konstantinov+future, Assigned: mozeditor)
References
Details
Attachments
(1 file, 1 obsolete file)
10.20 KB,
patch
|
Brade
:
review+
bzbarsky
:
superreview+
chofmann
:
approval1.8b3+
|
Details | Diff | Splinter Review |
The "editor.CR_creates_new_p" pref, which controls whether Enter/Return key will create a new Paragraph at the insertion point, should default to 'true' due to the following reasons: 1. CMS systems which rely on MIDAS expect this behavior (like Microsoft's HTML Editor control provides). 2. Users expects paragraphs on pressing Enter (experience from other editors, such as: Microsoft RichText Control, Microsoft Word, Netscape Composer). 3. BiDi Users need a convenient way to enter new paragraphs, as they're used to in other apps (see point 2), since only paragraphs may assume direction.
Comment 1•19 years ago
|
||
I think this sounds reasonable. What's the command for forced line breaks when this pref is set to true? To change the default, one should just have to change editor/ui/composer.js (somewhere near the file end); so this bug is just to discuss whether to do this or not. Right?
Reporter | ||
Comment 2•19 years ago
|
||
1. Assuming Mozilla implements the common practice, Enter shall insert Paragraph Breaks and Shift-Enter shall insert Line Breaks. 2. True. This bug is for: a) Getting the maintainer's agreement for the change, b) Tracking the creation and applying of the patch.
Comment 3•19 years ago
|
||
A CMS using midas could set this attribute on the editor, returnInParagraphCreatesNewParagraph, couldn't it? If that's true the argument about a CMS telling all users to change their pref wouldn't really apply; the owner of a CMS could force it if they felt that strongly about it. Should <p> behavior should be the default may boil down to: are there more users who understand the difference between p and br, and notice the lack of paragraphs, than there are users who will be confused by our inability to put the cursor on a blank line between paragraphs (bug 85505)? If the default is changed, don't forget to make sure there's code to set returnInParagraphCreatesNewParagraph explicitly for any context which expects the old behavior, such as mailnews.
Reporter | ||
Comment 4•19 years ago
|
||
For BiDi users, this functionality is mostly important in mailnews. How does Outlook Express handle this issue? I'm quite sure it inserts new paragraphs upon Enter. Are the users of Outlook Express confused by the margins which paragraphs introduce?
Comment 5•19 years ago
|
||
For HTML (Composer) this is a good idea to me (because <p></p> should be preferred to <br />), and there's also the UI to set this preference easily. In Outlook (not Outlook Express), the enter key creates a new paragraph in HTML mode, in plain text (of course) and RTF modes it creates a new line. As I don't use Mozilla for email purposes, I don't have that much experience; are there different message "modes" (like HTML/plain text)?
Comment 6•19 years ago
|
||
IMHO, Midas should always create paragraphs. That is, the user's pref wrt. Composer should not break Midas.
Comment 7•19 years ago
|
||
This does *not* change the default value of the pref, and I don't have the time to fight that battle and get the caret bugs fixed etc to do that now, but this *does* make it so that we always insert new <p>'s when the user hits return.
Attachment #178539 -
Flags: superreview?(bzbarsky)
Attachment #178539 -
Flags: review?(brade)
Comment 8•19 years ago
|
||
Comment on attachment 178539 [details] [diff] [review] Make midas always get new <p>'s on enter (the path of least resistance). sr=bzbarsky, but we now have two places in editing session that have to do this designMode check... it may be worth factoring it out into a separate method.
Attachment #178539 -
Flags: superreview?(bzbarsky) → superreview+
Comment 9•19 years ago
|
||
Comment on attachment 178539 [details] [diff] [review] Make midas always get new <p>'s on enter (the path of least resistance). The code itself is fine but I think we need to offer a command for changing the behavior. I don't think we should change the default without this command. Developers should be able to control the behavior. jst: thanks for the patch; I hope someone will be able to build on it to give developers the control. p.s. the editor pref is specific to Composer. It should not be changed or apply to Midas/MailCompose/etc. The subject of this bug is invalid but I understand what is being asked.
Attachment #178539 -
Flags: review?(brade) → review-
Reporter | ||
Comment 10•19 years ago
|
||
Brade, the interest of the BiDi crowd is mainly about changing MailCompose behavior. To achieve that, should I fill out another bug? If so, what should be the subject?
Comment 11•19 years ago
|
||
Comment on attachment 178539 [details] [diff] [review] Make midas always get new <p>'s on enter (the path of least resistance). Brade, the whole point of this is to be compatible with IE, anything else makes little sense to me as far as details like this goes. Right now we're causing everyone who's using midas headaches due to this difference. Can you control how this works in IE? I don't think so (correct me if I'm wrong), so based on that I really don't think we need anything more than what this patch does already. Re-requesting review.
Attachment #178539 -
Flags: review- → review?(brade)
Comment 12•19 years ago
|
||
I agree with jst. I don't think it makes sense to delay this in order let Web developers control it when there don't seem to be any Web developers who would want the <br> behavior--especially considering that IE does the right thing anyway.
Comment 13•19 years ago
|
||
brade, I don't normally duplicate comments, but since this issue was split off into a new bug, I think this bears repeating. Sorry if I seem very insistent, but on behalf of all the CMS systems out there, please take a minute to read this - it's very important to us (and to the blind people that use our systems) that Mozilla inserts <p>, not <br> when you press return in the Midas control. Our accessibility compliance goes out the window the moment anyone uses a Mozilla- based browser with our systems. There are numerous problems with the current fix: - There is an option so you can choose if you want buggy behaviour (br) or correct behavior (p) in the prefs (which I can live with) - Problem is, the buggy behaviour is the default (it inserts <br> instead of <p> - To add insult to injury, the checkbox for buggy behavior (<br>) can't be switched off on the Mac build of Moz because of widget rendering issues. I'm not looking forward to telling people "oh, btw - all Mozilla users have to go to their prefs dialog and switch off the checkbox to use $WEB_BASED_CMS_SYSTEM_X properly". There are numerous standards and accessibility reasons to having <p> be the default too, if you need references to this, I can dig them up. I believe this point has been flogged to death in this thread already, so I won't repeat the arguments. Can we let the default be <p>, and then the <br> guys can adjust their prefs if they like linebreaks instead? Being consistent with every other browser and word processing app on the planet sounds like a sane default to me. Disclaimer: I have a special interest in this bug since we produce an open source CMS system, and we still can't recommend Mozilla/Firefox as the preferred browsers in large enterprise CMS deployments because of this tiny issue. If Mozilla could insert <p> by default, we could. I have been tracking this bug for over 2 years, and when it's this close to being fixed, I believe it should be done properly. Sorry if this comes across as a rant, but it is very important to all the web- based CMS vendors out there that this behaviour is corrected.
Comment 14•19 years ago
|
||
Now Safari has this right. So CMS makers can recommend Safari in addition to IE. brade, could you please elaborate *why* you believe developers should be able to control the behavior of Midas as opposed to Midas always creating a paragraph on return like IE and Safari do? There don't seem to be people outside the old Composer team who want the br behavior.
Comment 15•19 years ago
|
||
Looks like brade isn't even seeing the follow-ups.
(In reply to comment #14) > brade, could you please elaborate *why* you believe developers should be able to > control the behavior of Midas as opposed to Midas always creating a paragraph on > return like IE and Safari do? There don't seem to be people outside the old > Composer team who want the br behavior. Because Midas can be used for "rich" email where people almost never care about the structure and semantics because they DON'T HAVE to. All they want is a richer rendering. So I entirely agree with brade: the pref should not control Midas, and what the CR creates in Midas should be command-based.
Comment 17•19 years ago
|
||
Ilya Konstantinov (comment 10) -- If you want to change the behavior in MailCompose, you should be lobbying the Mail team for a new pref (so yes, you need a new bug). The bug's summary could be something like "Mail compose needs pref to toggle behavior of [enter] key in editor"; please cc me on that new bug. jst (comment 11) -- Yes, the behavior in IE's MSHTML editor can be controlled. Alexander Limi (comment 13) -- I understand the need for <p> to be the default behavior for Midas and I support that but I think it is important for developers to be able to have the current behavior (as Daniel explains in comment 16). All I am asking for is for developers to be able to get either behavior. I don't understand this part of your comment: > - To add insult to injury, the checkbox for buggy behavior (<br>) can't be > switched off on the Mac build of Moz because of widget rendering issues. > > I'm not looking forward to telling people "oh, btw - all Mozilla users have > to go to their prefs dialog and switch off the checkbox to use > $WEB_BASED_CMS_SYSTEM_X properly". Mozilla users should NOT be able to set a pref (e.g. click a checkbox) to control the Midas behavior for <p> / <br>. This functionality is up to the web developers (who may or may not offer it as an option). Henri -- thanks for cc'ing me.
(In reply to comment #17) > Mozilla users should NOT be able to set a pref (e.g. click a checkbox) to > control the Midas behavior for <p> / <br>. This functionality is up to the web > developers (who may or may not offer it as an option). 100% agreed.
Comment 19•19 years ago
|
||
(In reply to comment #16) > Because Midas can be used for "rich" email where people almost never care about > the structure and semantics because they DON'T HAVE to. All they want is a > richer rendering. > So I entirely agree with brade: the pref should not control Midas, and what the > CR creates in Midas should be command-based. This issue is important to different groups of people for different reasons- why must we all receive the same treatment? I'm a CMS/web developer, and when I originally looked at through-the-web editing solutions, this particular issue was my first concern and browser compatibility came second. I ended up implementing Kupu (kupu.oscom.org), which is cross- browser, but I'm currently asking my clients to use Internet Explorer, for this issue alone. Even if it were fixed as a client-side switch, it would still be nconvenient and impossible for me to have to hand-configure every computer my clients use to update their site. Is there any way the web application can control this behaviour? Also, if folks using the composer don't care about structure and semantics, why would they care either way? Please discuss further, Izaak
Comment 20•19 years ago
|
||
(In reply to comment #18) > (In reply to comment #17) > > > Mozilla users should NOT be able to set a pref (e.g. click a checkbox) to > > control the Midas behavior for <p> / <br>. This functionality is up to the web > > developers (who may or may not offer it as an option). > > > 100% agreed. With all respect, this is still a bug, and such a proposed fix is a new feature. It impacts a lot of folks if something doesn't land before release. This is a serious crutch to business users adopting non-IE browsers, as the writable-web is a way to get business-users to actually change habits when it comes to browser choice. If Moz 1.8 and Firefox 1.1 are released without a solution for the communities that need well-formed paragraph content and predictably stylable DOMs (this goes beyond the CMS crowd), it ends up being inconsistent with every other major browser (Safari, Opera, MSIE) for purposes of consistency with the past. "Tradition" is unfortunately a circular argument when trying to justify something, and though a developer-controlled API option or similar is _necessary_ to approach this, it is not _sufficient_. Something needs to be done before release or _dozens_ of open source projects using Mozilla browsers are out in the cold.
Comment 21•19 years ago
|
||
Nominating as an Aviary 1.1 blocker, because this is a big deal for CMS vendors.
Flags: blocking-aviary1.1?
Comment 22•19 years ago
|
||
Attachment #178539 -
Attachment is obsolete: true
Updated•19 years ago
|
Attachment #184737 -
Flags: superreview?(bzbarsky)
Attachment #184737 -
Flags: review?(brade)
Updated•19 years ago
|
Attachment #178539 -
Flags: superreview+
Attachment #178539 -
Flags: review?(brade)
Comment 23•19 years ago
|
||
The patch I just attached here makes the default for the return-inside-p when using midas be to create new p's instead of inserting br's, and if a page developer doesn't like that it can be changed with the boolean command "insertBrOnReturn". How's that sound? I can change the name of the command if others have thoughts on what that should be...
Comment 24•19 years ago
|
||
Comment on attachment 184737 [details] [diff] [review] Make midas always get new <p>'s on enter (the path of least resistance), but give a way for site developers to control this if needed. >Index: editor/composer/src/nsComposerDocumentCommands.cpp >+ nsresult rvCSS = aParams->GetBooleanValue(STATE_ATTRIBUTE, >+ &insertBrOnReturn); rvBR, perhaps? nothing related to CSS in this block... sr=bzbarsky with the nit picked.
Attachment #184737 -
Flags: superreview?(bzbarsky) → superreview+
This is a side comment on the patch : it does not change the behavior of the return key at the end of a header (h1-h6) or a double return key in a list to stop the list. Those actions will still create a bodytext and not a paragraph, right?
Comment 26•19 years ago
|
||
Comment on attachment 184737 [details] [diff] [review] Make midas always get new <p>'s on enter (the path of least resistance), but give a way for site developers to control this if needed. r=brade (with bz's nit) I'd probably prefer "cmd_insertPOnReturn" but I'm mostly indifferent. Daniel's point (if true) could be considered a bug (and handled in a separate bug). Daniel--what behavior does Composer have for typing in headers? Is it desirable for this flag to handle h1-h6 too or ?
Attachment #184737 -
Flags: review?(brade) → review+
(In reply to comment #26) > Daniel--what behavior does Composer have for typing in headers? Is it > desirable for this flag to handle h1-h6 too or ? |nsHTMLEditRules::ReturnInHeader| splits the header in two if the selection is not at the end of the element. If the selection ends the header before the CR, then a new br is inserted right after the header and the caret is placed right before it. That method should be modified to listen to the new pref and create a paragraph instead of a br.
(In reply to comment #26) > Daniel's point (if true) could be considered a bug This is not a bug since it was never a feature in the past. It's really a RFE.
Updated•19 years ago
|
Attachment #184737 -
Flags: approval1.8b3?
Comment 29•19 years ago
|
||
Comment on attachment 184737 [details] [diff] [review] Make midas always get new <p>'s on enter (the path of least resistance), but give a way for site developers to control this if needed. a=chofmann
Attachment #184737 -
Flags: approval1.8b3? → approval1.8b3+
Comment 30•19 years ago
|
||
Fixed. Brade, I decided to leave the command name as is since I think it makes more sense to make it mention inserting br instead of a specific tag that this behaviour has an affect in since it sounds like this should control more than <p>. If you disagree and want it changed, please file a followup bug on that issue.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Comment 31•19 years ago
|
||
*** Bug 305893 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•