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 http://style.verso.com/font_size_intervals/altintervals.html#st 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

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.

Related to that problem, Tapio Markula <tapio1@gamma.nic.fi> 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 consistent). I made a page about this matter to my Teaching site: http://www.nic.fi/~tapio1/Teaching/Model8c.html 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 bug.

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.

*** Bug 22700 has been marked as a duplicate of this bug. ***

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.

Putting on beta radar.

PDT is looking for some specific examples before deciding if this is a beta stopper

Adding [NEED INFO] to Status Summary.

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. FYI: - 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.

Putting on PDT+ radar for beta1.

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 (News.com, 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.

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.

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?

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.

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".

Sure: the rounding was disabled.

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.

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...

Putting on PDT+ radar for beta1.

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.

It's checked-in, the pref is 'on' by default. Marking fixed.

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

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

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.

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.

http://bugzilla.mozilla.org/show_bug.cgi?id=31226 was opened for Linux problem. Marking Verified for Win and Mac.

http://style.verso.com/font_size_intervals/altintervals.html moved to http://style.cleverchimp.com/font_size_intervals/altintervals.html It and the result of fixing this I hope can someday be refined via bug https://bugzilla.mozilla.org/show_bug.cgi?id=187256 and my tentative W3 proposal currently at http://members.ij.net/mrmazda/auth/w3fonts-css3.html

http://members.ij.net/mrmazda/auth/w3fonts-css3.html moved to http://fm.no-ip.com/auth/CSS/css3/3.4/