26935 - font substitution on Mozilla causing netscape.com to lay out differently

Status: VERIFIED DUPLICATE of bug 21950

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

Description

[ekrock's old account (dead)]

To see problem, view above URL in both Nav4.7 and Commercial 2/7 build on WinNT 
4.0 SP4. Compare the gray header at the top right of the page. The calculated 
line height is larger in Mozilla due to the same backward compatibility vs. CSS 
box model issue as in bug #24186.

buster has applied a patch (thanks, buster!!!) for bug #24186 that fixes the 
problem in Nav Quirks mode for block level elements (display: block) such as P, 
but this patch is not invoked for table elements such as TD (display: 
table-cell).

The reason we may want to examine the feasibility of a similar patch for table 
elements for beta1 is that major portals and content home pages use tables 
extensively (in fact, almost exclusively) for positioning text on their home 
pages. So the current patch for bug #24186 appears not to be helping on the 
pages viewed most frequently by users.

Note: If you view the markup, you'll discover that the page has incorrect 
nesting of FONT and A tags: <FONT><A></FONT></A>. However, fixing it has no 
effect on display as we're probably already handling this through residual 
style.

Will attach screen shots and simplified test case and mark beta1 keyword. (I 
recognize that due to the complexity of the table layout code, a fix may not be 
possible for beta1, but that's a call for the PDT team to make after we get an 
estimate of the actual difficulty of doing a patch similar to #24186.)

Comment 1

[ekrock's old account (dead)]

Attachment: simplified test case (with tag nesting fixed)

Comment 2

[ekrock's old account (dead)]

Attachment: screen shot of original Netscape header viewed in Nav4

Comment 3

[ekrock's old account (dead)]

Attachment: screen shot of original Netscape header viewed in 2/7 Commercial

Comment 4

[karnaze (gone)]

The block code is going to need to be modified to make the 1st attachment work 
like Nav4.x. The table code does not handle the tags (e.g. <FONT>) inside the 
<TD>. They are handled by the block code. It may be the case that Steve's patch 
will fix this problem. Right now it looks like the fonts around the <A>s are too 
big (compared to Nav4.x). Reassigning to Steve.

Comment 5

[buster]

Eric:  I think you not seeing what you think you are seeing.  I believe the 
quirks mode work around I put in place should work just fine inside a table.  
Table cells display their content by including a block frame as their 
one-and-only child, and the block frame is oblivious to the fact that it is 
inside a table.
I think what you are really seeing here is the font used by mozilla is 
significantly larger than the font used by Nav.  This is an issue Erik van der 
Pool has been working on, totally independent of the line height quirks issue.
I'm 80% sure of what I just said :) If I can get a build today, I'll confirm it. 

Comment 6

[ekrock's old account (dead)]

Steve's probably right. I did notice last night that the characters being 
displayed looked slightly different (like a different font) and also appeared 
slightly larger (for example, wider from left to right) than what was displayed 
in Nav4. 

erik, is this a DUP of a bug you have open already? I couldn't see any in your 
list that looked like this. And what are the prospects for fixing by beta1?

Changing bug Summary from "NavQuirks mode needs to apply "line height patch" to 
table elements (not just block level)" to "font substitution on Mozilla causing 
netscape.com to lay out differently." Reassigning to erik. Changing component to  
"Style System". cc:ing pierre and troy.

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Could the problem here be related to the rounding bug in Nav4 (which was a bad
thing and should not be maintained)?  What does this look like in IE5?

Comment 8

[ekrock's old account (dead)]

Attaching a screen shot that shows, from left to right, the same area of 
Netscape.com displayed in IE 5.5 b1, Nav4.7+, and Seamonkey Commercial 2/7.

To my eyes, IE 5.5 and Nav4 are displaying the same font at the same size. Only 
Seamonkey looks different.

Comment 9

[ekrock's old account (dead)]

Attachment: netscape.com left-to-right in IE5.5b1, Nav4.7+, and Sea 2/7 Commercial--all on WinNT 4.0 SP4

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do you see the same thing on attachment 5055 [details] (above)?  It looks from the
screenshot of netscape.com that both the font size and the line height are
different, although it's hard to tell.

Comment 11

[Hixie (not reading bugmail)]

There is another problem on that page which is probably also causing you to
think that the fix for bug 24816 didn't work for tables -- bug 24816 doesn't
solve the case of <font>...</font><br><font>...</font> (note the <br>).

This is now bug 26996.

Comment 12

[Hixie (not reading bugmail)]

[Oops. Unzapping the changes ekrock made amd which I overwrote.]

Comment 13

[Hixie (not reading bugmail)]

david: yes. I'll attach a screenshot with some parts of the text in IE5.0 and
Gecko 2000020808 zoomed in.

Comment 14

[Hixie (not reading bugmail)]

Attachment: Screenshot of attachement 5055 in IE5 and Gecko.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Most of the problem with this bug is bug 26996 (and probably also bug 26998). 
However, there is also the question of why the font size is bigger in Gecko.

Comment 16

[Hixie (not reading bugmail)]

Is this font-size issue actually bug 21950? Or maybe bug 13072?

Comment 17

[Erik van der Poel]

OK, I've looked into it, and here's my current status: When font sizes are
specified explicitly, e.g. 9px, 10px, etc, then MSIE and Seamonkey give the
same results. When font sizes are specified as <font size="1">, then Seamonkey
gives larger fonts than both MSIE and Nav4. My tentative conclusion is that
MSIE and Nav4 are using different values for HTML font sizes 1-7. Seamonkey is
using the same multipliers for 1-7 as Nav4. That code was lifted directly from
Nav4. So we may need to make our 1-7 match MSIE's (since they're the market
leader now). That way, both our explicit sizes (e.g. 9px) and our HTML sizes
(1-7) will look OK in today's market, no? Comments, please.

Comment 18

[Erik van der Poel]

I have a number of critical PDT+ bugs for M14, so I'd like some help with this
one. Pierre, do you have some spare cycles? We need to change our HTML sizes
1-7 to match MSIE's multipliers. I.e. size 1 might be 0.6 x size 3, but we need
to change it to 0.55 or whatever. This will take some experimentation or maybe
even asking MS or someone on the Net whether they happen to know MSIE's
multipliers.

Comment 19

[leger]

Need more info for PDT+ or PDT- decision.  ekrock came to PDT and will work on 
getting us info.  Need to know what is needed minimally for beta1.

Comment 20

[ekrock's old account (dead)]

OK, so here's the situation as I understand it:

0) Although PDT as a whole didn't take a final position, the consensus seemed to 
be that the current problem of <FONT SIZE="1> being "too big" (this bug, 26935) 
is a beta1-caliber issue. The question is how we fix that.

1) Erik is arguing that we should leave out the already-removed Nav4 rounding 
code to keep fixed the bug that Nav4 [and Mozilla if it's compatible] can't 
readably display <FONT SIZE="8px"> and <FONT SIZE="9px">, and then modify the 
scaling factors so that <FONT SIZE="1>, etc. will display 
backwardly-compatibly with Nav4 and IE.

2) Rick (in the PDT meeting) argued that he'd prefer to put the old Nav4 
rounding code back in Mozilla, accepting that <FONT SIZE="8px"> and <FONT 
SIZE="9px"> will be unreadable. His concerns seemed to be (i) the risk of 
complications stemming from changing the scaling factors, and (ii setting a 
precedent of changing the code to be IE-compatible rather than Nav4 
backwardly-compatible.

3) My position FYI: *If* we can modify the scaling factors to solve the current 
very widespread <FONT SIZE="1> bug with reasonable effort and without causing 
new bugs, I'd prefer to do so (option 1). If possible, in this particular case, 
I'd prefer to be cross-browser compatible with IE (and fix what was a known bug 
in Nav4) than to be backwardly compatible with a Nav4 bug. However, I'm aware of 
the possibilities that:

a) changing those scaling factors may be too risky, or that
b) we may not have the resources to do the needed calculations at this time.

Rick, Erik, and I have been asked to conference about this by phone tomorrow, 
evaluate issues a and b, and decide what our joint recommendation is. All input 
welcome.

Comment 21

[Pierre Saslawsky]

Per Erik's comments on 2000-02-08 15:11, I'm closing this as dup of bug 21950.


*** This bug has been marked as a duplicate of 21950 ***

Comment 22

[Christine Hoffman]

Verified dup of #21950 per comments