Closed
Bug 155063
Opened 22 years ago
Closed 13 years ago
Consistency in font sizing in Chimera
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jcho, Unassigned)
Details
Attachments
(6 files)
The following observations are premised on my belief that in Chimera, as in Mozilla supposedly, relative font sizes are determined using the same em settings by which headings are presently defined, so in terms of size: h1 = font size 6 = xx-large = 2em h2 = font size 5 = x-large = 1.5em h3 = font size 4 = large = 1.17em h4 = font size 3 = medium = 1em h5 = font size 2 = small = 0.83em h6 = font size 1 = x-small = 0.67em In addition, font size 7 (HTML 3.2) is equivalent to 3em. Based on the above, and assuming that Chimera will eventually allow users to set their preferred font sizes from a given range, I have these observations to make: a. Heading level H5 (presently set to 0.83em) will render more accurately at base font size 12 (base 12), if its font-size is set to 0.833em instead. (The added decimal place does make a difference.) With this change, headings will appear consistent throughout the range of font settings. b. Font size 7 (HTML 3.2) renders incorrectly at base 13 & 12; it should be 3em, or exactly 3 times the base font size. c. Font size 5 (HTML 3.2) and x-large (CSS) renders incorrectly at base 15 & 13; it should be 1.5em. d. Font size 4 (HTML 3.2) and large (CSS) renders incorrectly at base 14 & 13; it should be 1.17em. e. The default minimum font size should be set to 9px, ie: pref("font.minimum-size.x-western", 9); to allow fonts defined as xx-small to render correctly at fonts settings higher than 14, as well as the fact that the Mac can render fonts properly down to a size of 9px.
Reporter | ||
Comment 1•22 years ago
|
||
This html page demos the comparison between headings and relative font sizes with em settings and the inconsistencies arising at certain base font size settings in Chimera
Reporter | ||
Comment 3•22 years ago
|
||
It may very well be. But I have been unable to trace a similarly reported bug in Mozilla.
Jeffrey, I meant that if you're reporting something that is the same in Chimera and Mozilla, then this bug should be changed to Mozilla instead of Chimera.
Reporter | ||
Comment 5•22 years ago
|
||
Sorry, Greg. I haven't a copy of Mozilla with me to check if this is the case. Should I switch the product name then?
Jeffrey, yes, but only if you're sure it happens in Mozilla also. Problems with web content layout usually belong on Mozilla, but not always.
Comment 7•21 years ago
|
||
sounds like a moz bug
Assignee: saari → font
Component: Page Layout → Layout: Fonts and Text
Product: Camino → Browser
QA Contact: winnie → ian
Version: unspecified → Trunk
->style
Assignee: font → dbaron
Component: Layout: Fonts and Text → Style System
Comment 9•21 years ago
|
||
Note size mismatches in large and x-small groups. 1.583em != 1.5em and .75em != .67em. Some sizes actually match due to available font size step granularity.
Comment 10•21 years ago
|
||
Note size several mismatches: 1.583em != 1.5em, 1.25em != 1.17em != large/size=4, .833em != .83em, & .75em != .67em != x-small/size=1. OS/2 here is serving up fonts with inconsequential size granularity. Reporter, maybe you should supply a screenshot on a current/recent Chimera version. Note that at the sizes at issue, 16px and under default, sizes other than e.g. %, px, pt or em, are provided not by the percentage scale at http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#330 but by the tables at (standards mode) http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#265 and (quirks mode) http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#297 In both these tables you can see that for many defaults, xx-small = x-small and even = small. There is a proposal to change this in bug 187256.
Comment 11•21 years ago
|
||
Except as noted, the sizes are according to: http://lxr.mozilla.org/seamonkey/source/content/html/style/src/nsStyleUtil.cpp#265
Comment 12•21 years ago
|
||
Note here that all sizes match except the sub-default % sizes, which is expected, since table values are used for the others rather than the scale percentages, and the small table values don't match the scale at all.
Comment 13•21 years ago
|
||
This is similar to the previous attachment, except that the scale percentage for large/size=4 also doesn't match.
Assignee: dbaron → nobody
QA Contact: ian → style-system
Comment 14•17 years ago
|
||
Is this still a problem in Camino?
I don't see what leads to the expectation that the named font sizes (which were probably a bad idea to begin with) should be the sizes used for HTML h1..h7. So I think our behavior here is fine.
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.
Description
•