Closed Bug 111879 Opened 23 years ago Closed 13 years ago

Allow user specification of font step size, or document CSS required for same.

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: kmself, Unassigned)

References

Details

IIRC, at one point the W3C HTML specification called for a step size between the
standard HTML font sizes of 20% (I've looked for this in the 4.01 specification
without success).  Over the standard seven step scaling range, this results in
fonts from 50% to 200% of "normal", with "size=3" being the default.  This is
actually an improvement from the initial spec which allowed a much larger step
size (50% IIRC), but is still excessive under normal circumstances.

The problem arises from sites using font and size directives which don't reflect
or aren't directly supported by the user's configuration or supported options. 
For these sites, body (and other text elements) may be too small, or too large,
for comfortable viewing.

The two solutions I've found most useful are to compress (or eliminate) the
scaling range, and/or to rewrite CSS rules such that fonts are all displayed in
a set face and size.  Other alternatives include specifying text element sizes
in invariant units other than points -- pixels or physical dimensions, tuned to
the user's display configuration.

The range compression works relatively well as a hack.  My own strong preference
is for minimal contextual hinting from font size.  Texts with widely variant
font sizes for header and body elements seem garish (yes, I'm one of those
Luddites who prefers the classic nroff Prentice-Hall Unix texts' typsetting to,
say, a Que or Sams text with their HUGE SHOUTING TITLES).  Not to mention the
abuse of such elements is grossly annoying when the user's environment doesn't
match the page designers.  I find a step size of 2-5% is sufficient for
distinguishing hierarchy within text, while ensuring readability across a wide
range of sites.  This provides scaling from 94% to 108% (at 2% step) to 90% -
120% (at 5% step).

Another possible fix would be to offer as a possible user.css a CSS stylesheet
(or set of stylesheets) which goes a long way to defining a rigid set of font
faces and sizes which won't, under any circumstances, be overridden by those
specified in a page's HTML.  There are a number of sheets and points on the
current (Nov 25, 2001) Mozilla website, but none addresses this concern
satisfactorially.  I've been through several sources of CSS information
(including the standard itself and multiple designer-oriented websites) without
being able to piece this together myself.  Most CSS documentation is oriented at
website authors, not end users, and seems disturbingly unconcerned with issues
such as ensuring basic readability and accessability.

For a short roster of sites which specify basic text element overrides, which
I'd like to override myself:

  - http://www.theregister.co.uk/  Specifies font and size, using CSS.
  - http://scoop.kuro5hin.org/  Specifies font and size, using tags.
  - http://www.infoworld.com/   All-around bad design, including small fonts and
                                bad color scheme.
> find a step size of 2-5% is sufficient for distinguishing hierarchy within text

Really?  For a 15px base font (let's be optimistic) this is less than 1px
difference between font sizes.  Most unix systems only have fonts every 2px to
start with....

Confirming rfe, though.  2-5% is kinda low but 10% would be reasonable in some
circumstances.
Assignee: asa → dbaron
Status: UNCONFIRMED → NEW
Component: Browser-General → Style System
Ever confirmed: true
QA Contact: doronr → ian
> IIRC, at one point the W3C HTML specification

I think that was the CSS spec, and you're comparing CSS1 and CSS2.

Todd Fahrner has written detailed proposals for how CSS font-size keywords
should work, and I think we've moved pretty close to them, at least in standards
mode.  I don't think a pref for everything is the solution -- I think if there's
something wrong with our current solution we should fix it for everyone, unless
there are really good reasons that the ideal solution would vary significantly
between users.  We have too many prefs already.
Long clarification on font step size intent.

> Really?  For a 15px base font (let's be optimistic) this is less than
> 1px difference between font sizes.  Most unix systems only have fonts
> every 2px to
> start with....
> 
> Confirming rfe, though.  2-5% is kinda low but 10% would be reasonable
> in some circumstances.

Netscape 4.x allowed the option to set step size.  I found best results with a setting of 05 (units were percent).  I noticed no difference at any lower value, and didn't try anything higher.  I'm not sure what the sensitivity or minimum effective value

If you're asking whether or not my intent is to have little or no delta between font sizes, then yes, my intent is to have little or no delta, _particularly_ at or near the default setting. 

Many websites run with a "size=2" tag.  If they're going to treat this as a default size, then it should be sized as default, not 20% smaller than default, and if available font points don't provide a gradation sufficient to distinguish default and "size=-1", the desired effect is being met.

A depressingly large number of sites run with body text set at "size=1" or "size=-2".  Again, if this results in a size equal to or one point smaller than default, it's meeting the spec.

The reality is that such text is being presented as default body text, but is not rendered as such in a large subset of browser clients.  Or the user would prefer more direct control over font rendering at the client side.



Usability impacts:

Text which is meant to be significantly smaller than default is generally being demphasized (e.g.:  legal boilerplate, sometimes item captioning).  In some rare cases, page layout is affected when this text is enlarged.  This should be considered a web designer fault, not a user fault:  there is no guarantee that any given user agent (either with default settings or as configured by the user) will display content as intended by the designer.  The fact that brittle site design breaks readily should be considered a feature, not a bug, and fair warning to the designer that the page should be reconfigured for more flexible rendering.  In any event, there is no loss of legibilty by increasing the size of such text.

Larger point sizes are less of a concern from a readability standpoint: they're already sufficiently large to be legible, assume the user has sleected a comfortable default for body text.  Again, if other contextual hints don't do a sufficient job of indicating context, the page has design problems.  Adn, again, there is no loss of legibility assuming default font face/size are selected for comfortable viewing by the user.

Memo to the web designers:  Explicit layout should be presented in an invariant format -- PostScript or PDF -- not HTML.



It's quite possible that I'd want *all* font "size" and "face" hints to be ignored, and to have a page rendered with a uniform font and point size.  The Dillo browser already does this -- it has one font, at one size, compiled in.  Frankly, given the state of the Web, late 2001, it's kinda nice at times.

Sounds like you want one of two things:

1)  The minimum font-size pref (which we have).  UI coming up, in the meantime
    if you're interested I can look up what the prefname is

2)  "* { font-size: normal; font-weight: normal; }" in your userContent.css
I'm quite interested in this issue also.  I'm currently using the font zoom
feature to force fonts to readable sizes in our application.  This works, but
still leaves small fonts too small, and since we're already pushing the layout
due to small displays and larger fonts, I need to limit the amount of increase
in the font sizes.  Being able to "flatten" the font-space (no matter how it's
specified or in what units) is important to me.
> 2)  "* { font-size: normal; font-weight: normal; }" in your userContent.css

We could also ignore text sizes and text decorations when the pref that disables 
all styles is set (bug 32372).

> I think that was the CSS spec, and you're comparing CSS1 and CSS2.

Yes, thanks for the ref.

> Todd Fahrner has written detailed proposals for how CSS font-size keywords
> should work, and I think we've moved pretty close to them, at least in 
> standards mode.

I'm not familiar with Todd's work, though a Google search turns up a number of
relevant-looking documents, including particularly http://style.cleverchimp.com/ 

The argument against point sizes -- a possible issue on website cross-platform
utility -- is also well taken: 
http://style.cleverchimp.com/font_size/points/font_wars.GIF


> I don't think a pref for everything is the solution -- I
> think if there's something wrong with our current solution we should fix it 
> for everyone, unless there are really good reasons that the ideal solution 
> would vary significantly between users.  We have too many prefs already.

I'm not convinced that preferences are bad of themselves.  Hiding the obscure
ones from novice users is good.  Providing functionality only through
config-file edits (and documenting this), or as I initially said, through a CSS
stylesheet (or snippet) for inclusion by the user which explicitly overrides
these settings would be useful.  Options to ignore point specifications (points
are evil on numerous counts) or translate them to px or em units, might also be
useful.

This issue leads as I've said to fundamental questions of how usable sites are
cross-platform.  As such, this is significant in keeping a free web based on
open standards.  A good goal.
> Sounds like you want one of two things:
> 
> 1)  The minimum font-size pref (which we have).  UI coming up, in the meantime
>     if you're interested I can look up what the prefname is

I've got this configured.  It's not a fully acceptable solution for a number of
reasons.

First, it only effects the low end of the scale.  It's still possible for pages
to specify larger-than-comfortable fonts, for which this setting has no effect.

Second, this effectively destroys all contextual hinting provided by font
sizing.  Reducing the scaling factor to some nonzero value _will_ preserve this
visual cueing, though deemphasizing it.  If the user wants to remove _all_ such
cueing, they may do so by setting the scaling factor to zero.

Third, the units for the minimum size are in points, not pixels or ems (AFAIK).
 A reasoable value for my preferred proportional font (garamond) is too large
for my preferred monospaced font (courier new).  This could be fixed by allowing
the user to specify units for font sizing (or changing units to px or ems).

Fourth, the minimum font size preference is a hack.  It's saying "you're right,
the scaling factor is too large, and people are abusing font sizes, so we're
going to arbitrarially truncate the low end of the font sizing scale, albeit in
a nonuniformly rendered unit, points".  Fix the root cause:  font scaling.

> 2)  "* { font-size: normal; font-weight: normal; }" in your userContent.css

I'm not sufficiently versed in CSS that I'd know what this means or effects. 
What does this do?



Also, if someone would drop me a line off bugzilla -- how do I respond directly
by mail to a bug?  Quick search doesn't show the method.  Thanks.
OK, more research and I think I may understand something.

I believe that my issue is with the values assigned to the <absolute-size> and
<relative-size> font size attributes, both as used in CSS and as used when
interpreting <font size=<value>> tags in HTML.

See:  http://www.w3.org/TR/REC-CSS2/fonts.html#font-size-props

I've created a simple userContent.css which overrides most font configurations:

    * { 
        font-size: normal !important; 
        font-weight: normal !important; 
        line-height: normal !important; 
    }

...which does fairly well for overriding CSS-specified font attributes, but does
zilch for any fonts sized with <font> tags.

Is there a way to modify the value of the absolute-size (xx-small, x-small,
small, medium, large, x-large, xx-large) attributes, via CSS?  I can find no
documentation of this, and the CSS specs indicate that this is hardcoded within
the client.

As I read it, the scaling factor is merely _suggested_:

    On a computer screen a scaling factor of 1.2 is suggested between 
    adjacent indexes

    http://www.w3.org/TR/REC-CSS2/fonts.html#value-def-absolute-size

Because of the rampant abuse of this web design element, I would *very strongly*
argue that this value should be capable of being overridden by user specification.

Otherwise, a pointer to appropriate sources (I've found
{ROOT}/include/mozilla/content/nsStyleUtil.h, but don't find the value encoded
within the header) so I can build my own would be appreciated.
Look in nsStyleUtil.cpp.  There are tables of point sizes (for a user font-size
selection of 9 to 17), and a table of %'s for user font sizes outside that
range.

I agree with you on many of the issues, though totally ignoring fonts from the
CSS code creates a different set of problems.
Ok, I'm attacking this from the CSS front.

I've created a userContent.css stylesheet, still under development, that does a
good job of undoing font-mangling from the bulk of sites I've visited over the
past three days.  A few things still need work.

See:  http://kmself.home.netcom.com/Download/userContent.css

There's a companion sample webpage with various style elements indicated:

See:  http://kmself.home.netcom.com/Download/test.html

This renders _all_ text at the user's default point size.  Where possible, it
uses the user's indicated serif, sans-serif, clean, and monotype font
preferences, with exceptions (eg: I've found that the textarea style doesn't
work with just "monotype" specified).

I'm also not happy with the virtual directory listing, which I'd prefer to be
monotype as well.

In general, however, this addresses about 80-90% of my concerns.

I *still* feel that stepsize should be:

1.  Configurable by the user.
2.  Scaled in ems rather than points.

I've also changed the bug severity.  I consider this to be a  minor bug
(readability affects usability directly), though it's not a showstopper, and
there are workarounds (as demonstrated here).
Severity: enhancement → minor
*** Bug 124383 has been marked as a duplicate of this bug. ***
*** Bug 126062 has been marked as a duplicate of this bug. ***
I agree the step size increment/decrement is currently too granular. I don't
agree that 2% could be adequate in most cases, but also believe 10% is
excessively granular. From the default prefs setting of 16px, an increment of
1px is 6.25%; from 13px, 7.7%. I suggest 1px as the default increment/decrement.

Also, I don't think this qualifies as minor. Seems to me this is really RFE, but
if not, should at least be normal severity.

Also, a fix here, particularly a change to 1px default, would likely moot bug
181438.

See http://members.ij.net/mrmazda/ss/hesperiaSS.html for some my work related to
font sizing issues, which I hope to update soon to address the shortcomings of
using user stylesheets.
*** Bug 208825 has been marked as a duplicate of this bug. ***
*** Bug 221840 has been marked as a duplicate of this bug. ***
Assignee: dbaron → nobody
QA Contact: ian → style-system
I don't think we want to do this.  (The named steps haven't turned out very useful or widely used, and I don't think it's worth adding user controls that aren't going to do much, and if they do, they'll probably just break pages.)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.