Closed Bug 113013 Opened 23 years ago Closed 21 years ago

Default font size pref should affect "absolute" font sizes

Categories

(Core :: Layout: Text and Fonts, defect)

Product:
Core
Component:
Layout: Text and Fonts
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED INVALID

People

(Reporter: jesup, Assigned: lorikaplan)

References

(Blocks 1 open bug)

Details

(Keywords: access, fonts, intl, Whiteboard: WONTFIX? DUPLICATE? (py8ieh: see comment 18 points 5 and 6)) 

There are significant problems with the current font size preferences.  (was
discussing this with akk, Heisi, timeless and biesi and a few others on IRC.)

You can adjust the font size in prefs.  However, it doesn't affect font sizes
specified in px units (and perhaps some others).  This can lead to lots of pages
with Really Tiny Fonts that you can't read on a 100dpi (or higher) display.  It
confuses users because they think they increased the font size, and it seemed to
work in most places.

There is a Text Zoom menu item, but it isn't saved.  (And there are bugs with
em-sized non-font-elements.)  Also, unlike 'normal' font sizing, it's done in %.

There's a pref with no UI for a minimum (point?) size for fonts.  There should
be two prefs (for variable and fixed fonts), and it needs a UI.  Note that this
doesn't take the place of the other two mechanisms since it loses all font size
information at or below the value you set for it.

These issues affect accessibility (for the visually-impaired) and readability on
high-DPI displays.


Proposal: the basic mechanism should not be the tables in nsStyleUtil.c.  THe
basic mechanism presented to users should work via textZoom.  If the user picks
a larger font, pages in px should be enlarged too.  Yes, this _is_ a spec
violation, so perhaps there should be a checkbox or Advanced button, but note
that the POLC (principle of least confusion) dictates that users who want larger
fonts be given larger fonts in all cases. 

Note that this implies that there may be separate zooms for proportional and
fixed fonts, which would be tricky.  Perhaps we should instead expose the
textZoom factor instead of letting the user specify font size in points.

We have 3 mechanisms; one of which has a UI and is saved, one is saved, and one
has a UI but isn't saved.  They use different units, and their relationship is
confusing to users.  We need one unified pref page (or page plus advanced, etc).
 We need at least a moderately intuitive way to adjust font sizes that works for
pages that use px (like CNN, espn, etc).
I guess this is why IE only has Smaller, Small, Medium, Large, and Larger for
font size choices, as it completely avoids the problems with specifying exact
sizes.  However, I find IE's implementation very annyoing, as every choice
always seems a bit too small or too big.  So I suppose my 2 cents' worth is to
make sure any new implementation doesn't end up like IE's.
Well, I worry making pixels not mean pixels based on a change in font prefs will
just continue to encourage authors to put text in images.  Authors should almost
never specify fonts in pixels (but of course they do).

Beyond that, how would you decide when a pixel shouldn't be a pixel?  What if I
want a pixel to be a pixel, but I want my default font to be 12px?  What if I
want a pixel to be 1.5 pixels, but I want my default font to be 24px?

I'd propose the following:
 * we keep the meaning of the font-size pref the same (but perhaps also expose
it in a menu, although the Zoom should be more prominent)
 * we scrap the current "text zoom" and replace it with a real zoom that zooms
everything -- i.e., by changing the p2t value on the device context that is used
for conversion to the display, but not when converting to nscoords.  Such a zoom
would scale text, images, everything sized in ems or %ages, etc., but would
still allow the page to fit horizontally within the viewport unless it is badly
designed.
Cc:ing other folks and putting on the intl radar.
My preference would be to patch the existing stuff (bug 61883) before
contemplating a crusade that involves change that are unlikely to happen in the
short term.
Keywords: fonts, intl
I agree with the objections raised by dbaron but I don't think that a low-level 
pixel zoom would be the solution because people usually want to enlarge the text, 
not the images.  Nobody reports bugs saying "The images are displayed too small 
in my browser" (or if they do, they should use a lower resolution on the 
monitor).  See bug 4821 for more details on the full zoom feature.

A solution could be to implement the "min font size" pref, but then we have to 
make sure it applies to the line-height too.  We have a similar problem with text 
zoom (bug 95267).

I don't think that's true.  There are many web pages that use images to display
text.  For example, http://www.excite.com/ or http://www.apple.com/ .  Some
users might want to enlarge the images in order to read the text in them. 
That's what the Zoom feature is for.
While I agree with dbaron that text in images is an issue (and is for me), I
consider that a separate issue which is handled under bug 4821.

Quite honestly, all pixel measurements should be deprecated IMHO.  They're only
of any real use if you assume a more-or-less standardized DPI, viewing distance,
and display size (and assume the user has normal visual acuity).  They should
never have made it into the spec.

The minimum font size pref has it's uses, but that's really just a backstop; you
lose considerable amounts of contextual information once that minimum becomes
equal to or larger than the "normal" font size.  The same logic that scales all
<font size=N> sizes according to the user's font pref should apply.  If you set
your "font size" in prefs to 30 points (you have bad eyesight), that makes your
size 1 font size around 18 points or so (and people have been arguing that the
font sizes should be even more tightly clustered around the selected size).

<font size=N> is deprecated, but users can only affect fonts specified with that
deprecated (but still extremely common) construct.  This is a problem.  The
textZoom stuff does solve the problem, more-or-less, but in a much less precise
manner, and it has bugs, plus it can't be saved.  Minimum font size sort-of
solves part of the issue, but at the expense of losing formatting information
and compressing everything to a single font size (except perhaps ultra large
headlines).

And, as stated to start with, font sizes are in three places with three
different ways to change them: a prefs panel, a menu item that isn't saved, and
the third only accessible by editing user.js.
Pixel measurements are strongly discoraged by CSS gurus -- but physical units on
screen media are even worse still, since OSes very rarely have proper settings.
 The main solution here is evangelism of page authors -- I don't think there's
any UI that we're going to come up with that the majority of users will
understand how to use.

There are legitimate uses for pixel-size text (when used along with images), and
we shouldn't change the meaning of a pixel for text without changing it for
images as well.
-> ftang
Assignee: sgehani → ftang
Exposing the minimum font size pref we already have would go a long way toward
helping the people and platforms most affected by this problem.  Granted, it
loses some contextual information; but in practice that seldom seems to be a
problem, and in any case the alternative is to set the "use my fonts" pref and
have mozilla ignore all document specified fonts, which loses a lot more
contextual info than a minimum font size does.

Not to say that the rest of rjesup's suggestion (scale all absolute-specified
fonts along with the main font) is a bad idea.  I think it's a good idea, and
I'd use it, but we'd still need minimum font size (and it should be exposed),
for all the Windows-based page authors who see IE's scaled-up default fonts and
so use <font size=-1> over their whole page to make the fonts look normal sized,
making the page unreadable on Mac and Linux.
Perhaps a checkbox for "Adjust all font sizes" or "Adjust absolute font sizes as
well" (any wording you like).  Perhaps in an "advanced" box along with the
override checkboxes (or as another in the set).

The real problem here is that there's a conflict between the (rather annoying)
spec, and what people expectations and wishes are.  Most people who adjust their
font size in prefs really will expect that to apply to all fonts.

HTML (and CSS) are NOT page-layout languages, for all that people keep trying to
make them into page-layout langs.  Pixels are a particularly bad mechanism for
specifying font sizes, since god knows how much space a "15px" font is actually
going to take up given all the variances of OS, font family, font foundry,
display device, DPI, scaled vs bitmap, etc, etc.

If page authors would avoid px sizes, that would be a different story - but they
don't, and we don't have the clout to make them.  Witness cnn.com.  I want to
provide the users with a way to make pages reasonably usable, whether they're on
a high-DPI X display with bad "small" fonts, or have visual acuity problems, or
just feel less eyestrain reading larger fonts.  To me, that's more important
than strictly following the spec even when the user requests otherwise.

IMHO

>Perhaps a checkbox for "Adjust all font sizes" or "Adjust absolute font sizes
>as well" (any wording you like).  Perhaps in an "advanced" box along with the
>override checkboxes (or as another in the set).

For the record, CSS has a powerful concept that goes into achieving what you
mentioned in a spec-compliant manner. It is called |font-size-adjust| with
values: none | number | inherit. The property scales the so-called "actual"
font-size by a factor depending of the x-height of a font against the x-height
of a base font (see bug 74186). There are also prefs for that, but they only
work in GfxWin and there is no plan to expose them. The back-end support for
that (which I added as part of my landing in bug 99010) proved to be much
involved and so it is unlikely to happen in other platforms in the short term.
Hardware: PC → All
Pardon my ignorance, but what is "p2t" and how does it relate to font scaling
and/or page zoom?
pixels to twips - conversion between internal sub-pixel calculations and pixels.
Status: NEW → ASSIGNED
Despite my min font size prefs, this site still has tiny text :

http://jimmac.musichall.cz/themes.php3?skin=2

Is this because the style sheet using px ?

(Also I cannot select only part of a line, bug nr. would be
appreciated)
UE issue, over lori
Assignee: ftang → lorikaplan
Status: ASSIGNED → NEW
Component: Preferences → User Interface Design
Keywords: access
I agree with everything David Baron said. Things I specced in bug 28899 which 
aren't implemented yet are:
(1) UI to finish bug 61883 (different sizes for differently legible font
    families)
(2) UI for the minimum font size.
That design is as complex as I dared make it -- I think adding any more 
features would tip it too far into incomprehensibility.
Possible fix:  userContent.css

I've had this same issue with Galeon,  had been told that this was addressable
with CSS, using a default stylesheet, but had found no examples of one that did
what is being requested.

I've since created and used a stylesheet which I've been using for the past four
months or so, with excellent results.

The stylesheet itself (heavily annotated) is available at
http://kmself.home.netcom.com/Download/userContent.css

Examples of pages with and without the stylesheet (note:  users with an existing
stylesheet may have results differing from the default) are at:
http://kmself.home.netcom.com/Download/test.html (without)
http://kmself.home.netcom.com/Download/test-css.html (with)

The stylesheet forces all fonts to the faces and size(s) specified in the users'
browser preferences.  All absolute and relative "size" tags or CSS directives
are ignored.  All "font" face directives are ignored.  Headers are also
specified.  Because a minimum font isn't specified, it's still possible to scale
a page using the zoom control.  Text will increase/decrease appropriately, and
can be greeked.  This is a Good Thing.

The one thing the CSS doesn't render right (IMO) is the virtual directory page
returned when you're browsing a filesystem or a website that returns a
filesystem listing.  If I could get this fixed I'd be in heaven (please reply at
the address above).

I've found precisely one website which breaks in ways that are at times
unreadable with this style sheet.  It's http://www.law.com/.  Certain pages
within the site use absolutely scaled regions which break when text is resized.
 Other than that, this stylesheet gives me the web the way I want it given to
me.  Much happiness.

Shipping a CSS (or providing pointers to one similar to mine) might resolve this
bug.  It might also raise the awareness level of web designers who break things
in the first place.
IMHO:

   1. Font Zoom should be _exactly_ as it is now. A transient zoom for text only
      intended simply as a way to quickly make small text more readable on a
      temporary basis and which may well break the layout of badly written
      pages. (done)

   2. We should implement Page Zoom as a separate feature, and that should work
      exactly like it does in Opera. It should not be transient (although I'm
      not sure if it should affect all pages when multiple windows are open).

   3. Text Size prefs should control the default font size ('medium' in CSS
      terms). There should only be one font size control.

   4. The font selection should let the user pick fonts for each of the generic
      font families, and should let the user pick which generic font family to
      consider the default. (done)

   5. We make the 'font' shorthand not reset 'font-size-adjust' and we set
      'font-size-adjust' on the root element to the aspect ratio of the default
      font-family as given in step 4. This will automatically take care of
      making the font sizes of other font families resize to match the aspect
      ratio of the default font.

   6. We add an option to the font pref panel to control whether or not to do
      what it says in step 5. (i.e., whether or not to set f-s-a to the aspect
      ratio on the :root element or whether to set it to none.) We make the
      default be 'none' (pref unchecked).

   7. We keep the minimum font size pref exactly as now. (done)

This is actually *very* close to what we have now, UI-wise. The only real
changes are the introduction of Page Zoom (a four-digit bug), the removal of the
font size pref for Monospace, and the addition of a pref to reimplement the
behaviour of the latter using font-size-adjust.


w.r.t. the initial comments:

The font size prefs *shouldn't* affect pixel-sized text. If authors size text in
pixels, then by default we must honour the contract we have with the author that
a 10x10 pixel image will be roughly the same as 10px text. (By "by default" here
I mean ignoring any transient controls like font zoom or any accessibility
features like minimum font size.)

The font zoom is exactly correct -- it isn't saved, and it's done in %. That's
what we want. Bugs in font zoom were recently fixed. In any case, bugs in a
feature should never be a consideration for implementing another feature in a
different way -- the effort should just be spent fixing the first set of bugs.

We have a minimum font size pref for getting around pages designed with
ridiculously small fonts. Set it to be whatever you find is the smallest text
you can comfortably read.

We should have page zoom. I agree with that.


> Proposal: the basic mechanism should not be the tables in nsStyleUtil.c.

We need those tables regardless of what we do. Those tables are how we go from
xx-small to xx-large in CSS. (Unless I am thinking of something else.)

Those tables are fine. They have been carefully tweaked and work great.


> The basic mechanism presented to users should work via textZoom. If the user
> picks a larger font, pages in px should be enlarged too.

That's what the minimum font size pref is for.


> Yes, this _is_ a spec violation, so perhaps there should be a checkbox or
> Advanced button, but note that the POLC (principle of least confusion)
> dictates that users who want larger fonts be given larger fonts in all cases.

Evangelisation and education are key here. We have to get page authors to
understand that they should honour user preferences by using only 'em' units,
and we have to get users to understand that page authors have that choice.

How we do that is our of scope of my comments.


> Note that this implies that there may be separate zooms for proportional and
> fixed fonts, which would be tricky.

And horrible. I am against that.


> We have 3 mechanisms; one of which has a UI and is saved, one is saved, and 
> one has a UI but isn't saved.  They use different units, and their 
> relationship is confusing to users.

Which is the second?


> We need one unified pref page (or page plus advanced, etc).

We have one unified pref page. The Font Zoom stuff isn't a pref, and shouldn't
be a pref. It's similar to the Use Stylesheet menu item, it's not a pref, and
should not be in the prefs dialog.


> We need at least a moderately intuitive way to adjust font sizes that works
> for pages that use px (like CNN, espn, etc).

Yep. Minimum Font Size (a pref, works now) and Page Zoom (RFE).


I think this bug is a dupe of bug 4821 (well, bug 112108 really). If there is
support for what I proposed at the top of this comment (points 5 and 6), then
I'll file new bugs.
> There should only be one font size control.
[ ... ]
> the removal of the font size pref for Monospace

That would be a huge loss in usability on linux.  Like it or not, the X
font model just isn't very good, and fonts don't always appear at their
advertised sizes.  Trying to find a size that's right for both the chosen
proportional font and the chosen monospace font is impossible; one of them will
be either too big or too small.  Perhaps on platforms that use only scaleable
fonts, this isn't a problem, but it's a big problem on Unix. 

> The font size prefs *shouldn't* affect pixel-sized text.

I understand Hixie's arguments for this, but won't it be confusing for users
(who don't and shouldn't have to know how the font was specified in the html)
when they choose text zoom and the text doesn't zoom?  Shouldn't the user's
wishes override those of the page designer?

Otherwise I have no argument with Hixie's comments.  The existing font zoom
works well for me -- I use it fairly often even though a set a minimum font
size, since pages that force a font other than my chosen one often end up too small.
>> There should only be one font size control.
> [ ... ]
>> the removal of the font size pref for Monospace
>
> That would be a huge loss in usability on linux.

I used to buy that argument. However, I no longer do.

For the last 6 months I've been using Mozilla on Linux as my primary platform,
and I have it set up so that both my font size prefs are set to 16px. I haven't
installed any special fonts (except those required for MathML, and those aren't
either my default serif or default monospace fonts). And you know what? It works
fine. I don't have any Huge Loss of Usability. Web pages look prefectly normal.


> Like it or not, the Xfont model just isn't very good, and fonts don't always  
> appear at their advertised sizes. 

The monospace font pref isn't helping with that problem in any noticable way.

And anyway. If you re-read my proposal, you'll see that I specifically provided
an alternative solution to that problem in the point I numbered 5.


> Trying to find a size that's right for both the chosen proportional font and 
> the chosen monospace font is impossible; one of them will be either too big or
> too small. 

WORKSFORME on a 6-month old standard Mandrake 8.1 installation.


>> The font size prefs *shouldn't* affect pixel-sized text.
> I understand Hixie's arguments for this, but won't it be confusing for users
> (who don't and shouldn't have to know how the font was specified in the html)
> when they choose text zoom and the text doesn't zoom?

Again. Please re-read what I said. I explicitly stated that *font zoom* should
zoom *all* text, including pixel sized text, *as it does now*.

It's the default font size prefs that shouldn't affect pixel-sized text. That's
exactly what pixel sized text means in CSS.

It the page author says "I want 25px text" then CSS says that he should get 25px
text. That's what "25px" *means*. The author may be stupid to say so, but then
that's why we have the (potentially layout-destroying) font zoom feature. We
even have a minimum font size feature. And we should have a (persistent) page
zoom pref.


> Shouldn't the user's wishes override those of the page designer?

Yes, that's what page zoom, font zoom, and minimum font size are for. It's not
what the *default* font size pref is for.


Here is how I see our features fitting in with each other:

   Default Font Size, Default Page Colours, user stylesheets, etc: Set what the 
      web looks like by default, on pages whose authors have honoured the user's
      preferences.

   Minimum Font Size, !important user stylesheets, etc: Force certain features
      on web pages, so that pages all remain readable despite the author's 
      ignoracne of the user's preferences.

   Font Zoom: Transient changes to the font size, for pages that use large 
      amounts of text at the minimum font size or for when the reader is tired
      or at some distance from the monitor.

   Page Zoom Pref: A persistent increase in the size of all features of the web,
      for users with poor vision or very high resolution monitors.

   Page Zoom Chrome UI: A quick access to the page zoom pref for taking a closer 
      look at a web page.
Whiteboard: WONTFIX? DUPLICATE? (py8ieh: see comment 18 points 5 and 6)
>>> There should only be one font size control.
>> [ ... ]
>>> the removal of the font size pref for Monospace
>>
>> That would be a huge loss in usability on linux.
>
>I used to buy that argument. However, I no longer do.
>
>For the last 6 months I've been using Mozilla on Linux as my primary
>platform, and I have it set up so that both my font size prefs are
>set to 16px. I haven't installed any special fonts (except those
>required for MathML, and those aren't either my default serif or
>default monospace fonts). And you know what? It works fine. I don't
>have any Huge Loss of Usability. Web pages look prefectly normal.

	Whether or not you have problems with this is highly dependant
on a slew of factors.  I regularly use 3 different RH Linux machines,
and a few different FreeBSD 4.x machines running XFree86 3.6 and 4.x.
Of those machines, only the RH 7.2 using 1Kx768 resolution doesn't
seem to have major problems - and it still has some (monospace).

>> Trying to find a size that's right for both the chosen proportional
>> font and the chosen monospace font is impossible; one of them will
>> be either too big or too small.
>
>WORKSFORME on a 6-month old standard Mandrake 8.1 installation.

	Change your resolution to 1280x1K, or 1600x1200 and try again.
Or try it on a "standard" Xfree86 distribution instead of Mandrakes (which
probably has a bunch of non-standard fonts, etc).  Or try it with some font
other than the default.

>>> The font size prefs *shouldn't* affect pixel-sized text.

>> I understand Hixie's arguments for this, but won't it be confusing
>> for users (who don't and shouldn't have to know how the font was
>> specified in the html) when they choose text zoom and the text
>> doesn't zoom?
>
>Again. Please re-read what I said. I explicitly stated that *font zoom* should
>zoom *all* text, including pixel sized text, *as it does now*.
>
>It's the default font size prefs that shouldn't affect pixel-sized
>text. That's exactly what pixel sized text means in CSS.
>
>It the page author says "I want 25px text" then CSS says that he
>should get 25px text. That's what "25px" *means*. The author may be
>stupid to say so, but then that's why we have the (potentially
>layout-destroying) font zoom feature. We even have a minimum font
>size feature. And we should have a (persistent) page zoom pref.

	You're correct, that is what 25px means, and you're correct
that the author was probably stupid to say so.  The problem is that
that stupidity is commonplace, unlikely to go away, and that stupidity
confuses users.  They thought they selected a larger font size, and
then they hit a page where everything is small and hard (or
impossible, in some situations) to read, perhaps even mixed in with
correctly sized text.

>> Shouldn't the user's wishes override those of the page designer?
>
>Yes, that's what page zoom, font zoom, and minimum font size are for. It's not
>what the *default* font size pref is for.

	The whole issue mostly comes down the old argument: does the
user (via the user-agent aka the browser) get to decide what to display
and how (even if that isn't what the page author intended), or does
the page author get to decide even if that means that the particular
user is inconvenienced or unable to use the page?

	Traditionally, browsers provided a number of ways in which a
use could override the page author.  Font size and style (originally,
before CSS), window size, whether images are displayed or not, whether JS code
is run (which can affect a page FAR more, and is saved), etc.

>Here is how I see our features fitting in with each other:
>
>   Default Font Size, Default Page Colours, user stylesheets, etc:
>   Set what the web looks like by default, on pages whose authors
>   have honoured the user's preferences.

	The last phrase is the important one.  

>   Minimum Font Size, !important user stylesheets, etc: Force certain features
>      on web pages, so that pages all remain readable despite the author's 
>      ignoracne of the user's preferences.

	Until CSS, font size (base size) used to be in this section.
Minimum font size loses information.

>   Font Zoom: Transient changes to the font size, for pages that use large 
>      amounts of text at the minimum font size or for when the reader is tired
>      or at some distance from the monitor.

	Again: there are people who really need for this to be saved,
unless they want to use a large minimum size and lose all the
information meant to be conveyed by relative sizes.

>   Page Zoom Pref: A persistent increase in the size of all features
>   of the web, for users with poor vision or very high resolution
>   monitors.

	AaronL might be able to provide more real feedback on this, but
I imagine that sight-impaired users might NOT want to zoom images by default.
Full Zoom (bug 4821) also tends to cause large scrollbars, which make the
browser tough to use.  (I know this.)

>   Page Zoom Chrome UI: A quick access to the page zoom pref for
>   taking a closer look at a web page. 

	I can't imagine a good way to make this easier that doesn't
have other negative impacts.

> Change your resolution to 1280x1K, or 1600x1200 and try again.

I use 1600x1200 on a 15" laptop monitor.

I do grant you that it is possible that some Unix systems have bad font setups,
but I am not convinced that we, in the 21st century, should still have to be
implementing work arounds for problems that other platforms have had solved for
decades, and that some modern Unix systems have shown need not exist.


> Does the user (via the user-agent aka the browser) get to decide what to 
> display and how (even if that isn't what the page author intended), or does
> the page author get to decide even if that means that the particular
> user is inconvenienced or unable to use the page?

Neither. There is a third option, the one I described in my previous comment,
and the one that the specs specify. The user gets to pick default settings. The
author gets to selectively override some of those. Then the user gets to
selectively override the author's choices. In the case of font size, there is
one pref on the "user default" side, and there are four on the "user override"
side. See my list in my previous comment on this bug.


> Traditionally, browsers provided a number of ways in which a user could 
> override the page author. 

And since the advent of CSS User Stylesheets, the number of ways is even bigger.


> Until CSS, font size (base size) used to be in this section.

"Before CSS" is over 6 years ago now, by the way. This isn't exactly a new
change. Half of the life of the web has been this way.

Incidentally. Other browsers (Opera, IE) implement a subset of what I am
describing. Do they also lack the font size preferences you are advocating?


> Again: there are people who really need for [foont zoom] to be saved

Pages that use pixels for sizing (and thus are not affected by the default font
size prefs) are those that font zoom destroys. I don't understand why anyway
would want us to destroy these pages. Page zoom gets around this. Could you give
me more details on these users?


> unless they want to use a large minimum size and lose all the information 
> meant to be conveyed by relative sizes.

In practice this is not an issue. Minimum font sizes that are small enough (e.g.
around the 16px mark) not to totally destroy web pages do not lose any meaning
of consequence. Users that would pick minimum font sizes that _do_ lose meaning
should be using page zoom, not the minimum font size pref.


> AaronL might be able to provide more real feedback on this, but I imagine that
> sight-impaired users might NOT want to zoom images by default.

I imagine the opposite. Therefore we have a stalemate until someone can provide
some hard evidence either way.


> Full Zoom (bug 4821) also tends to cause large scrollbars, which make the 
> browser tough to use.  (I know this.)

LOL. How can you assert knowledge about bugs in a feature that we don't have???


> I can't imagine a good way to make [page zoom chrome UI] easier that doesn't
> have other negative impacts.

What's wrong with the UI seen in, e.g., Opera? Or a UI similar to what we have
now for font zoom?


I mean no disrespect, but I am baffled by your arguments.
Summary: Font size prefs need to be redesigned; functionality problems → Font size prefs need to be redesigned; functionality problems (font zoom ui)
Component: User Interface Design → Layout: Fonts and Text
I think the need of users to have changes to "default font size" prefs work
consistently within and across existing pages outweighs the need of site owners
to be able to coordinate image sizes with text sizes.  I don't think the
"minimum font size" pref helps much.
Summary: Font size prefs need to be redesigned; functionality problems (font zoom ui) → Default font size pref should affect "absolute" font sizes
I'd much rather stop supporting absolute font sizes entirely.  (Note that Jesse
retitled the bug in his previous comment so as to make the bug INVALID in my
opinion.)
Indeed, bug 131236 comment 3 offers one good reason why the newly-summarized 
bug should not be fixed. Bug 96096 comment 18 offers another reason (whether 
that reason is a good one is, I suppose, not is not for me to say).
This bug is now definitely INVALID.
http://ln.hixie.ch/?start=1045789943&count=1 : "I recently increased my default
font size to 24 pixels."
Indeed. From this experience I have learnt that:

   1. We need Page Zoom urgently.
      I would much rather like to have my prefs set as font size = 16px, page 
      zoom = 200%. At the moment, I can't read any of my web comics without
      using your "zoom in images" bookmarklet.

   2. We need Text Zoom to be per-site.
      Whenever I hit a site that uses pixel-sized units, I hit Ctrl-+ twice. 
      When I click through a link to a site that respects my font prefs, the 
      text size becomes ridiculously large and I have to hit Ctrl+0.

I don't see how my experiences validate this bug.
200% of 16px is 32px, probably not what you want or need if your default is
24px. I find 16px is about right at 1024x768. Divide 1600 by 1024 and multiply
times 16px, and the result is 25px. So, like IH, I find 24px default at
1600x1200 works nicely, considering the higher resolution produces vastly
superior letter forms with "right size" text compared to lower resolutions.

I don't think there's any way for the request here to be satisfied. MPT's
comment at http://bugzilla.mozilla.org/show_bug.cgi?id=96096#c18 also seems to
confirm.

This bug looks awfully similar to bug 96096.

invalid.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.