Closed Bug 99406 Opened 23 years ago Closed 23 years ago

Format toolbar buttons not changing text size after using format menu

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 46290
Milestone:
mozilla0.9.6

People

(Reporter: TucsonTester2, Assigned: mozeditor)

References

Details

(Whiteboard: EDITORBASE; 3 days) 

windows95
build:2001091003


Description:After changing text size using the format menu the format toolbar 
selection will not increase or decrease text size.

Reproducibility:Everytime

Steps to reproduce:
1.Open blank composer page and type some text. (e.g.Format)
2.Highlight the text and choose format>size and select large
3.With the text still highlighted click on larger font size button on the 
format toolbar. 

Actual results:The big and small tags are added but the text doesn't resize in 
the composer window.

Expected results:I expected the text size to increase.

It would seem logical that with the text highlighted you would be able to 
increase or decrease text size from the format toolbar and composer should 
recognize the font tag.
After talking with jfrancis, it seems that things are working correctly, and
this isn't really a bug.

The problem seems to be that users are confused by the fact that the
Format->Size->x-small to xx-large menu items generate <font size=> tags which
basically tells the layout engine to use a specific size of the base font ...
whereas the +/- buttons on the toolbar use <big> and <small> tags which tell the
layout engine to use larger/smaller sizes of the current font.

In this particular case, we are generating the following output like the following:

    <big><big><font size="+1">My Words</font></big></big>

Notice that because the user chose Format->Size->large before pressing the +/-
buttons, so the <font size=> tag ended up being inside the <big> tags later
generated by pressing the buttons on the toolbar.

Because the font tag is closest to the actual content in terms of parent
hierarchy, it takes precidence over the <big> tags.

So what should I do with this bug? Mark it INVALID? Or does the composer team
want to discuss a way of making this less confusing?
brade? cmanske? What should I do with this bug? Mark it INVALID?
I guess it should be invalid. Kathy?
Joe: any plans to abandon the <big> / <small> tag. I know we've run into the 
confusion it can cause.
I think we should abandon big/small if we can't work well with font sizes.  I 
think we should fix this in the Composer application.  Maybe remove them from the 
toolbar?  I'm not sure but I don't think we should resolve this bug as invalid.

Reassign to Syd while we think about this issue.
Assignee: kin → syd
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 95 → All
I have no plans to abandon big/small.  I would like for us to abandon font size 
instead.  Why should we have html'isms in our mail interface?  Mail users 
shouldn't even know we are using html, right?   What the heck is x-large?

I can't make big/small and font size live together happily.  Going with just font 
size is very difficult. Going with big small is not too bad and works pretty well 
already.

This sounds like a typical case where mail and web Composers diverge.
Big and small seem simpler and more appropriate for Mail, while Web Composer 
users would probably prefer CSS-based font size.
How does Daniel's replacement of CSS "font-size" affect this issue? It seems that
it wouldn't help, i.e., CSS size would have precedence over big just as HTML
font size does.
since they aren't going to do anything, perhaps we should disable the big/small 
icons in the case where the font size has been set?

It's hard to identify that case.  If font size is "inside" big/small, font size 
wins.  So if you have:

<html>
<body>
Here is some small<font size=1>text</font>
</body>
</html>

and you select "small text" and click on the big button, "small" will get bigger 
but "text" will remain the same.

I guess I could do something kinda odd and do this in response to the above 
scenario:

<html>
<body>
Here is some <big>small<font size=1><big>text</big></font></big>
</body>
</html>

That would actually work.  (just tested it by making the change in source view 
and observing the result - you get what you want).

IM prefers HTML font tags in place of big, small for what it is worth. 

This seems like enough of a usability issue, nominating nsbeta1, "---" to get it
on my radar.
Keywords: nsbeta1
Blocks: 104166
I have a fix for the original bug here which I will attach as a patch shortly.
Assignee: syd → jfrancis
Status: NEW → ASSIGNED
Whiteboard: EDITORBASE; 3 days
Target Milestone: --- → mozilla0.9.6
strike that - i'll attach it to 46290, which this is a dup of.


*** This bug has been marked as a duplicate of 46290 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.