12737 - {css1} {compat} -moz-fixed should be compat mode only

Status: VERIFIED FIXED

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

Description

[Ian Graham]

Changing the font-family for the document 'body' erroneously
changes the font-family for code, tt, and pre elements (for
which the default font should be 'monospace').
This is illustrated in '
http://www.java.utoronto.ca/NS5-bugs/font-overload-problem.html
The seamonkey behavior is the same as that seen in Navigator 4,
but is still incorrect according to the CSS spec (if my interpretation
is correct).

OS: Windows 98 (release 2) on Dell XPS T450.

Comment 1

[Peter Linss]

This was done specifically for backward compatibility. For the record, the font
selected by 'monospace' is not affected. code, tt and pre all use '-moz-fixed'
to get the backward compatible behavior.

Comment 2

[Christine Hoffman]

Verified WONTFIX

Comment 3

[Hixie (not reading bugmail)]

This should _definitely_ be only a NavQuirks thing!

Reopening. See another test case here:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/mozfixed.html

Peter: Are we going to get NavQuirks vs Standard ua.css? You could implement
this using a custom at-rule, so you don't need two ua.css files:

   code,tt,pre { font: 1em monospace; }
   @-moz-quirks {
      code,tt,pre { font-family: -moz-fixed; }
   }

Or maybe now that we have sync @import for ua.css:
   @-moz-quirks-import url(quirks-ua.css);
...which only imports the relevant quirky bits when in Quirks mode.

There are other issues that need a Quirks ua.css -- see the file itself.

Comment 4

[Peter Linss]

I suppose it would be fair to disable some of the quirkiness in standard mode.
I *really* don't want to add any kind of "at quirk" rule handling.
Pierre, the best fix for this is to make the code which sets the font family
(nsHTMLFontElement::MapAttribtuesInto and
nsCSSStyleRule::MapFontDeclarationInto) only set the family of the fixed font in
quirk mode.

Comment 5

[Pierre Saslawsky]

Fixed. Note that if the document is not declared HTML 4.0 compliant, the 'code',
'pre' and 'tt' elements are still displayed using the normal font instead of the
fixed-width font.

When verifying this bug, you can see that the page on <www.java.utoronto.ca>
shows the same bug as in Navigator 4.0 while the page on <www.bath.ac.uk>
displays correctly because it has the HTML 4.0 header.

Comment 6

[Pierre Saslawsky]

Reopening: when there is no body element (as in Ian's testcase above), we
shouldn't do the quirk thing. Maybe it's more generic than that and the quirk
should be applied only if the parent doesn't have an inherited font.

Comment 7

[Hixie (not reading bugmail)]

pierre: Huh? We _don't_ do the quirk thing on my page. What's the problem?

Comment 8

[Pierre Saslawsky]

Sorry, I omitted some details from an email exchange we had with chrisd. We don't
do quirks with your page because it contains a strict DTD header but if we change
it to a transitional DTD, or if we simply remove it, we still do the quirks while
Navigator doesn't. Navigator does the quirk thing only if we set the font for the
body _and_ a <body> tag is present. Your page doesn't have a <body> tag.

Comment 9

[Pierre Saslawsky]

It becomes tricky: the quirk has to be applied for any element, except for the
body element when it is implicitely created by the parser in the case where the
<body> tag is missing. In other words, if you have a page which:
- doesn't have a strict DTD
- sets a font for the body element
- doesn't have a <body> tag
then we do the quirk while Nav4 doesn't.

We talked with Rick yesterday about a hack to know whether the body was
implicitely created but we were assuming that Nav4 was doing the quirk only for
the body element. It's not the case and since in the two places where the quirk
is applied - MapFontAttributesInto() and MapDeclarationFontInto() - we can't get
to the content, it means that we are stuck.

My opinion is that we should not do that quirk at all because:
- IE doesn't emulate it
- I can't think of a case where it could be relied upon to make things look
better in Navigator than in other browsers.

Comment 10

[Hixie (not reading bugmail)]

Yay! Yank the quirk altogether, please!

Comment 11

[Pierre Saslawsky]

Thanks for your support. The quirk is out.

Comment 12

[Christine Hoffman]

Using 11/23 build, verified fixed. Text for code, tt and pre elements is
'monospace' with strict or transitional DTD.

Comment 13

[Hixie (not reading bugmail)]

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...