46983 - [REL POS] Relatively positioning an inline box inside a table cell wrongly affects cell dimensions

Status: RESOLVED FIXED

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

Description

[Matthias Kerkhoff]

From Bugzilla Helper:
User-Agent: Mozilla/4.74 [en] (WinNT; U)
BuildID:    2000072909

Images inside table cells which are (relative) positioned via a CSS style may 
lead to an increased row height of the table.

Reproducible: Always
Steps to Reproduce:
1. Create a page with an IMG inside a TD. Add some text to another TD
2. Move the IMG down by adding a CSS style like {position:relative; top:100px;}

Actual Results:  3. The table will behave as if the following CSS style has been 
used for the TD {padding-top:100px;}, ie. the row height will be increased as 
much is needed to keep the img inside the cells boundary.							

Expected Results:  My understanding of relative positioning is something like 
this:
Do initial layout -> Move relative positioned elements (w.o. changing the 
layout). I would expect that the tables row height should not change if I move 
the IMG via CSS (BTW. what may happen if the IMG is moved up?).							

Maybe I add a testcase tomorrow. No time left today.

Comment 1

[Matthias Kerkhoff]

Attachment: testcase

Comment 2

[Marc Attinasi]

Something has to go - denying beta3 nomination for absolute/relative positioning 
problems in tables.

Comment 3

[Jacob Kjome]

I'm no expert in CSS, but I think that tables are structural entities which are
meant to hold content inside them.  Bringing content that was inserted inside a
<td> within a table and making it move outside a table is kind of meaningless.
Why should it be in a table structure in the first place if it is not meant to
physically be there.  Personally, I think IE 5.5 renders this wrong by allowing
the relative position outside the table.  I think Mozilla does it correctly by
just extending the height of the table to keep it within there.

Maybe I'm on the above, but I think it is a misuse of table any way you look at
it.  Should things even be allowed to be relatively positioned within the table?

Enlighten me.


jake

Comment 4

[Hixie (not reading bugmail)]

According to CSS, yes, relatively positioning _anything_ is allowed. Don't
forget, CSS is not about structure, it's about presentation. The underlying
document should be purely structural, and the CSS should be presentational.
So what happens if you want to relatively position something that happens to
be in a table? Hence it is allowed.

Comment 5

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

Whatever you may think about CSS and tables, relative positioning should never 
affect ancestor elements.

Comment 6

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

And, BTW, this may be a dup of bug 4519.

Comment 7

[Jacob Kjome]

Ok, I'm convinced.  Mostly going on a gut feeling and the fact that this bug 
hadn't been commented on since early august and seemed like it needed a kick in 
the butt to get it fixed.  Like I said "I'm no expert in CSS".  I'll read a bit 
more of the spec before I make a statement like that again.  Sorry.  I am glad 
the bug is getting attention again, though.

Jake

Comment 8

[Keyser Sose]

*** Bug 64987 has been marked as a duplicate of this bug. ***

Comment 9

[Greg K.]

using FizzillaCFM/2002071208, the testcase works as expect IF the images are
changed to display: block using CSS. (See bug 22274). As such, I suggest this
bug be resolved WFM.

Comment 10

[Greg K.]

Attachment: Modified testcase with 'img { display: block; }' CSS rule

Comment 11

[Greg K.]

Setting All/All since first testcase behavior can be observed as originally
described using FizzillaCFM/2002071208.

Comment 12

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

No, this is a bug and should not be resolved as worksforme.

Comment 13

[Greg K.]

Ah, I think I get the point. The problem is that relatively positioning any
inline box inside a TD influences the table cell height. Using display: block is
merely a workaround.

I think this might be a better Summary.

Comment 14

[Greg K.]

Attachment: Improved testcase

Comment 15

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

See bug 172896 comment 11, which describes a fix for this bug.

Comment 16

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

This is fixed by my patch on bug 172896.

Comment 17

[rjones-bugzilla]

Attachment: two columns in a table that become an inline section. The cells then grow and shrink as the display attribute changes.

The code gives a table with columns that shrink and grow as they are changed. 
Surely they should stay the same?  The problem seems similar to bug 46983.

Comment 18

[rjones-bugzilla]

Steps to reproduce the problem in the above attachment.
1. Load the attachment.
2. Click near the top of the text and then near the bottom so there are two red
columns.
3. Repeatedly click either column and see it grow or shrink.

Tested in K-Meleon Version 0.7 Build 700 Compiled Thu Oct 31 00:54:24 2002

Comment 19

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

The previous two comments are not related to this bug.

Comment 20

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

Fixed by checkin of bug 172896.

Comment 21

[Jacob Kjome]

just wanted to note that the attachment in comment 17 crashes Phoenix (latest
nightly).  However, there are lots of crashers today and I'm not sure which of
these might match with this crasher.  I'll let someone else figure that out...or
I might check back and do it myself if I get the time.

Jake