Closed Bug 16423 Opened 25 years ago Closed 23 years ago

Do not insert   when user types two spaces at sentence end.

Categories

(Core :: DOM: Editor, enhancement, P3)

enhancement

Tracking

()

VERIFIED WONTFIX
Future

People

(Reporter: otto, Assigned: mozeditor)

References

()

Details

(Keywords: helpwanted)

Attachments

(1 file)

According to the design document (above URL) the intended behavior is to
replace a space with "nbsp+space" when I type two spaces at the end of a
sentence.  I have verified this is the case with M10 on NT4(SP3).

I request, on the behalf of touch-typists everywhere, that this not be the
case.  The technical rule for typists is that a sentence is followed by two
spaces.  It's a holdover from the typerwriter days, when it made sense... and
those of us who took touch-typing in high school have the damndest time
breaking the habbit. :) So, any HTML us touch-typists create using the new
editor (and the old 4.x Composer, incidentally) is riddled with extraneous
nbsp's.

Suggested behavior is to insert a nbsp after a third space.

If changing the behavior is not an option, maybe (please) include the ability
to turn off spaces converted to nbsp.  With full-blown CSS1 support, nbsp
shouldn't really be necessary, right? ;)
Assignee: ducarroz → buster
Reassign to Editor team...
Assignee: buster → jfrancis
Target Milestone: M20
the goal of the first incarnation of the editor is to be as
"word-processor-like" as possible for mail note composition.  That means, forget
about html, give the user the visual effect they expect from any standard word
processor:  MS Word, WordPerfect, etc.  This is to facilitate mail note
composition, within which users don't care what the HTML looks like, but what
the end result looks like.  Due to compatibility requirements with older mail
programs, CSS is not an option.

Having said that, the rules for determining this kind of thing are enbodied in a
single replaceable object.  So when we get to doing HTML page composition
("composer"), we can easily change the decisions we made for mail note
composition.

Your request still seems odd to me, but time permitting we could make it a
preference.  It's the "end of sentence" only requirement that seems really odd,
it's hard for the code to know what the end of sentence is in the midst of
insertions, deletions, paste, etc.  But we easily could have a pref that says
"no nbsp ever."
QA Contact: lchiang → sujay
change QA contact to sujay.
Target Milestone: M20 → M11
accepting/m11
Target Milestone: M11 → M20
oops; meant m20
Been a while, I know.

A preference that said 'no nbsp' would be a viable soution.  (personally, I'd 
prefer if it applied to both composer and messenger.)

The reason I suggested only at the end of a sentence, is because that's how 
they teach touch typing.  The end of each sentence requires two spaces, so it's 
a habbit I've developed.  Since it's reasonable to want to be able to insert 
nbsp's I didn't necessarilly want to take away that ability.

That said, if someone can point me to the right place in the code to add the 
preference (doesn't need to be in any of the panels) and to add the 
functionality, I'd be glad to do it.

Thanks.
Note that some editors (such as FrameMaker) have a "smart spaces" option, which
will cause it to not insert a second space if the previous character typed was
also a space.
I agree with the original report. Multiple consecutive spaces do not belong in 
HTML, and neither Composer nor Message Composition should try to pretend that 
they do.

Allowing multiple consecutive spaces only encourages the user to do unproductive 
and unattractive things. Like trying to use spaces to align columns of text 
(rather than using a table), oblivious to the fact that readers of the message 
will be using different fonts so that the space alignment won't work. Or using 
spaces to indent paragraphs, when this can be done more consistently (and more 
quickly) with paragraph formatting.

Such problems are legion amongst WYSIWYG word processor users, and it would be 
nice to think that with the advent of HTML we could avoid encouraging people to 
make exactly the same mistakes.

However. No matter which decision you make on keeping the " " trick or not, 
do not ever, EVER, make it a preference. Adding a preference for something as 
obscure as this will not help anyone. Those users who care about this will learn 
not to type multiple consecutive spaces in the first place. And those users who 
don't care will just be confused by the extra preference.

Mozilla is not a heavyweight desktop publishing tool; it should be an order of 
magnitude simpler and more easy to use than that. A preference for something like 
this just does not belong in a program like Mozilla.
Just to confuse matters, spaces are significant in preformatted and plaintext...
Assignee: jfrancis → beppe
Status: ASSIGNED → NEW
moving to future milestone
moving back to previous owner
Assignee: beppe → jfrancis
Target Milestone: M20 → Future
accepting
Status: NEW → ASSIGNED
Component: Composition → Editor
Product: MailNews → Browser
This shouldn't just apply to {message composition, with the exception of plain 

text}. It should apply to {all HTML editing, with the exception of preformatted 

text/plain text/UI text fields}.

mail compose users should not have to even know they are using html.  Hitting 
space multiple times will always indicate a desire by the user to see additional 
whitespace.  Perhaps at a future date we will be able to do this with css without 
screwing up popular mail readers.  But for now, the nbsp solution is the best.

Having multiple spaces typed _not_ give you additional whitespace is just not an 
option for our target audience.

> Hitting space multiple times will always indicate a desire by the user to see
> additional whitespace.

Hitting space multiple times will always indicate that the user is doing 
something which (a) will not be seen as desired by a recipient who is using a 
different font, (b) could be done more quickly and reliably using a different 
method (such as paragraph formatting), or (c) both of the above.

Users composing in HTML *should* experience different behavior than in a word 
processor, because otherwise Mozilla will be misleading them into thinking that 
inserting multiple spaces is a reliable way of achieving alignment effects in 
their message. That may be partially true in word processors (where most viewers 
of the same document have the same hardware/OS/fonts), but it is very rarely true 
on the Internet.
Perhaps I'm missing something, but I do not see a proposal here for any 
improvement.  If you can tell me a better way to deal with this issue in a way 
that is compatible with older mail clients, do tell!

In the meantime, having users possibly be disappointed about the results of 
aligning content with spaces is much better than having their recipients see no 
additional whitespace at all.
> I do not see a proposal here for any improvement.

The proposal is to silently ignore consecutive spaces when editing formatted 
text. This would lead to an improvement in the comprehension of formatted content 
(whether on the Web or in e-mail), because it would help prevent mistakes on the 
author's part, and therefore help prevent problems in document presentation for 
the readers.

> If you can tell me a better way to deal with this issue in a way that is
> compatible with older mail clients, do tell!

There are no compatibility issues here. I'm not suggesting you should stop
*reading* ` 's, just that you should stop *writing* them (when in
un-preformatted mode).

> In the meantime, having users possibly be disappointed about the results of
> aligning content with spaces is much better than having their recipients see no
> additional whitespace at all.

I can't believe that authors, when they discover that they can't insert 
consecutive spaces, will just give up and not use any whitespace at all. They'll 
find the toolbar button to insert a table, or the toolbar menu to change the 
paragraph formatting, or whatever it is they need to use to get the formatting 
they want in a proper (read: compatible) manner.
As the person who opened the bug, let me clarify why I wanted this.

Somtimes I use Netscape Composer to quickly write an HTML file.  I'm a touch 
typlist, and therefore in the habbit of typing two spaces after a period, as 
you're supposed to on a typewriter.  For whatever reason, I want to drop down 
and hand edit the HTML and every sentence I've typed is like this "This is a 
sentence.  ".  This is definitely not what I intended and has some ugly 
display repercussions.  So I search and replace the nbsp... which is easy 
unless there were some nbsp's that I wanted.  

I don't care what happens in HTML e-mail messages.  I send message in plain 
text, I encoure most people to do so.  I can't even look at the source of an 
HTML message, much less edit it (but that's another RFE).  Yeah, it may look 
wrong to the really pick, but I don't care.  (I do understand it's technically 
related... but all the arguments against have come from the quick formatting of 
throw away e-mail.)

My suggested solution(s):

a) Begin inserting nbsp on the *third* space.  Seems like a reasonable 
compromise.
  or
b) Insert only space, do no checking to decide whether there should be a nbsp.
  or 
c) A pref for one or both of the above.  This doesn't even have to be exposed 
in the GUI, as far as I'm concerned.

Lastly, I'm glad to write code, I just need a little pointer to where in the 
code these changes would be made.  I've gotten the source, can build it, so and 
so on.

Thanks.
Matthew Thomas:
>I can't believe that authors, when they discover that they can't insert 
>consecutive spaces, will just give up and not use any whitespace at all. They'll 
>find the toolbar button to insert a table, or the toolbar menu to change the 
>paragraph formatting, or whatever it is they need to use to get the formatting 
>they want in a proper (read: compatible) manner.

When people dont get multiple spaces in mail compose when they type multiple 
spaces, we will get a gizillion bug reports.  If we do give them spaces and 
handful of html-savvy users see how we do it, we will get a very small number of 
folks who debate the wisdom, while successfully using Messenger nonetheless.  It 
seems pretty clear to me which course of action better suits the goals of 
Messenger.

Otto:
>My suggested solution(s):
>a) Begin inserting nbsp on the *third* space.  Seems like a reasonable 
>compromise.

This kind of solution will only confuse people further.  Why do they get a space 
when they type once, then not a second until they type their third?  

None of these proposals will make any sense to mail users.  HTML mail has been 
around for a while, and rich text word processors for longer than that.  As far 
as I know, they all obey this rule: If you type a space, you get an extra unit of 
visual whitespace.  No proposal that violates that rule is going to be taken 
seriously by our Messenger users.  

This isn't a standards issue.  It's a usability issue.  
> None of these proposals will make any sense to mail users.  HTML mail has 
> been around for a while, and rich text word processors for longer than that.  
> As far as I know, they all obey this rule: If you type a space, you get an 
> extra unit of visual whitespace.  No proposal that violates that rule is 
> going to be taken seriously by our Messenger users.  
> 
> This isn't a standards issue.  It's a usability issue.  

Let me make even clearer, this is not a Messenger issue, it is an issue of the 
quality of the HTML *Composer* generates.  I agree with you on the Messenger 
issue, but that is not what this bug is about.
fwiw WordPerfect and I think MS Word do have strange features like this. 
WordPerfect 7's quickcorrect set w/ 2spaces->1space:
This is a test.<space>This is a test.<space><space>This is a 
test.<space><space><space>
becomes
This is a test.<space>This is a test.<space>This is a 
test.<space><space><space>

I'm not sure if 8 or 9 have a different rule, but maybe we should survey the 
word processor's approach to this problem.
I would be very dismayed if I typed a second space in an editor and it didn't
cause anything to go into the document.

I'm also a touch-typist who habitually types two spaces at the end of a
sentence.  I (see, just did it :-) am also aware that this is somewhat
deprecated and that if I get extra nbsp's in my document, it's my own fault
since I typed them.  I wouldn't mind if there was a pref to collapse whitespace,
but I probably wouldn't turn it on; if the nbsp's really bothered me I guess I'd
try to train myself not to type the extra space (though that would take a
while).
Akkana:
> I would be very dismayed if I typed a second space in an editor and it didn't
> cause anything to go into the document.

Don't get me started on how much whitespace really ought to display at the end 
of a sentence. :) Suffice it to say TeX gets it right, despite the number of 
spaces you actually type.

Matthew Thomas:
> Word 98's approach to the problem

I sort of agree with Word's solution.  It warns you and lets you do it.  
However, I'm not trying to control the layout when I type two spaces at the end 
of the sentence.  I don't think Word gets the display right in that case, 
either.

Incidentally, this also has some weird ramifications when it comes to word 
wrapping.  When the text happens to wrap at the end of a sentence, you get 
something like this:

Long sentence that happens to wrap at the end of the sentence.
 New sentence on the new line.

added helpwanted
Keywords: helpwanted
I'm willing to write the code for this, if someone can point me to where it 
needs to be written.  Best option is to merely make it a preference that can be 
set by hand in the .js files, I think.  It won't confuse the GUI and most 
everyone who doesn't want it won't know it's there.
A comment from a first-time casual user of Mozilla (just migrated to 0.9.2 from
Netscape 4.77) on the `two spaces after period' problem.  The &nbsp; action is
not so concerning to me as the fact that, in Message Composition, a line can be
broken in the middle of the two spaces, so that you get a leading space on the
next line.  Definitely not what us touch-typists expect to see.  I think Otto
has already pointed this out in his additional comments dated 2000-06-18.
I think there's a bug already on the fact that plaintext lines can be broken
such that there's a leading space on the next line.  (I don't think you need two
consecutive spaces to trigger that, either.)  If there isn't one already, there
should be.
!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: