font-size: using <absolute-size> and <length> affect the layout differently (for same computed font-size)




17 years ago
17 years ago


(Reporter: jean.lagarde, Assigned: dbaron)


Windows 98

Firefox Tracking Flags

(Not tracked)



(1 attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20010913
BuildID:    2001091303

The included HTML is pretty obvious at demonstrating the behavior. The HTML used
to produce the two tables is identical, except for the STYLE="font-size:" of the
textarea. One uses "font-size:large" and the other "font-size:10pt". In one
case, the two elements (textarea and button) stay on the same line in the cell,
and in the other case, they do not. The issue does not seem to be with what the
actual computed font size ends up being -- I have tried values from small to
x-large for the absolute-size, both smaller and larger than 10pt in my browser,
and the different behavior remains. This only happens in a table cell.

I have no insight into the internals of Mozilla, and if this is more of a style
system issue or more of a layout issue, but this behavior is clearly wrong: The
way one expresses the font size should not affect the layout in this way. I am
also not sure what the correct layout should be (I am guessing the one with no
line break, as it does outside of the table), but at least, both cases should
give the same layout.

Reproducible: Always
Steps to Reproduce:
1.Display the HTML page included below
2.You're done

Actual Results:  The layout is different for the two tables (textarea and button
on same line versus on different lines).

Expected Results:  The layout should be the same; I think both elements should
remain on the same line.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"

<title>Strange side effect of font-size:xxpt</title>

<H4>With "font-size:small" for the textarea, the textarea and button are on the
same line</H4>
<table border=1><TR><TD>
<TEXTAREA NAME=test1 ROWS=3 COLS=10 STYLE="font-size:large">

<H4>With "font-size:10pt" for the textarea, a carriage return is inserted
between the two elements!</H4>
<table border=1><TR><TD>
<TEXTAREA NAME=test2 ROWS=3 COLS=10 STYLE="font-size:10pt">

I don't see this on Linux.  I'll check on Windows later.  Could this be some
sort of rounding problem?  What happens if, instead of 12pt, you try 15.5px,
15.6px, 15.7px, 15.8px, 15.9px, 16.0px, ..., 16.5px?  Which ones cause the problem?

Comment 2

17 years ago
Sorry, don't have Linux handy here. Good point about trying different font
sizes, and it does make a difference, so maybe this belongs more to the layout

In the example page I provided, the problem occurs for me with 10pt (the
original value), and 10.1pt, then no problem from 10.2 to 10.5pt, then it shows
up again between 10.6 and 10.8, and disappears at 11pt. I played a bit near
10.1pt, and down to two decimals, the problem disappears at 10.18pt. I am
guessing that the problem is in computing the size of the table cell, because I
now notice that even when the button wraps to the next line, the table cell
still looks just wide enough for it -- it probably is too small by some rounding
error, as you suggested. At least, this is now less myterious than it first
appeared to me, but still a bug.

Comment 3

17 years ago
I've looked at other builds and platforms at home:

- Win2K, build 20010628: no problem
- Win2K, build 20010913: same problem as described for the same build on win98
- Linux, builds 20010804 and 20010913: no problem

So only the one build on windows seems to have the problem. Linux is OK.
Created attachment 54375 [details]
Testcase as attachment, edited for HTML 4 compliance
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5+) Gecko/20011019

Even before I edited the testcase, I still did not see this bug.  I reformatted
it and validated it for HTML 4 compliance (W3C validates it as XHTML as well),
and I still don't see this bug.

Comment 6

17 years ago
Sure enough, no problem in win98 when using the test case against 0.9.5 (build
20011011), but I reinstalled 0.9.4 just to be sure, and your test case does
display the problem in that build. So problem solved, I guess (but I wouldn't
mind if you tried it with 0.9.4 anyway, just to confirm I'm not crazy -- you
might have to play with the exact font size to make it happen (see next para)). 

By the way, given my comment of 2001-10-04, this bug is currently mistitled (my
mistake): The problem was not due to a difference between <absolute-size> and
<length>, but rather to the exact font size (e.g. the problem occured at 10.1pt,
but not at 10.2pt). Not sure what the protocol for changing bug titles is, so
I'll leave that to someone else.
resolving worksforme per last comment from reporter...
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.