Closed Bug 88035 Opened 23 years ago Closed 21 years ago

[QUIRKS]Table wrapped in <center> or <div> miscalculates height=100%

Categories

(Core :: Layout: Tables, defect, P3)

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: hume, Unassigned)

References

(
URL
)

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.
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?
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)
Same happens to me when table is wrapped inside <div></div>
*** Bug 96581 has been marked as a duplicate of this bug. ***
Blocks: 97138
Adding "[QUIRKS]" to summary.
Summary: Table wrapped in <center> miscalculates height=100% → [QUIRKS]Table wrapped in <center> miscalculates height=100%
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.6
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
Did you visit the demo URL?

It isn't fixed in a SPARC 2001110210 nightly.
OK, build was too old.  I'll wait for a newer nightly.
build: 20020304 win2000
reopening - this is not fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
*** Bug 129012 has been marked as a duplicate of this bug. ***
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%
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%;".
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
Resetting target milestone.
Target Milestone: mozilla0.9.6 → ---
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?

*** Bug 158348 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
mass reassign to default owner
Assignee: karnaze → table
Status: REOPENED → NEW
Component: Layout → Layout: Tables
QA Contact: petersen → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
*** Bug 202635 has been marked as a duplicate of this bug. ***
*** Bug 206083 has been marked as a duplicate of this bug. ***
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>

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>
Depends on: 222730
Fixed by bug 222730
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → FIXED
*** Bug 222981 has been marked as a duplicate of this bug. ***
*** Bug 219931 has been marked as a duplicate of this bug. ***
*** Bug 233476 has been marked as a duplicate of this bug. ***
*** Bug 196681 has been marked as a duplicate of this bug. ***
*** Bug 161583 has been marked as a duplicate of this bug. ***
*** Bug 199255 has been marked as a duplicate of this bug. ***
*** Bug 176346 has been marked as a duplicate of this bug. ***
*** 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.