37831 - bad font display, ignoring styles, ignoring cascade rules

Status: VERIFIED INVALID

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

Description

[Stanton McCandlish]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 4.5; Mac_PowerPC)
BuildID:    2000041805 (M15)

Mozilla seems to be entirely ignoring font sizing information, and selectively 
ignoring font color and typeface information (not always both at the same time), 
when these things are defined by stylesheets. It also seems to be violating the 
cascade ordering rules.

Reproducible: Always
Steps to Reproduce:
Load the URL above.  Feel free to grab and play with the code, including the 
stylesheet:
http://www.eff.org/effstyle.css

If you have a malevolent browser that refuses to display the content of this 
file (you should at least be able to download it, though) you can use this 
symlink:

http://www.eff.org/effstyle.css.txt

Actual Results:  Incorrect display of fonts sizes (in all cases), colors (in 
some cases) and typefaces (in some cases).

Expected Results:  Correct display of fonts in all aspects, as per stylesheet.

Netscape Communicator does not have this problem (as of 4.7).  I have no idea 
whether this problem in Mozilla is Mac-specific or not. I am using an external 
style sheet, and inline STYLE definitions, so I'm also assuming a inline 
stylesheet in the HEAD wuld exhibit the same problems.

Compare the above URL in Mozilla and, say, IE (I'm doing this on a Mac; can't 
guarantee the results on any other platform.)  The text in the right-hand 
sidebar should be the same as the text in the "EFF Mission" area (and in fact is 
very explicitly defined as such with a <SPAN CLASS="BODYCOPY">...</SPAN> despite 
this being the doc-wide default anyway!  Mozilla's essentially ignoring this 
style infomration *twice* and displaying the text in the default browser font 
(some serif font or another.)  Worse yet, it appears to be ignoring all font 
size-related style information.  The fonts I'm using (I'm the author of the page 
and stylesheet in question) are defined in specific point sizes, yet to no 
effect in Mozilla.  A glaring example is the huge "Subscribe to EFFector 
Newsletter" text, which is more than twice as big as it should be.  I suspect 
there may be two bugs here - 1) ignoring CSS1 font size information generally, 
and 2) ignoring all font (all style?) information, period, in certain contexts 
that I can't quite determine.

The first problem, of font sizes being ignored is general to the entire page 
(and subsequent subpages).

The second problem manifests as the serif font in the right-hand sidebar, in the 
"EFF's Hot Topics" and "EFF's Affilitations" material at the bottom of the 
central content area, again in the form text ("Search", "Browse", 
"Subscribe...")  A startling and hideous but widely different example can be 
found at any of a number of subpages.  Try http://www.eff.org/contact.html 
(compare in multiple browsers). Huge ol' lumbering black H1 & H3 text, ignoring 
both font size (like everything else) and color, while somehow getting the 
typeface correct.

A curious comparison can be made on this and other pages.  Have a look at the 
link below the EFFector form in the left-hand menu. It is definitely mis-styled.  
Yet most of the links elsewhere are correctly styled, suggesting that 'Zilla is 
getting at least the font *color* right, but only on links (not surprising - 
that information is defined elsewhere in the stylesheet.)  

Here's another surprise.  The right-side sidebar's heading text IS properly 
styled on this page and in some other places:
http://www.eff.org/buildin.html
(other than that, like ALL the text on all of these pages, it is too large, in 
violation of the specif point sizes I gave them. But *relative* to the other, 
over-sized, text it is "correct", and in the right typeface, and correctly 
colored.)

But, one thing that definitely did not work (see "EFF's Mission" area, middle of 
http://www.eff.org) is over-riding <A...> link colors with <A HREF...><SPAN 
CLASS...>text here</SPAN></A>.  That's definitely a violation of the cascading 
rules.  If I use that span to tell it to make the text green then by jolly, it 
oughta be green, no matter how <A...>'s are defined in the site-wide style 
sheet.

PS: The problem is NOT caused by an invalid HTML-infes

Comment 1

[Stanton McCandlish]

*** Bug 37818 has been marked as a duplicate of this bug. ***

Comment 2

[Stanton McCandlish]

Final line was truncated for some reason. Should have read:
"invalid HTML-infested .css file"

Comment 3

[Pierre Saslawsky]

In the first URL (http://www.eff.org/), the display of right-hand sidebar is 
consistent between Nav4x (Mac + Win) and Mozilla. I can't say whether it's right 
and I acknowledge that it is different from IE.

In the second URL (http://www.eff.org/contact.html), the display is obviously 
different between Moz and the other browsers (Nav + IE). I'm going to investigate 
that page first because the code is simpler.

In both URLs, the "Subscribe to EFFector Newsletter" text is wrong in Moz. I'm 
going to look into that one too.

Comment 4

[Pierre Saslawsky]

In the second URL, the font size is correct for a resolution of 96 dpi (try it 
with MacIE5) and the colors are wrong because the code is invalid: the headers 
use the "NAV" and "DOL" classes but the style defines "nav" and "dol". Per 
HTML4.0, IDs and CLASSEs are case-sensitive. See bug 35522 for more info. I'm 
afraid we'll have to reopen that bug (it's currently LATERed) and implement the 
quirk. I'm going to attach some simplified html and css files.

Comment 5

[Pierre Saslawsky]

Attachment: simplified eff/contact.html

Comment 6

[Pierre Saslawsky]

Attachment: simplified effstyle.css for eff/contact.html

Comment 7

[Pierre Saslawsky]

The problem with "Subscribe to EFFector Newsletter" can be divided in 2 parts:
1) As described above, we have a case-sensitivity problem with the "SM" class. 
That's another instance of bug 35522.
2) We have a table inheritance problem related to a NavQuirk as described in
bug 31955. I'm going to attach a tescase (I already put it under 31955).

Comment 8

[Pierre Saslawsky]

Attachment: testcase showing table inheritance problems (bug 31955)

Comment 9

[Pierre Saslawsky]

The problem with the right-hand sidebar is coming from bug 37872 or
bug 37876 (can't switch to strict mode). I'm going to attach a simplified 
testcase that used to work in M15 provided the doc type is 'strict.dtd'.

Comment 10

[Pierre Saslawsky]

Attachment: testcase for the right-hand sidebar

Comment 11

[Pierre Saslawsky]

As a summary, all the problems described here are either invalid or duplicates of 
other bugs.
1) Tables don't inherit the font family and font size. These problems are 
duplicates: they go away if we change the "frameset.dtd" to a "strict.dtd" (bug 
37872) and use an older build like M15 (bug 37876).
2) The code is invalid: some classes are declared in lower-case in the css file 
and used in upper-case in the html file. Unlike what I wrote earlier, we can't 
fix it with a NavQuirk because the document has a "HTML 4.01" DTD and should 
consequently follow the HTML specifications at
<http://www.w3.org/TR/html4/struct/global.html#adef-id>.  Still, I'm going to 
reopen bug 35522 because, had the page been without particular DTD, it would have 
been another compelling case to implement the quirk.

Closed as invalid.

<[e-mail]> (or your webmaster) - please fix the CLASS declarations or change 
the doc type to 'transitional'.

Comment 12

[Stanton McCandlish]

>the colors are wrong because the code is invalid: the headers 
>use the "NAV" and "DOL" classes but the style defines "nav" and 
>"dol". Per HTML4.0, IDs and CLASSEs are case-sensitive.

Wow. I feel like an utter moron.  Many apologies.  I don't know how I 
missed the case-sensitivity of classes.  Jeez. <banging head on desk>

(PS: My final comment in my original bug report was supposed to read:
"PS: The problem is NOT caused by an invalid HTML-infested .css file."
I don't know why Bugzilla keeps cutting off my text. It's happened on nearly 
every bug report I've made. 

Comment 13

[Christine Hoffman]

Adding 'verifyme' keyword

Comment 14

[Hixie (not reading bugmail)]

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...

Comment 15

[Hixie (not reading bugmail)]

rsVERIFIED