Closed Bug 1289 Opened 21 years ago Closed 16 years ago

Absolutely positioning of table elements [ABS POS]


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






(Reporter: rh, Unassigned)




(Keywords: css2, qawanted, testcase, Whiteboard: [bae:20011119](py8ieh:recheck with wg that cells cannot be floated)[nsbeta3-])

In this document there is a table with an absolutely positioned table with
absolutely specified dimiensions. The table frame bottom edge is wrong. (works
fine in IE).
Summary: table frame extends too low → Abs. positioining of DIV in a table increases table height
Note to bug reporter: please do not submit bugs like this. Instead, narrow it
down to simple test case. Here is the simple test case for this bug:

It appears the absolutely positioned DIV inside the last cell is causing the
problem. This looks like malformed content, but I didn't see the DIV being
rendered anywhere. Source code is below.

Adding Steve to the cc: list becuase I'm not sure if this is a layout thing or a
tables thing.

      <TABLE border=1 cellSpacing=0
      style="LEFT: 74pt; POSITION: absolute; TOP: 128pt; WIDTH: 464pt">

        <TR style="HEIGHT: 17pt">
          <TD align=left style="WIDTH: 114pt" vAlign=top>
          <TD align=middle style="WIDTH: 116pt" vAlign=top>
          <TD align=middle style="WIDTH: 115pt" vAlign=top>
          <TD align=left style="WIDTH: 115pt" vAlign=top>
<DIV class=f4 style="LEFT: 533pt; POSITION: absolute; TOP:

Changing summary to reflect problem.
This is indeed malformed HTML. sorry for your trouble. (IE does seem to be
better at recovering from it though).
Setting all current Open/Normal to M4.
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Assignee: kipp → troy
troy: this is crashing in an assertion in the nsFrameList code because the
expected parent of the absolute item being appended != the actual parent. Maybe
the assertion is wrong? However, since I don't see any (obvious) code in
nsAreaFrame for reparenting the absolute children, I'm guessing its a frame
construction bug...
Assignee: troy → karnaze
Chris, the table related frame construction code seems to be doing the wrong
thing for absolutely positioned elements inside of tables which is why the
parent frame is wrong. Here's the stack trace for the assert:

NTDLL! 77f76148()
nsDebug::Assertion(const char * 0x00730a44, const char * 0x00730a30, const char
* 0x00730a04, int 343) line 140 + 13 bytes
nsFrameList::VerifyParent(nsIFrame * 0x01065620) line 343 + 34 bytes
nsFrame::AppendFrames(nsFrame * const 0x01065620, nsIPresContext & {...},
nsIPresShell & {...}, nsIAtom * 0x01084090 {"Absolute-list"}, nsIFrame *
0x0106ec50) line 260
nsBlockFrame::AppendFrames(nsBlockFrame * const 0x01065620, nsIPresContext &
{...}, nsIPresShell & {...}, nsIAtom * 0x01084090 {"Absolute-list"}, nsIFrame *
0x0106ec50) line 3287 + 25 bytes
nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x01059d10,
nsIPresContext * 0x010842b0, nsIContent * 0x0106686c, int 0) line 3150
StyleSetImpl::ContentAppended(StyleSetImpl * const 0x0105c120, nsIPresContext *
0x010842b0, nsIContent * 0x0106686c, int 0) line 739
PresShell::ContentAppended(PresShell * const 0x01059138, nsIDocument *
0x01086980, nsIContent * 0x0106686c, int 0) line 1605 + 33 bytes
nsDocument::ContentAppended(nsDocument * const 0x01086980, nsIContent *
0x0106686c, int 0) line 1242
nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x01086980, nsIContent *
0x0106686c, int 0) line 684
HTMLContentSink::WillInterrupt(HTMLContentSink * const 0x010863f0) line 1507
CNavDTD::WillInterruptParse(CNavDTD * const 0x01058d50) line 2719 + 27 bytes
nsParser::ResumeParse(nsIDTD * 0x00000000) line 766
nsParser::OnDataAvailable(nsParser * const 0x01086564, nsIURL * 0x01084610,
nsIInputStream * 0x01086d10, unsigned int 583) line 968 + 17 bytes
nsDocumentBindInfo::OnDataAvailable(nsDocumentBindInfo * const 0x01085b40,
nsIURL * 0x01084610, nsIInputStream * 0x01086d10, unsigned int 583) line 1783 +
24 bytes
OnDataAvailableProxyEvent::HandleEvent(OnDataAvailableProxyEvent * const
0x01084ab0) line 632
StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x01084ab4) line 471 + 12
PL_HandleEvent(PLEvent * 0x01084ab4) line 476 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00f9ebf0) line 437 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x6f6b009a, unsigned int 49436, unsigned int 0,
long 16378864) line 799 + 9 bytes
USER32! 77e71250()
I'm inserting some comments from Troy for future use.

The table code should behave the same as the other code (e.g., block). Sort of.

Assuming that the table itself isn't absolutely positioned (ignore that issue
for a second), then yes you should check if you have
children that are absolutely positioned and then give them a different parent
(the one passed in to the function) and return that
child back in the list of absolutely positioned children. Don't add it to your
list of flowed children, because it's being moved out
of the flow.

However (there's always a 'however'), you probably don't want to let people
absolutely position (or float) row groups, rows, or
cells; and certainly not col groups or cols. The CSS2 spec discourages this as
Moving to M8
CSS2 discourages this, but it *certainly* doesn't say you cannot do it. In fact,
it specifically says you can. (It also says you can float cells, but I have had
that revoked. The change should appear in a future errata). See section 17.5

I have created a self-explanatory test case for this:

[Note. The original URI is now a 404, so I have changed it to the test case.]
[dbaron: I have cced you on this bug, since you have done a lot with absolute
positioning and may be interested in how this develops.]
You can relatively position table elements, but you *CANNOT ABSOLUTELY POSITION
ANY TABLE ELEMENT*, because CSS2, section 9.7 ( ) says:

Otherwise, 'position' has the value 'absolute' or 'fixed', 'display' is set to
'block' and 'float' is set to 'none'.
(...sorry about splitting this comment.  NN4.x decided not to let me type in the
text box...)

Therefore, the position:absolute on any table-type element makes it a block,
which means it is handled according to the rules on implied table elements,
which then recreates the appropriate missing element in the structure.  So it's
not quite as messy as it seems.  Considering the current serious problems with
implied table elements, I'm going to mark this bug as depending on bug 2479.  I
don't think it's really worth trying to make sense of this until implied table
elements make sense.
Problem still occurs with the June 28th Build (1999062809)
Moving to M9.
David has convinced me that floating a table cell _does_ make sense. A floated
cell becomes a block box, and by CSS2's table creation rules, the block box is
assimilated into an anonymous cell. See CSS2 for the exact rules.
Target Milestone: M9 → M11
Target Milestone: M11 → M12
Moving to M12
QA Contact: petersen → chrisd
Summary: Abs. positioining of table elements → {css2} Absolutely positioning of table elements
Target Milestone: M12 → M14
mass move to m14.
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Changing [NOTESTCASENEEDED] code to new donttest keyword. Sorry for the spam!
Keywords: donttest
moving to M16.
Target Milestone: M14 → M16
Summary: {css2} Absolutely positioning of table elements → Absolutely positioning of table elements
I have changed the anonymous table construction code and have another local 
change that renders the following, but I'm not sure if it is correct. How should 
the following be rendered? Can the <div> be absolutely positioned even if it 
gets wraped in an anonymous table cell?

<ul style="display:table; border:1px solid black; padding:0px; 
           LEFT: 100px; POSITION: absolute; TOP: 150px; WIDTH: 200px">
 <li style="display:table-row; padding:2px">
 <li style="display:table-row; padding:0px">
  <DIV style="LEFT: 300px; POSITION: absolute; TOP: 100px">bar</DIV>
The DIV should be absolutely positioned relative to the UL element (which is its
containing block).  (Note that the UL element is not the anonymous table element
generated inside the UL element.)
Moving to M17.
Target Milestone: M16 → M17
Nom. nsbeta3. Recc. nsbeta3+. Want CSS2 positioning to work correctly; here it 
would be broken for DIVs within TABLEs if not fixed.
Keywords: nsbeta3
Encountered the following problem in M16 - is it related to this discussion?:

Unable to establish TABLE as a containing block with respect to which 
descendents may be positioned absolutely.

The following HTML (with or without style="position:relative" in either the 
TABLE or TD tags), will not cause the "absolute" DIV, or any other element, to 
be absolutely positioned with respect to the TABLE.

<TABLE style="position:relative">
  <DIV id="absolute" style="position:absolute; top:0; left:0">

Contents of DIV overwrite 'outer' text rather than 'inner', showing that the 
absolutely positioned DIV is positioned with respect to initial containing 
block rather than the TABLE.

As per meeting with ChrisD today, taking QA.
Keywords: donttesttestcase
QA Contact: chrisd → py8ieh=bugzilla
Whiteboard: (py8ieh:recheck with wg that cells cannot be floated)
Denying beta3 nomination for absolute positioning problems in tables.
Whiteboard: (py8ieh:recheck with wg that cells cannot be floated) → (py8ieh:recheck with wg that cells cannot be floated)[nsbeta3-]
Target Milestone: M17 → Future
this is probably my bug, not chris'
Assignee: karnaze → buster
Summary: Absolutely positioning of table elements → Absolutely positioning of table elements [ABS POS]
QA Contact: ian → amar
The comment Val Sharp mentioned above is bug 63895.
Build reassigning Buster's bugs to Marc.
Assignee: buster → attinasi
reducing priority
Priority: P2 → P4
Whiteboard: (py8ieh:recheck with wg that cells cannot be floated)[nsbeta3-] → [bae:20011119](py8ieh:recheck with wg that cells cannot be floated)[nsbeta3-]
Reconfirmed using FizzillaCFM/2002071208 to view testcase URL. Setting All/All.
OS: Windows NT → All
Hardware: PC → All
Component: Layout → Layout: Tables
Yes.  What does this bug really cover?  The comments mention a wide variety of
issues; the testcase does as well.  Is this a tracking bug?
attinasi will probably not work on those bugs :-(
Assignee: attinasi → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
I think this bug is actually now INVALID. Here's why:

1) The listed URL is now a 404.
2) As bz mentioned above in comment 33, the bug addresses multiple issues.
3) The reporter admitted that the original test HTML was malformed.
4) Angus submitted a test case, but didn't attach it as an actual testcase
attachment (maybe this wasn't possible in 1998?). This makes it difficult for QA
to confirm the problem.
5) The issue mentioned by Val Sharp is another bug, as stated by dbaron.

If somebody wishes to reopen this bug... actually you probably shouldn't.
Instead, file a new bug that has a clear summary stating the specific problem
and an attached testcase, and CC me if you want it confirmed.

Closed: 16 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.