Closed Bug 44952 Opened 24 years ago Closed 23 years ago

HTML Message/Compose Accelerators: Format menu should match spec

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: nbaca, Assigned: jglick)

References

Details

(Keywords: helpwanted)

Overview: In the HTML Message window the accelerators for the Format menu should 
match the spec.
Keywords: nsbeta3, ui
QA Contact: lchiang → nbaca
Target Milestone: --- → M18
OS: Windows NT → All
spec says Background Color, currently we have Page Background Color (we're 
composing a message, not a page); Netscape 4 didn't include this menu item, and 
you will be able to get it from Page Colors and _Background_; Unless netscape 
has done some research and decided consumers want this menu item, I think it 
can be removed.
I'll look into moving Table above font sizing.
.
Assignee: putterman → timeless
Mass accepting.
Status: NEW → ASSIGNED
cc'ing ducarroz.  Are we pulling this in from the Editor?
Yes, the format menu is managed by the editor. cc'ing cmanske
Removing the nsbeta3 nomination.  These will be condensed into a smaller number 
of bugs and then renominated.  
Keywords: nsbeta3
Target Milestone: M18 → mozilla0.9
So what accelerators don't match the spec? They are the same for both "Page"
and "Message" Composers, as they should be.
As for the "Page Colors and Background" issue, that is the wording we found best
given user feedback. I see the point about "Page" vs. "Message", but I'm not
sure if it's worth making a special case for that.
4.7 does have this item in Message Composer -- it is labeled: "Page Colors
and Properties".
It allows user to set color and image for a message. I know this is not always
a good thing to do (especially given bad interactions with other mail readers),
but that is a separate issue.
Build 2001-011004: NT4
I can say that the accelerators for the Format menu in the HTML New Message
Compose window match the Composer Format menu.

I cannot say that they match the spec because the menu items are different. I
found the spec at http://mozilla.org/mailnews/specs/compose/Comp_Menus.html.
jglick, does this spec need updating?
Menu items and accelerators are correct, IMHO. The spec needs to be updated.
Note: The menu text for the second group of items changes dynamically:
When there is a selection, they read:
Remove Te_xt Styles
Remove Li_nks

When the selection is "collapsed" (you have a caret in text), they read:
Discontinue Te_xt Styles
Discontinue Li_nK

I use "_" before the letter that should be the "accelerator" letter.
Sorry for the delay. Spec updated to reflect Charlie's comments. Remove Te_xt 
Styles. Remove Li_nks.
Blocks: 70185
Target Milestone: mozilla0.9 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3
jglick: my original comment (2000-07-13 22:35) is still unaddressed.
Assignee: timeless → jglick
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.3 → mozilla0.9.4
timeless, i'm sorry, what exactly is the issue?
I think "Page Colors and Background" just fine for message composer.
If you really want to get fussy, you could change to "Message Colors and 
Background" in message composer.
Spec is here: http://www.mozilla.org/mailnews/specs/compose/Comp_Menus.html

Spec                          Mozilla                          Comment
-------------------------------------------------------------------------------
RemoveTextStyles-Ctrl+Shift+K RemoveAllTextStyles-Ctrl+Shift+T   Words, shortcut
Remove Link(s)- Ctrl+Shift+L  Remove Links - Ctrl+Shift+K     Different shortcut
Align over increase indent    Align under increase indent                  Order
Properties ALT+Enter          Properties                        Shortcut missing
Font->Fixed Width             Font->Fixed Width - Ctrl+T    Shortcut not in spec
Size->Smaller - Ctrl+-        Size->Smaller - Ctrl+-          Different shortcut
Size->Larger  - Ctrl++        Size->Smaller - Ctrl+=          Different shortcut
---                          Table->create Table from Selection  Missing in spec

Is this really a good spec? Increase/decrease Indent, Shortcuts Ctrl+[/] not
accessible on international keyboards (german, danish), bug 88380

Checked on 2001072503 (trunk), Win2K

spec                          current
RemoveTextStyles-Ctrl+Shift+K RemoveAllTextStyles-Ctrl+Shift+T
imo shorter is better, 

I think you need a break: (i know i do)
Size->Smaller - Ctrl+-      Size->Smaller - Ctrl+-        *same?*
Size->Larger  - Ctrl++      Size->*Larger?* - Ctrl+=      Different shortcut

ctrl+= is a xptoolkit bug, don't worry about it. properties is something i can 
fix after we resolve the rest of the issues.
Target Milestone: mozilla0.9.4 → mozilla0.9.5
QA Contact: nbaca → olgam
I have updated the spec to reflect these items. Product now matches spec except 
for the following items in which I think the product, not the spec should 
be changed:

Product
Format: Discontinue Text Styles --- Ctrl+Shift+T
        Discontinue Links --- Ctrl+Shift+K
Format: Text Style: Fixed Width --- Ctrl+T

Spec
Format: Discontinue Text Styles --- Ctrl+Shift+K
        Discontinue Links --- Ctrl+Shift+L
Format: Text Style: Fixed Width --- (None)


Ctrl+Shift+T is already used in 3 Pane Mail for "Get All New Messages". 
Ctrl+T is used in 3 Pane Mail for "Get New Messages". I understand sometimes we 
have to use the same accelerators for different purposes in different 
components, but it should be avoided if possible. Especially in this case, since 
Mail Compose is not a separate component from 3 Pane Mail, but a window which is 
part of the Mail component. In addition, getting new mail is something that 
should work consistently, even when composing a mail message.

Ctrl+L is Insert Link, so it make sense to have Ctrl+Shift+L be Remove Links. If 
that is implemented, Ctrl+Shift+K is available for "Discontinue Text Styles". 
"Format: Text Style: Fixed Width" does not need its own accelerator. 
I thought we already had this discussion?
1. I still think trying to keep all Mail Pane accelerators the same in the Mail
Compose window is too restrictive. I see nothing wrong with having a different
action for the more obscure key cominations, such as Ctrl+Shift+T.
2. I believe accelerators need to have some mnemonic connection with the action 
What does "T" have to do with getting new mail? Obviously it *is* a better 
mnemonic for "Discontinue *T*ext Styles". Ctrl+Shift+K doesn't have a good 
mnemonic connection for that.
Note that we do use Ctrl+Shift+K in 4.7, so if we want to consider compatability 
with that, there may be an argument for it. Note that in 4.7, Ctrl+Shift+K 
discontinued BOTH text and link styles, so we've changed the actions, reducing
similarity with older version. Given that, we'd prefer new key bindings for the
new, separate actions of removing links and text styles.
both text styles and links
Composer can't use Control-Shift-L so it's not a good choice for Discontinue 
Links.

We should not change the keybinding for Discontinue Links... it should remain 
Control-Shift-K since we have shipped several versions with that keybinding and 
it's somewhat consistent with 4.x.

If mail compose would prefer not to have keybindings for Fixed Width (Control-T 
in Composer), that is fine but Composer should continue to have that keybinding.

Perhaps mail compose shouldn't have a keybinding for discontinue text styles 
either (even though Composer will continue to have it)?
>I thought we already had this discussion?
Yes, we had this discussion in a different bug (i don't recall the #), and it 
was never resolved in that bug either. :-)

>1. I still think trying to keep all Mail Pane accelerators the same in the Mail
>Compose window is too restrictive.
I agree. It would be impossible most likely given the shortage of key 
combinations available. I'm only asking that something as important and 
frequently used as retrieving new messages, be consist across Mail windows.

>2. I believe accelerators need to have some mnemonic connection with the action 
>What does "T" have to do with getting new mail? 
Again, I agree, but in reality this can't always happen because of the shortage 
of key combinations available. Every other key combination was already taken so 
4.x choose "Ctrl+T" for "Get Msgs". 
Kathy's right, I forgot that Browser and Composer both use Ctrl+Shift+L to bring
up the "Open Location".
I also contend that "Ctrl+T" is very important for Composer users. It was 
definitely missed in earlier 6.x releases.
We will look into how to let Mail Composer not use keybindings, or have
different keys, that Web Composer needs to retain.
So we do need to keep Ctrl+shift+K for "Dicontinue Links" (that should also be
used in Mail). We would like to use:
Ctrl+shift+T for Web Composer (Mail can not use this if they want)
Ctrl+shift+L for "Open Location" (I guess now it's "Open Address"!!!)
Ctrl+T for Format > Text Styles > Fixed Width
OK, I see "Ctrl+Shift+L" is already being used for "Open Location" in Composer. 
Sorry I missed that one.

How about we compromise? ;-)

Keep as implemented:
Format: Discontinue Text Styles --- Ctrl+Shift+T
        Discontinue Links --- Ctrl+Shift+K

But removed:
Format-->Text Style-->Fixed Width --- Ctrl+T
(At least for Mail Compose)

That sound ok?
That sounds ok with me. I tried this morning to remove the "key" and "accelltext"
attributes on the "Fixed width" menuitem when in mail composer (did that in the 
method that is called when the text styles submenu appears). It killed the 
keybinding, but didn't remove the "Ctrl+T" on the menu!
So we might have to use an overlay mechanism to make that work.

Status: NEW → ASSIGNED
Seems like i'm the only one who feels this way. If no one else see this as a 
problem, i'm willing to let this go.
Jennifer: You mean we can keep "Ctrl+T" for "Fixed width" in Mail Composer?
Yes, if no one else thinks this is a potential area of confusion, i'm willing to 
cave to the consensus. ;-)
Spec being updated. Marking fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Fix is verified on updated Spec.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.