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)

x86
Linux
defect
Not set
normal

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
Attached image small screenshot
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
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
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.
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"?
Attached file testcase (obsolete) —
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.
Attached file another testcase
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.
Attachment #120280 - Attachment is obsolete: true
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.
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?
> + 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".
No it's not, since <basefont> is rarely, if ever, used in practice.
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.)
(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.)
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.
<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.
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.
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?
Defining <font size=3> to mean "the font size of the body element" would be a
good start.
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. 
> 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.
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.
Not to mention that you can have content outside a <body> element.... (but
inside <html>, say).
Ok then, you tell *me* how you're gonna fix it...
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: