font-size: using <absolute-size> and <length> affect the layout differently (for same computed font-size)
RESOLVED
WORKSFORME
Status
()
People
(Reporter: jean.lagarde, Assigned: dbaron)
Tracking
Firefox Tracking Flags
(Not tracked)
Details
Attachments
(1 attachment)
|
721 bytes,
text/html
|
Details |
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" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <title>Strange side effect of font-size:xxpt</title> </head> <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"> </TEXTAREA> <BUTTON>></BUTTON> </table></TD></TR> <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"> </TEXTAREA> <BUTTON>></BUTTON> </table></TD></TR> </body> </html>
|
(Assignee) | |
Comment 1•17 years ago
|
||
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?
|
(Reporter) | |
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 component. 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.
|
|
(Reporter) | |
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.
|
||
Comment 4•17 years ago
|
||
Created attachment 54375 [details]
Testcase as attachment, edited for HTML 4 compliance|
|
||
Comment 5•17 years ago
|
||
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.
|
|
(Reporter) | |
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.
|
||
Comment 7•17 years ago
|
||
resolving worksforme per last comment from reporter...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•