Closed Bug 12737 Opened 20 years ago Closed 20 years ago

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

Categories

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

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: ian.graham, Assigned: pierre)

References

()

Details

(Keywords: css1)

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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → VERIFIED
Verified WONTFIX
Status: VERIFIED → REOPENED
Summary: CSS: Changing 'body' font-family affects elemenst that should have monospace fonts → {css1} {compat} -moz-fixed should be compat mode only
Resolution: WONTFIX → ---
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.
Assignee: peterl → pierre
Status: REOPENED → NEW
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.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Target Milestone: M11
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.
Whiteboard: 11/16: Verification pending clarification from assigned engineer
Status: RESOLVED → REOPENED
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.
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Whiteboard: 11/16: Verification pending clarification from assigned engineer
Target Milestone: M11 → M12
pierre: Huh? We _don't_ do the quirk thing on my page. What's the problem?
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.
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.
Yay! Yank the quirk altogether, please!
Status: ASSIGNED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Thanks for your support. The quirk is out.
Status: RESOLVED → VERIFIED
Using 11/23 build, verified fixed. Text for code, tt and pre elements is
'monospace' with strict or transitional DTD.
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.