Open Bug 181438 Opened 22 years ago Updated 14 years ago

text zoom should not skip percent that makes page text match default font size

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
UNCONFIRMED

People

(Reporter: mrmazda, Assigned: samir_bugzilla)

References

(
URL
)

Details

Using both 1.1 (20020826) for Mandrake Linux 9.0 and 2002112112 OS/2 trunk.
Neither system has Verdana installed. Both have Helvetica installed. Systems are
both set to default font size 16 px.

Subject URL css is set to display body text at .8 em using font-family: Verdana,
Helvetica, Arial, sans-serif;. Ctrl++ sets body text to the neighborhood of
.90-.93 em. Ctrl++ a second time skips over 1.0 em to the neighborhood of
1.10-1.15 em. Thus, there is no simple way to get the page's body text to the
user's choice of font size. Whatever the algorythm for determining the
smaller/larger increment, 1.0 em should not be skipped over. I've seen many
other pages exhibiting this behavior, (e.g. http://www.microsoft.com/) but I
think the subject matter of this URL serves as an ironic emphasis of the need
for this.

I read bug 31961 with great interest. That should very useful if it ever comes
to pass, but I don't think it would obviate the need for this. I also read all
the way through bug 37940, and think it should be reopened or another bug filed
to make the fixed percentages reflect common situations better. e.g., on the
subject URL, 120% results in approximately .90-.93 em, while 150% results in
approximately 1.10-1.15 em, both just like using the keyboard shortcuts.
So the request is that Ctrl-+ and Ctrl-- change the text size such that the
"main body text" does not shoot through the user's default font size.

Now how do we decide which text on the page is the "main body text" exactly?
BZ: We don't need to know "main body text" size. We only need to query the value
of 1em in prefs, and not pass that size without first stopping on that size. One
reason for the enhancement request is the coarseness of the increment. A whole
bunch of common font faces jump to bold at the first common stop beyond 1em,
somewhere around 1.1em-1.15em. I keep hitting pages where the whole .92em-1.08em
range is skipped over, and getting the size at least to 1em bolds everything.
> and not pass that size without first stopping on that size

Not pass that size for _what_ exactly?

<body style="font-size: 10px">
 This is text
 <p style="font-size: 12px">More text</p>
 <p style="font-size: 8px">More text</p>
</body>

What is your expected behavior on that page?
That example is easy. The median size is 10px. If 10px is smaller than 1em, then
apply the plateau to the median size on increment. If 10px is larger than 1em,
then apply the plateau to the median size on decrement.
My point is that calculating the "median size" is _hard_.  And very expensive. 
And likely to fail, imo (eg on many pages the median size will end up the size
of the link bars on the sides, not the size of what people care to read).

The point is, suggest an actual useful way to do this.  ;)
I don't know how to make it easy or inexpensive, but maybe I have an alternative
that would produce the same effect:

How about changing the hotkey increment/decrement from whatever it is now, to
one pixel, and adding two more increments in the view->zoom menu in between 100%
and the two changes adjacent? Fonts sizes now are converted to integer pixel
values for rendering, aren't they?

100% -> 120% is just too coarse to be able to land on 1em, especially if the two
following increments land on 150% and 200%. But, by changing the increment to a
pixel, surely it could.
Summary: smaller/larger Ctrl++/Ctrl+- should not skip over default size (1.0 em) - text zoom → text zoom should not skip zoom percent that makes page text match user's chosen default size
Summary: text zoom should not skip zoom percent that makes page text match user's chosen default size → text zoom should not skip percent that makes page text match default font size
*** Bug 208825 has been marked as a duplicate of this bug. ***
Mozilla > Preference > Advanced > Mouse Wheel > Make the text larger or smaller

I find that using the mouse wheel provides a finer text-size increment than 
Ctrl+ and Ctrl-.  Using the wheel is a significant improvment.

Only problem is that when the wheel is selected for this function, it can't be 
used to scroll anywhere in Mozilla.  Obviously, that includes scrolling through 
webpages and emails.  

Also, with a few hundred folders in my email accounts to scroll through, it's a 
problem having the wheel disabled for scrolling through all those folders.

Thanks,
       -Neil-
Product: Core → Mozilla Application Suite
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
No improvement since bug opened.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
You need to log in before you can comment on or make changes to this bug.