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.