Closed
Bug 201751
Opened 21 years ago
Closed 21 years ago
font size = -1 causes size to increase instead of decrease
Categories
(Core :: CSS Parsing and Computation, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: jwz, Assigned: dbaron)
Details
Attachments
(5 files, 2 obsolete files)
In certain documents, <FONT SIZE="-1"> causes the font size to *increase* instead of *decrease*. This exhibits itself on livejournal.com, among other sites, and I've narrowed it down to this small test case: <style type="text/css"> body { font-size: 10pt; } </style> MMMMMMMMMMMMMMMMMMMMMMMMMMM <br> <font size="-1"> MMMMMMMMMMMMMMMMMMMMMMMMMMM </font> The bug persists when I select any item on the View/Text Zoom menu: the font size of both lines changes, but the second line is always larger than the first line. If it turns out that this is a configuration problem on my machine, rather than a Mozilla bug, I'd sure like to know how to fix it -- I don't believe I touched *anything* about the font stuff here, so I imagine it's a common problem. Mozilla could easily detect this problem by noting the line height in the fonts that it actually ends up using -- it's obvious that when requesting a smaller font, something has gone horribly wrong if the font you got back is actually taller. ------------------ Mozilla 1.3 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 Red Hat Linux release 8.0 (Psyche) Linux 2.4.18-14 #1 Wed Sep 4 12:13:11 EDT 2002 i686 athlon i386 GNU/Linux My Appearance/Fonts preferences say: Proportional Sans Serif 18 Monospace default 16 Allow documents to use other fonts Display resolution System setting xdpyinfo says: dimensions: 1280x1024 pixels (433x347 millimeters) resolution: 75x75 dots per inch depth of root window: 24 planes xset q says: Font Path: /home/jwz/.gnome2/share/cursor-fonts, unix/:7100, /home/jwz/.gnome2/share/fonts RPMs: mozilla-1.3-0_rh8_xft mozilla-nss-1.3-0_rh8_xft mozilla-psm-1.3-0_rh8_xft mozilla-nspr-1.3-0_rh8_xft Xft-2.0-1 XFree86-100dpi-fonts-4.2.0-72 XFree86-75dpi-fonts-4.2.0-72 XFree86-base-fonts-4.2.0-72 XFree86-font-utils-4.2.0-72 XFree86-truetype-fonts-4.2.0-72 bitmap-fonts-0.2-2 fontconfig-2.0-3 ghostscript-fonts-5.50-7 ttfonts-1.0-9 urw-fonts-2.0-26
Reporter | ||
Comment 1•21 years ago
|
||
Comment 2•21 years ago
|
||
Over to style system. The issue here is that <font size="-1"> is supposed to mean "1 step down from current size". And the default "current size" is 3. So in that testcase, <font size="-1"> is equivalent to <font size="2">. We base the size of a <font size="2"> on the font size set in preferences as the "default font size". I don't think any styles on parents of the font tag should affect that, but over to style system to make sure.
Assignee: kmcclusk → dbaron
Component: GFX → Style System
Assignee | ||
Comment 3•21 years ago
|
||
The traditional meaning of + and - size attributes on FONT (despite what HTML4 says) is that they are relative to the base font size (which defaults to 3, but can be overridden by a BASEFONT [1]), not relative to the font size of the container. This may not make sense, but it's not the kind of thing we can change without breaking a ton of web pages. [1] which, despite what HTML4 says, is in Netscape 4 a container rather than an empty element
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
Comment 4•21 years ago
|
||
Reporter, what you see really does amount to a configuration issue. #1-Don't use points to size web page text. At 75DPI, 10pt=10px. At 120DPI, 10pt=16px. With your 18px Mozilla default, <font size="-1"> means 15px. Hence, your testcase is showing you 10px on line 1 and 15px on line 2. You can do a quick comparison of points and pixels at http://members.ij.net/mrmazda/auth/pt-vs-pixel.html which may help in deciding what DPI to use for Mozilla and/or Linux. #2-Unless you are trying to make your Linux behave like an old Mac, you don't want Mozilla using 75DPI. At your 1280x1024 resolution, you'll be best served by 120DPI or 144DPI. You can leave Linux running at 75DPI and still have Mozilla running at 120 by putting user_pref(" browser.display.screen_resolution", 120); in user.js in your profile directory.
Reporter | ||
Comment 5•21 years ago
|
||
Um, what? I don't understand a word any of you said.
Can you please re-explain using smaller words?
> You can leave Linux running at 75DPI and still have Mozilla
> running at 120 by putting
> user_pref(" browser.display.screen_resolution", 120);
> in user.js in your profile directory.
I did that, restarted, and it doesn't seem to have made any
difference at all: everything looks the same as before.
Was this suggestion relevant to the bug I reported at all,
or was it supposed to make something else handwavingly "better"?
Comment 6•21 years ago
|
||
This is my expansion of the original small testcase, showing two extra lines plus descriptions of what is being displayed, made and tested before I submitted comment 4. I routinely use the user.js pref from that comment to switch DPI values for testing purposes. If you followed the instructions there you should see what I saw. All of Mozilla must be closed and restarted, not just the browser.
Comment 7•21 years ago
|
||
Comment 8•21 years ago
|
||
slightly different testcase... The first set of characters is the "default" font, from which <font size="-1"> is calculated. With my default font/dpi settings, the second set of characters (with the style applied) is smaller than the default. Hopefully this helps illustrate the interaction.
Comment 9•21 years ago
|
||
Attachment #120280 -
Attachment is obsolete: true
Comment 10•21 years ago
|
||
Attachment #120283 -
Attachment is obsolete: true
Comment 11•21 years ago
|
||
Testcase 120286 (comment 8) illustrates that <font size=x> trumps the font-size style applied to the span. Maybe this isn't invalid after all.
Comment 12•21 years ago
|
||
Of course it trumps it. Would you be surprised if the "foo" text in: <span style="font-size: 10pt"><font style="font-size: 20pt">foo</font></span> were 20pt tall?
Comment 13•21 years ago
|
||
> + and - size attributes on FONT ... are relative to the base font size (which > defaults to 3, but can be overridden by a BASEFONT [1]) Ohhhhh really? Why is bug 3875 verified wontfix, then? It seems dangerous for SIZE="-1" to be implemented at all, if it's relative to neither BASEFONT *nor* BODY's size as set by CSS. That's like implementing CSS "color" but not "background-color".
Comment 14•21 years ago
|
||
No it's not, since <basefont> is rarely, if ever, used in practice.
Assignee | ||
Comment 15•21 years ago
|
||
Since this bug is linked from jwz's blog ( http://www.livejournal.com/users/jwz/193866.html ), which says that 'This is because the FONT tag, when used to request a font "one tick smaller than the current size" has no knowlege of what the current CSS font size is', I'd like to comment that the same thing is true for HTML. <FONT SIZE="-1"> has no knowledge of what the current *HTML* font size is. <font size="5"><font size="-1">Text</font></font> <br><font size="2"><font size="-1">Text</font></font> yields two lines with the same font size. Doing otherwise for CSS would be *totally* changing the meaning of <font size="-1">, which has been silly since it was first introduced. (jwz seems to be confusing <font size="-1"> with <small>, which both predates it and makes sense.)
Assignee | ||
Comment 16•21 years ago
|
||
(Actually, I'm not so sure about the "predates" bit. And, given that I already spent 10 minutes trying to figure out whether I was right, I'm not planning find out for sure.)
Reporter | ||
Comment 17•21 years ago
|
||
Look, you can rationalize this all you want, but the fact remains that <font size=-1> results in a font that is *bigger* rather than *smaller*, and that is absurd on its face. Perhaps you're right and the spec requires you to do this stupid thing. That doesn't make it any less stupid.
Assignee | ||
Comment 18•21 years ago
|
||
Assignee | ||
Comment 19•21 years ago
|
||
<font size="-1"> means and has always meant "one 'notch' smaller than the
document's base font size". <small> means "one 'notch' smaller than the
surrounding text". (I even double-checked this using Netscape 3 on attachment
122413 [details].) I think it's probably about 8 years too late to change this.
Reporter | ||
Comment 20•21 years ago
|
||
And it is precisely the disconnect between "the document's base font size" and "the document's default CSS font size" that is the cause of the current silly behavior. There are now *two* "default document font sizes", and they don't talk to each other.
Comment 21•21 years ago
|
||
The "document's default CSS font size" is the same as the font size with no <basefont> element, namely, the user's preferred font size. The following: <style type="text/css"> body { font-size: 10pt; } </style> ...does not change the "document's default CSS font size", it simply changes the font size of the <body> element. What are you proposing we do to "fix" this bug?
Reporter | ||
Comment 22•21 years ago
|
||
Defining <font size=3> to mean "the font size of the body element" would be a good start.
Comment 23•21 years ago
|
||
No it would not. Font size 3 is determined by the user via his font size pref. The size font of body, if explicit, is determined by the page creator; if not explicit, via inheritance either from html rule or user pref. When either <font> or css is used exclusively for font sizing, there is no inconsistency.
Reporter | ||
Comment 24•21 years ago
|
||
> When either <font> or css is used exclusively for > font sizing, there is no inconsistency. Thank you for repeating the part where I said > There are now *two* "default document font sizes", > and they don't talk to each other. Look, you can tell yourself until you're blue in the face that it's "perfectly logical" for size=-1 to result in a font that's bigger, but that doesn't make it true. Binding the two font systems together is the only way to make things behave sanely. Since CSS is the new and "preferred" way, it makes sense to make the scale used by the FONT tag dependent on the scale used in CSS. Oh, but go ahead and continue to blame it on "user error" if that makes you feel better. WTFever.
Comment 25•21 years ago
|
||
I imagine that would be likely to break major sites. For example, it would break http://www.apple.com/. Also, since it is possible to construct a DOM where the BODY element is contained within a <FONT> element, your definition could lead to an infinite loop.
Comment 26•21 years ago
|
||
Not to mention that you can have content outside a <body> element.... (but inside <html>, say).
Reporter | ||
Comment 27•21 years ago
|
||
Ok then, you tell *me* how you're gonna fix it...
Comment 28•21 years ago
|
||
Personally I don't think it's broken -- we are acting exactly like Netscape 4.x did and IE6 does, which is what counts as far as <font> goes. In other words, it is broken-as-designed. Hence this bug's resolution.
Comment 29•21 years ago
|
||
If it were to be "fixed", the reverse of the comment #22 request might be made a user option via a pref: - always make the page's css body font size rule equal 100% of my font size preference
You need to log in
before you can comment on or make changes to this bug.
Description
•