Closed
Bug 582
Opened 27 years ago
Closed 26 years ago
{css1} Monospace font inside a serif div doesn't work
Categories
(Core :: CSS Parsing and Computation, defect, P2)
Tracking
()
VERIFIED
FIXED
M10
People
(Reporter: angus, Assigned: peterl-retired)
References
()
Details
(Keywords: css1)
Sample HTML:
<head>
<style type="text/css">
DIV.a {font-family: serif;}
.five {font-family: monospace;}
</style>
</head>
<body>
<div class="a">
I should be serif.
<P class="five">
I should be monospace.
</P>
</div>
</body>
Note if you replace "monospace" with "sans-serif," it works, so I think it has
something to do with the monospace font in particular.
Assignee | ||
Updated•27 years ago
|
Status: NEW → ASSIGNED
Component: Unknown → Style System
Assignee | ||
Comment 1•27 years ago
|
||
This is semi-intentional behavior. Currently, monospace is a "magic" font name
that means "act like pre". This was done for several reasons, so that we could
specify "pre" behavior in CSS, and so that CSS "monospace" will track user
fixed-pitch font choices and "pre" behavior... An explict setting of font-face
always overrides the fixed-pitch ("pre") font. We can either accept this
behavior, or extend CSS and change the "magic fixed" font to something like:
"fixed".
Reporter | ||
Comment 2•26 years ago
|
||
Adding Hakon to the CC list for his suggestions on this bug. Hakon - what are
your thoughts?
Why don't you just use CSS's way to encode PRE:
PRE { white-space: pre }
DIV.preformatted { white-space: pre }
This way, you can remove the magic of the "monospace" -- and conform to CSS!
Assignee | ||
Comment 4•26 years ago
|
||
We do use the white-space property to specify the whitespace behavior of PRE.
What is at issue here is the font face, not the whitespace behavior. A
white-space value of "pre" does not change the font face, it merely preserves
whitespace.
The PRE HTML tag has the following specification in the ua.css stylesheet:
PRE { white-space: pre; font-family: monospace; ... }
In HTML the following: <FONT face="times"><PRE>pre text</PRE></FONT> will result
in Times being used for the "pre text". An explicit setting of font face (via
HTML or CSS) overrides the font used by contained elements that would otherwise
get a monospace font. This is the behavior implemented by our "monospace" font
family.
Comment 5•26 years ago
|
||
This treatment of monospace has the additional effect that other fonts within a
monospace DIV are chosen in weird ways. In Windows, bitmapped fonts seem to be
chosen over True-Type fonts (I think.) See:
http://www.w3.org/Style/CSS/Test/current/sec522.htm‰
Assignee | ||
Comment 6•26 years ago
|
||
The only thing I see wrong with sec522.htm is that 'fantasy' is still mapped to
Arial. Care to suggest a font to use instead?
Updated•26 years ago
|
Comment 7•26 years ago
|
||
The "magic" of monospace has very weird effects. I put an image of NGLayout's
rendering of the above URL at
http://www.fas.harvard.edu/~dbaron/tests/nglayout/monosp.gif . Notice the
following problems:
1) "font-face: monospace, serif" causes a serif font.
2) The fonts are different in the top and the bottom of the page, this is
because a serif font within a monospace DIV is different from a serif font not
within a monospace DIV.
I'm not sure what this says about PRE, but I think PRE needs to be handled in a
special way, rather than a special handling of monospace.
Comment 8•26 years ago
|
||
Actually I think no special treatment is needed at all if the FONT attribute is
handled as defined in the CSS2 spec at
http://www.w3.org/TR/REC-CSS2/cascade.html#q12
I think this is the way FONT is handled by IE5.
I will submit a separate bug on this (this bug has gotten long enough), after
making a demo of what should happen.
Comment 9•26 years ago
|
||
I'm actually not submitting a separate bug, because this over-use of FONT
occurs only when the CSS inside it is font-family: monospace. This seems to
show that the magic behavior of monospace is needed only because of a bug in
the magic behaviour of monospace. This may explain why "font-family:
monospace, serif" yields a serif font.
I made a test case for treatment of mixed FONT and CSS at:
http://www.fas.harvard.edu/~dbaron/csstest/noncss.html
The FONT tag is given too much control when what is inside it is CSS with
"font-family: monospace", so that CSS on elements inside the font tag inherits
from the FONT FACE rather than using their own values. This would not happen
in CSS even if the FONT FACE were declared ! important. The above test case
explains what should (I think) happen. IE 5.0 beta 2 passes the above test
exactly as described, so compatibility is not an issue.
I think removal of *all* magic treatment of monospace should make PRE and these
other problems work as they should, now that white-space is implemented.
Comment 10•26 years ago
|
||
Your comment on 98-10-01 about PRE not changing a font specified using a font
tag is true for Netscape only. MSIE does change the font. See
http://www.fas.harvard.edu/~dbaron/csstest/noncss.html for an example. MSIE's
behavior is more sensible, easier to implement, and doesn't conflict with
correct implementation of CSS. And you won't be "destroying" bad pages out
there if you change it.
Comment 11•26 years ago
|
||
Setting all current Open/Normal to M4.
Assignee | ||
Updated•26 years ago
|
Target Milestone: M4 → M7
Updated•26 years ago
|
Summary: Monospace font inside a serif div doesn't work → {css1} Monospace font inside a serif div doesn't work
Comment 12•26 years ago
|
||
The code that's doing this seems to be at:
http://lxr.mozilla.org/seamonkey/source/layout/html/content/src/nsHTMLFontElement.cpp#222
and
http://lxr.mozilla.org/seamonkey/source/layout/html/style/src/nsCSSStyleRule.cpp#1218
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 13•26 years ago
|
||
PRE font compatibility now controlled by extension generic font name
'-moz-fixed'. 'Monospace' just selects courier now.
Updated•26 years ago
|
Status: RESOLVED → VERIFIED
Comment 14•26 years ago
|
||
Verified fixed (all tests checked). Remaining issues spun off into bug 8893.
Comment 15•25 years ago
|
||
Migrating from {css1} to css1 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
You need to log in
before you can comment on or make changes to this bug.
Description
•