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)
Core
DOM: Editor
Tracking
()
VERIFIED
WONTFIX
Future
People
(Reporter: otto, Assigned: mozeditor)
References
()
Details
(Keywords: helpwanted)
Attachments
(1 file)
22.16 KB,
image/png
|
Details |
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? ;)
Updated•25 years ago
|
Assignee: ducarroz → buster
Comment 1•25 years ago
|
||
Reassign to Editor team...
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."
Assignee | ||
Updated•25 years ago
|
Target Milestone: M20 → M11
Assignee | ||
Comment 4•25 years ago
|
||
accepting/m11
Assignee | ||
Updated•25 years ago
|
Target Milestone: M11 → M20
Assignee | ||
Comment 5•25 years ago
|
||
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.
Comment 7•25 years ago
|
||
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.
Comment 8•24 years ago
|
||
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.
Comment 9•24 years ago
|
||
Just to confuse matters, spaces are significant in preformatted and plaintext...
Updated•24 years ago
|
Assignee: jfrancis → beppe
Status: ASSIGNED → NEW
Comment 10•24 years ago
|
||
moving to future milestone
Comment 11•24 years ago
|
||
moving back to previous owner
Assignee: beppe → jfrancis
Target Milestone: M20 → Future
Updated•24 years ago
|
Component: Composition → Editor
Product: MailNews → Browser
Comment 13•24 years ago
|
||
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}.
Assignee | ||
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
> 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.
Assignee | ||
Comment 16•24 years ago
|
||
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.
Comment 17•24 years ago
|
||
> 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.
Reporter | ||
Comment 18•24 years ago
|
||
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.
Assignee | ||
Comment 19•24 years ago
|
||
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.
Reporter | ||
Comment 20•24 years ago
|
||
> 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.
Comment 21•24 years ago
|
||
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.
Comment 22•24 years ago
|
||
Comment 23•24 years ago
|
||
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).
Reporter | ||
Comment 24•24 years ago
|
||
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.
Reporter | ||
Comment 26•24 years ago
|
||
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.
Comment 27•23 years ago
|
||
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 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.
Comment 28•23 years ago
|
||
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.
Assignee | ||
Comment 29•23 years ago
|
||
!
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•