Closed
Bug 88035
Opened 24 years ago
Closed 21 years ago
[QUIRKS]Table wrapped in <center> or <div> miscalculates height=100%
Categories
(Core :: Layout: Tables, defect, P3)
Core
Layout: Tables
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: hume, Unassigned)
References
()
Details
(Whiteboard: (half implemented quirk) CANDIDATE_094)
If you wrap a table in a <center> tag, the definition of height=100% changes
meaning. Granted, <center>'ing a 100% x 100% table is unnecessary, but this is
different behavior from NS4 and IE.
My test case has two pages, one with the table wrapped in a center and the other
does not.
Comment 1•24 years ago
|
||
This is probably right for standards mode, but not for quirks mode.
The testcase seems unrelated to the bug description.
Maybe duplicate of bug 52073?
Reporter | ||
Comment 3•24 years ago
|
||
How do you mean unrelated?
The two webpages have identical tables, both specifying height=100%. The one
without the center tag calculates height as you'd expect. The second one, with
center, suddenly decides that height=100% means "as much below 100% as possible".
I didn't realize earlier that there were 2 URLs. In fact, I was about to
comment that having two table cells is quite different from having 2 separate
pages. There are two testcases for this bug:
http://den.bofh.halifax.ns.ca/~hume/moo/test1.html
http://den.bofh.halifax.ns.ca/~hume/moo/test2.html
The problem here is that we have a table height quirk that's half implemented.
According to CSS, neither height="100%" should work. But we have a hack to
ignore the CSS rules and go through a 'height: auto' BODY element, but not other
blocks. I'd rather see the hack work through all 'height: auto' blocks or not
exist at all...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: (half implemented quirk)
Comment 8•23 years ago
|
||
Adding "[QUIRKS]" to summary.
Summary: Table wrapped in <center> miscalculates height=100% → [QUIRKS]Table wrapped in <center> miscalculates height=100%
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.6
Comment 9•23 years ago
|
||
I think the <center> problem was fixed a while ago but there was still a problem
with extra cell spacing at the bottom. Meta bug 97138 fixes that.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: (half implemented quirk) → (half implemented quirk) CANDIDATE_094
Reporter | ||
Comment 10•23 years ago
|
||
Did you visit the demo URL?
It isn't fixed in a SPARC 2001110210 nightly.
Reporter | ||
Comment 11•23 years ago
|
||
OK, build was too old. I'll wait for a newer nightly.
Comment 12•23 years ago
|
||
build: 20020304 win2000
reopening - this is not fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 13•23 years ago
|
||
*** Bug 129012 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
Need to set a new target milestone. Adding <div> in summary.
Summary: [QUIRKS]Table wrapped in <center> miscalculates height=100% → [QUIRKS]Table wrapped in <center> or <div> miscalculates height=100%
Comment 15•23 years ago
|
||
the issue here is not that height="100%" is miscalculated, the issue is that
<center> does not have the same height as <body>, so unless the <center> or
<div> has a style="height: inherit;" or style="height: 100%" and it still does
not work, I don't think this is a valid bug. It will probably break other stuff
as it causes a height=100% to force a parent block element to have an implicit
"height: 100%;".
Comment 16•23 years ago
|
||
That's why its a Quirks bug and not a Standards bug.
Can we get a retarget? It seems to have been forgotten for both 0.9.4 and 0.9.6.
Keywords: mozilla1.0
Comment 18•23 years ago
|
||
I'm wondering if this quirks is really worth it. Are we sure that implementing
this will quirk not cause problems? It seems to me that this changes the whole
meaning of style="height: auto;" when any of the child boxes have style="height:
100%;". What about when a child box have style="height: 50%;" ? Is this a
<table> only thing?
Comment 19•23 years ago
|
||
*** Bug 158348 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 20•22 years ago
|
||
mass reassign to default owner
Assignee: karnaze → table
Status: REOPENED → NEW
Component: Layout → Layout: Tables
QA Contact: petersen → madhur
Target Milestone: Future → ---
Updated•22 years ago
|
Target Milestone: --- → Future
Comment 21•22 years ago
|
||
*** Bug 202635 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
*** Bug 206083 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
This also occurs when a table is wrapped inside a <form> tag. When using ASP.NET
it is very common to find pages where all of the elements are wrapped inside an
enclosing form tag.
Very simple test case:
<html>
<body>
<form>
<table height=100%>
<tr><td>This should be at the top of the browser window</td></tr>
<tr><td>This should be in the middle of the browser window</td>
<tr><td>This should be at the bottom of the browser window</td>"
</table>
</form>
</body>
Comment 24•22 years ago
|
||
Sorry, that test case should have been:
<html>
<body>
<form>
<table height=100%>
<tr><td>This should be at the top of the browser window</td></tr>
<tr height=100%><td>This should be in the middle of the browser window</td>
<tr><td>This should be at the bottom of the browser window</td>"
</table>
</form>
</body>
</html>
![]() |
||
Comment 25•21 years ago
|
||
Fixed by bug 222730
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
![]() |
||
Comment 26•21 years ago
|
||
*** Bug 222981 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 27•21 years ago
|
||
*** Bug 219931 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 28•21 years ago
|
||
*** Bug 233476 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 29•21 years ago
|
||
*** Bug 196681 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 30•21 years ago
|
||
*** Bug 161583 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 31•21 years ago
|
||
*** Bug 199255 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 32•21 years ago
|
||
*** Bug 176346 has been marked as a duplicate of this bug. ***
![]() |
||
Comment 33•21 years ago
|
||
*** Bug 85516 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•