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)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: ilya.konstantinov+future, Assigned: mozeditor)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
Depends on: 92686
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?
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.
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.
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?
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)?
IMHO, Midas should always create paragraphs. That is, the user's pref wrt.
Composer should not break Midas.
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 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 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-
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 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)
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.
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.
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.
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.
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.
(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
(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.
Nominating as an Aviary 1.1 blocker, because this is a big deal for CMS vendors.
Flags: blocking-aviary1.1?
Attachment #184737 - Flags: superreview?(bzbarsky)
Attachment #184737 - Flags: review?(brade)
Attachment #178539 - Flags: superreview+
Attachment #178539 - Flags: review?(brade)
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 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 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.

Attachment #184737 - Flags: approval1.8b3?
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+
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
Flags: blocking-aviary1.1?
Depends on: 301490
*** 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.

Attachment

General

Created:
Updated:
Size: