Closed Bug 582 Opened 26 years ago Closed 25 years ago

{css1} Monospace font inside a serif div doesn't work

Categories

(Core :: CSS Parsing and Computation, defect, P2)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Windows 95
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: angus, Assigned: peterl-retired)

References

(
URL
)

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.
Status: NEW → ASSIGNED
Component: Unknown → Style System
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".
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!
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.
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&#137;
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?
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.
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.
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.
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.
Setting all current Open/Normal to M4.
Target Milestone: M4 → M7
Summary: Monospace font inside a serif div doesn't work → {css1} Monospace font inside a serif div doesn't work
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
PRE font compatibility now controlled by extension generic font name '-moz-fixed'. 'Monospace' just selects courier now.
Status: RESOLVED → VERIFIED
Verified fixed (all tests checked). Remaining issues spun off into bug 8893.
Keywords: css1
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.