Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 18136 - Fixing the font size mess {font} {ll}
: Fixing the font size mess {font} {ll}
[PDT+]fix in hand; other code changes...
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P1 normal (vote)
: M14
Assigned To: Pierre Saslawsky
: Christine Hoffman
: Jet Villegas (:jet)
: 22700 (view as bug list)
Depends on:
Blocks: 21950 24005 28766
  Show dependency treegraph
Reported: 1999-11-05 15:31 PST by fahrner
Modified: 2008-06-05 09:06 PDT (History)
7 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Horizontal 1000 pixel ruler for test cases. (1.07 KB, image/gif)
2000-02-23 22:21 PST, Erik van der Poel
no flags Details
Test case for variable width fonts in HTML sizes 1-7. (1.59 KB, text/html)
2000-02-23 22:23 PST, Erik van der Poel
no flags Details
Test case for fixed width fonts in HTML sizes 1-7. (1.59 KB, text/html)
2000-02-23 22:25 PST, Erik van der Poel
no flags Details
Test case for <input type="text"> in HTML sizes 1-7. (4.67 KB, text/html)
2000-02-23 22:28 PST, Erik van der Poel
no flags Details
Horizontal 300 pixel ruler. (422 bytes, image/gif)
2000-02-24 09:54 PST, Erik van der Poel
no flags Details
Fontsizes according to CSS2 spec when mozilla is set to medium=16px (1023 bytes, text/html)
2000-02-26 13:53 PST, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details

Description fahrner 1999-11-05 15:31:59 PST
The (currently unfinished) article at the cited URL discusses the general mess of the CSS font-size system and its relation
to legacy systems, and proposes a harmonizing fix. See especially

I've thought long and hard about these issues for a few years now. I don't want to overburden the already overburdened team
with implementing this immediately, but I firmly believe that it's worth shooting for in 5.1 and beyo
Comment 1 Pierre Saslawsky 1999-11-16 16:28:59 PST
Thanks for your paper, Todd. I won't look into it right now but the issue may
surface sooner than you think. There is some teeth-grinding amongst the Mac
folks here already.
Comment 2 Pierre Saslawsky 2000-01-04 15:52:59 PST
Related to that problem, Tapio Markula <> sent us the
following note.
In fact Mozilla 5.0 Gecko displays font-sizes quite well. I just ask, that
that the font-size:medium could be as default the same as it is in MS IE =
'17px'. Then all relative font-sizes from xx-small to large are exactly as
big in both browsers. I made a bug report to Microsoft and complained about
the inconisitency of relative font sizes in MS IE 5.0. In fact MS IE 5.0
works much more inconsistent, because undefined is too small and x-large
and xx-large use inconsisten scaling factor (Mozilla 5.0 Gecko use

I made a page about this matter to my Teaching site:

It is tiny error to display xx-small as 10px instead of 9px (when 'medium'
is set to '16', xx-small should be '9px'; if 'medium' is '17px' (this is
the value of MS IE), then xx-small should be '10px').

Because the font-size concerns just one pixcel, this might not deserve a
Comment 3 David Baron :dbaron: ⌚️UTC-7 2000-01-04 17:30:59 PST
Medium should be equal to the user's font-size preference, and the other values
should be based around that size.  I think Todd's proposal for computing those
sizes is a good one.  The "absolute" keywords should definitely not be fixed to
certain pixel values.
Comment 4 Pierre Saslawsky 2000-01-08 03:28:59 PST
*** Bug 22700 has been marked as a duplicate of this bug. ***
Comment 5 Pierre Saslawsky 2000-01-18 14:29:59 PST
M20 was just a convenient way for me to see the font-related bugs in my list.
Using the {font} tag in the summary line instead.
Comment 6 rickg 2000-02-01 20:35:28 PST
Putting on beta radar.
Comment 7 Phil Peterson 2000-02-02 16:50:09 PST
PDT is looking for some specific examples before deciding if this is a beta 
Comment 8 leger 2000-02-04 05:07:46 PST
Adding [NEED INFO] to Status Summary. 
Comment 9 Pierre Saslawsky 2000-02-04 14:17:09 PST
I sent the following mail to Phil and RickG yesterday AM:
My M14 bug list contains several bugs related to fonts. Two of them especially 
describe the same thing: bug 21950 is the end user side of the problem where you 
can find all the info and testcases, while bug 18136 is where the discussion
started for a solution. 21950 is already tagged PDT+, 18136 should be PDT+ too. 

- Two other bugs may be duplicates of 18136 and 21950. They are 22925 and 19613. 
- The last two bugs with a {font} tag are likely to be separate issues: 12461 and 
22303, although 12461 may be fixed when 18136 is done. 
Comment 10 leger 2000-02-07 17:36:27 PST
Putting on PDT+ radar for beta1.
Comment 11 ekrock's old account (dead) 2000-02-18 01:17:37 PST
Clearing PDT+ status for re-evaluation by PDT team. I believe that PDT+ status 
will be restored, but only because 21950 depends on 18136, and PDT team should 
be aware of this relationship.

Bug 21950 is a report that certain specific sites break because Mozilla displays 
their fonts larger than Nav4. Because some of these sites are Top 100 (, 
My Netscape, etc.) this has been marked a PDT+ beta1 bug.

Bug 18136 is an enhancement request to implement Todd Fahrner's font system (and 
implicitly, to make it the default, as it is being proposed as a solution for 
21950). Implementing that font system per se is not a beta1 requirement. (It's a 
very desirable enhancement request, which is something different.) HOWEVER, it 
is currently being asserted that implementing Todd Fahrner's font system and 
making it the default will fix 21950, which *is* a beta1 bug.

So the situation should really be as follows: 
- 21950 is PDT+ beta1 (no change from current situation)
- 21950 depends on 18136 (just marked this)
- 18136 is not a beta1 bug for its own sake (clearing PDT+ for re-evaluation)
- HOWEVER, because 21950 is PDT+ beta1 and depends on 18136, 18136 inherits the 
21950 PDT+ beta1 status (noting this in comments for 18136, so PDT+ will likely 
be restored)

If we were to find a quick-and-dirty patch that fixed 21950 directly without 
implementing Todd Fahrner's system and making it the default (18136), then the 
depends relationship would be eliminated and 18136 would lose its inherited PDT+ 
beta1 status.

NOTE: As desirable as Todd Fahrner's system is, because it is a significant 
change to a very fundamental part of the browser (font size calculation), 
activating a first implementation of this algorithm carries a significant 
theoretical risk of unforeseen consequences, including possible beta1 stoppers, 
if (1) the algorithm, correctly implemented, has unforeseen effects on some of 
the 800 million pages out there, or (2) our initial implementation turns out to 
have bugs. Therefore, if we implement Todd Fahrner's algorithm for beta1, we 
should make sure that there is at least a week of intensive testing scheduled 
thereafter before the tree is branched for beta1.

The two conclusions follow logically:
1) We should ask ourselves whether there is a quick-and-dirty way to fix 21950 
that is simpler than implementing the complete Todd Fahrner algorithm and making 
it the default. This would eliminate 21950's dependency on 18136 and mean that 
18136 plus 5 days of testing was no longer a blocker for beta1.
2) If we conclude that the only way to fix 21950 is to implement the complete 
Todd Fahrner algorithm and make it the default, then we must do so ASAP so we 
can begin the 5 days of testing and avoid becoming a long pole blocking beta1.

jar has sent email saying that all beta1 bugs must be marked with a target 
completion date. pierre, what is your target check-in date for this bug? Our 
target completion date should really be that date plus 5 days because of the 
need for intensive testing.
Comment 12 Pierre Saslawsky 2000-02-18 03:22:51 PST
Changing the status white board back to [PDT+] from "should undergo 5 days of 
intensive testing after checkin before beta1 branch". We have a process in place: 
the PDT team decides what's going into the tree and QA estimates how long a 
particular feature needs to be tested.

I have Todd's system working on Mac and Windows. On Mac, it allows many major 
sites to be displayed correctly (finally!). On Windows, it allows the user to 
select smaller font sizes. The important aspects of that system are XP 
compatibility, current IE compatibility on Mac and future compatibility on 
Windows, and standard compliance. 

Before turning it on, we need to fix the Text and Dropdown list widgets which 
have been tweaked for the Nav quirks. We should also change the default font size 
values in the prefs to reflect that the new system works in pixels, not points.
Comment 13 Erik van der Poel 2000-02-18 11:26:53 PST
The default unit for the font size pref is already pixels (px), not points (pt).
The default variable width font size is 16px, currently.

The size *menu* in the font size UI is based on the numbers that we see for pt
in Nav4. This may need to be tweaked, but perhaps a different issue from yours?
Comment 14 ekrock's old account (dead) 2000-02-18 18:15:33 PST
Remember that only the PDT team is authorized to set [PDT+] or [PDT-] on a bug 
report. Anyone else is free to clear that code to trigger a reevaluation of the 
bug's priority level by the PDT team, and product management has been asked by 
the PDT team to review bugs and do so. Personally, I agree with you that this 
bug should be [PDT+] (although for different reasons), but let's allow the PDT 
team to review the status, become aware of the issues by doing so, and make the 
call. Reclearing [PDT+] so that can happen.

Re: your comments in 21950 about the importance of 18136: no one is questioning 
how desirable 18136 is, and your dedication to implementing features is 
admirable. Thank you for all your hard work. At the same time, it's important 
for us all to remember that right now, only PDT+ fixes are authorized for 
check-in, and 18136 should only be checked in for beta1 if it is PDT+ approved, 
in the interest of stabilizing, branching for a timely beta1, and enabling us to 
reopen the tree so that others may resume checking in non-PDT+ fixes.  Note that 
with your careful testing, you've already found that checking in 18136 will 
require some changes to the codebase you're aware of, and since knowledge is 
imperfect, the possibility exists that it will cause other issues no one's yet 
aware of.

Here is my enumeration of your reasons for checking in 18136 and assessment of 
the priority level of each one:

1) 21950 is approved PDT+ and 18136 is believed to fix 21950 --> 18136 is PDT+
2) current IE compatibility on Mac: ENH beyond committed features (not beta1)
3) future compatibility with IE on Windows: ENH (not beta1)
4) standards compliance: we're already more than sufficiently standards 
compliant for beta1; this algorithm essentially is an improvement to the 
interpretation and interoperation of standards (not beta1)
5) allows web designers to write-once-run-anywhere: ENH (not beta1)
6) many major sites finally render correctly on the Mac: fix to known bug that 
existed for Nav4.x (not beta1)

Also, please don't eliminate others' notations in the status field without 
talking with them first. At the original conference call at which we agreed to 
accept 18136 for beta1, this was agreed to by myself (and some or all of the 
others present) only on the condition that we intended there to be 5 days of 
intensive testing post-checkin, before beta1, because this is a significant 
change to core browser code. Restoring status field to read "fix in hand; other 
code changes necessary; 5 days of testing needed post-checkin." Status field 
should reflect this.

Don't get me wrong; because it's believed to fix 21950, I still agree with you 
that 18136 should go in for beta1. However, let's make sure that we keep the PDT 
team informed, let them make the PDT+ assessments, and also follow the testing 
plan we agreed to as a group in the conference call. Thanks again for your hard 
work in implementing this algorithm that will do so much for users and 
developers alike, and let me know how I can help you in testing as soon as it's 
checked in.
Comment 15 Hixie (not reading bugmail) 2000-02-21 15:00:18 PST
Pierre, you did do your work on Todd's algorithm with the font rounding code
disabled, right? Because it does make a difference... (I'm just making sure!)

See also bug 24005, "font size 9px rounded down to 8px".
Comment 16 Pierre Saslawsky 2000-02-21 15:07:50 PST
Sure: the rounding was disabled.
Comment 17 Pierre Saslawsky 2000-02-21 15:26:25 PST
In a quick response to ekrock's comments from 2000-02-18 18:15:
    6) many major sites finally render correctly on the Mac:
    fix to known bug that existed for Nav4.x (not beta1)
It's not a fix for a known MacNav4 bug. It's a fix for all the Mozilla versions 
released on the Mac until today. MacMoz can't be used on these sites (cnet, 
microsoft, msnbc, salon, sportsline..) unless you set what Mac users find to be 
an annoyingly large base font.

Comment 18 Hixie (not reading bugmail) 2000-02-21 15:42:09 PST
Pierre: Ok, cool.

So, at the risk of sounding stupid: what is stopping us from checking in what
you have done so far, but controlled by a pref and with the pref defaulting to 
off? This would allow us QA to begin the 5 days of testing that PDT want...
Comment 19 leger 2000-02-23 17:59:34 PST
Putting on PDT+ radar for beta1.
Comment 20 Erik van der Poel 2000-02-23 22:21:03 PST
Created attachment 5670 [details]
Horizontal 1000 pixel ruler for test cases.
Comment 21 Erik van der Poel 2000-02-23 22:23:51 PST
Created attachment 5671 [details]
Test case for variable width fonts in HTML sizes 1-7.
Comment 22 Erik van der Poel 2000-02-23 22:25:46 PST
Created attachment 5672 [details]
Test case for fixed width fonts in HTML sizes 1-7.
Comment 23 Erik van der Poel 2000-02-23 22:28:56 PST
Created attachment 5673 [details]
Test case for <input type="text"> in HTML sizes 1-7.
Comment 24 Erik van der Poel 2000-02-23 22:33:16 PST
I've created test cases for Variable Width Fonts, Fixed Width Fonts, and HTML
form text fields. I'd like some help with the creation of test cases for the
other HTML form widgets, such as Button, Select, Select Multiple, TextArea, etc.
Comment 25 Pierre Saslawsky 2000-02-24 05:29:28 PST
It's checked-in, the pref is 'on' by default.
Marking fixed.
Comment 26 Erik van der Poel 2000-02-24 09:54:15 PST
Created attachment 5698 [details]
Horizontal 300 pixel ruler.
Comment 27 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-02-26 13:48:22 PST
According to the CSS2 spec there should be a factor of 1.2 
between "medium", "smalla", "x-small" etc. If 4.x didn't have this factor then 
maybe this should be done using quirks/strict?

Attaching testcase with fontsizes according to CSS2
Comment 28 Jonas Sicking (:sicking) No longer reading bugmail consistently 2000-02-26 13:53:54 PST
Created attachment 5801 [details]
Fontsizes according to CSS2 spec when mozilla is set to medium=16px
Comment 29 David Baron :dbaron: ⌚️UTC-7 2000-02-26 13:59:04 PST
The CSS2 scaling factor of 1.2 between sizes is:
 1) a recommendation, not a requirement
 2) a bad idea in some situations, which is what Todd's proposal fixes
Comment 30 ckritzer (gone) 2000-03-08 14:10:15 PST
This looks good on:
Win98 2000-03-07-09 Commercial
MacOS9 2000-03-07-08 Commercial

And is still broken on:
Linux6 2000-03-08-09 Commercial

Reopening for Linux.
Comment 31 Pierre Saslawsky 2000-03-08 14:36:09 PST
This bug was about the implementation of Todd Farhner's algorithm. I guess it was 
reopened in error. If you are seeing some platform-specific problems, please open 
separate bug reports. Marked fixed again.
Comment 32 leger 2000-03-09 13:42:38 PST was opened for Linux problem.

Marking Verified for Win and Mac.
Comment 33 Felix Miata 2005-05-26 09:28:42 PDT moved to

It and the result of fixing this I hope can someday be refined via bug and my tentative W3 proposal
currently at

Note You need to log in before you can comment on or make changes to this bug.