Last Comment Bug 53663 - position:absolute table's top/left 'auto' treated as 0 [ABS POS]
: position:absolute table's top/left 'auto' treated as 0 [ABS POS]
: css2, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
P2 normal (vote)
: Future
Assigned To: layout.tables
: Madhur Bhatia
: 188647 189257 (view as bug list)
Depends on: 205790
Blocks: 10209 104166 112836 145572 208274 220906
  Show dependency treegraph
Reported: 2000-09-21 18:57 PDT by Jesse Ruderman
Modified: 2014-04-26 03:11 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (246 bytes, text/html)
2000-09-21 18:58 PDT, Jesse Ruderman
no flags Details
same testcase with cleaner HTML (288 bytes, text/html)
2000-09-28 10:51 PDT, Christine Hoffman
no flags Details
hack (677 bytes, patch)
2001-10-14 07:15 PDT, Bernd
no flags Details | Diff | Splinter Review

Description User image Jesse Ruderman 2000-09-21 18:57:44 PDT
[Split from bug 51037]

Netscape 4.75 and IE both 5.5 both ignore position:absolute when top and left 
aren't given, but Mozilla acts as if both were zero.  Including top:;left:; in 
the style string has the same result.

Moz 2000091808, Windows 98.
Comment 1 User image Jesse Ruderman 2000-09-21 18:58:05 PDT
Created attachment 15265 [details]
Comment 2 User image Christine Hoffman 2000-09-28 10:50:54 PDT
Attaching essentially the same testcase (just cleaned up HTML - content was in 
the HEAD in previous test).

Is this bug dependent or related ot #10209?
Comment 3 User image Christine Hoffman 2000-09-28 10:51:23 PDT
Created attachment 15725 [details]
same testcase with cleaner HTML
Comment 4 User image Hixie (not reading bugmail) 2000-10-02 16:29:04 PDT
ccing Buster, Karnaze, Pierre; Assigning to Marc; Taking QA; relnote, [ABS POS].

I twiddled the testcase, and the problem also occurs if you explicitly set
the 'top' and 'left' properties to 'auto'. The problem does _not_ occur if you
position, say, a <div>. I'm guessing this is something to do with the messed
up style contexts we have on table elements, but I'm probably totally wrong...

   Mozilla currently does not support the value 'auto' on the 'top' and
   'left' properties on tables. It incorrectly treats them as '0' instead. 
   As a work around, authors are encouraged to polute their markup by wrapping
   positioned <table> elements in a <div>, and positioning that, instead.
   For example, instead of: 
      <table style="position:absolute">  ...   </table>
   ...authors could use:
      <div style="position:absolute"><table>  ...   </table></div>
   This should have a similar effect.
Comment 5 User image Marc Attinasi 2000-10-02 17:13:30 PDT
Accepting. Ian, you are probably correct about the root of the problem, but I'll
have to look closer when we get a chance.
Comment 6 User image ekrock's old account (dead) 2001-02-23 18:12:27 PST
Nominating nsbeta1 for goal of achieving cross-browser and backward 
Comment 7 User image Bernd 2001-10-14 07:15:45 PDT
Created attachment 53470 [details] [diff] [review]
Comment 8 User image David Baron :dbaron: ⌚️UTC-8 2001-10-14 12:14:17 PDT
That's wrong -- it will break inheritance of 'auto' values and instead cause the
child's value to act like 'auto' rather than inheriting the computed value. 
(Admittedly, there's been some discussion in the working group over whether that
should work, but it does work for us.)
Comment 9 User image basic 2002-02-27 20:44:27 PST
status? DBaron: if the patch is wrong, what should be done in this case?
Comment 10 User image Greg K. 2002-07-13 14:39:01 PDT
Reconfirmed using FizzillaCFM/2002071208. Setting All/All.
Comment 11 User image Bernd 2002-07-15 07:37:06 PDT
there are two ways to fix the bug IMHO:
- remove the outer table frame and as a consequence the style attributes would
be retrieved for the table itself
- hack around at
 and make there a special treatment if a outer-table frame is encountered.
Comment 12 User image David Baron :dbaron: ⌚️UTC-8 2002-07-15 07:49:17 PDT
But this bug is only for 'top' and 'left' of auto.  The real problem seems to be
that 'inherit' isn't what you want in this case (for "inherit"-ance from table
to table-outer), since 'inherit' inherits computed values, but you want to
"inherit" the specified value.
Comment 13 User image David Baron :dbaron: ⌚️UTC-8 2002-07-15 07:50:07 PDT
(But yes, making the code that looks at 'top' and 'left' know about outer-tables
ought to fix the bug.)
Comment 14 User image Bernd 2003-01-11 04:40:45 PST
*** Bug 188647 has been marked as a duplicate of this bug. ***
Comment 15 User image Bernd 2003-01-15 21:47:10 PST
*** Bug 189257 has been marked as a duplicate of this bug. ***
Comment 16 User image Hixie (not reading bugmail) 2003-01-15 22:13:14 PST
Test case:
Comment 17 User image Boris Zbarsky [:bz] (still a bit busy) 2003-05-03 22:05:24 PDT
Comment 18 User image Chris "SoopahMan" Moschini 2003-07-01 13:45:08 PDT
Still does not work, Mozilla 1.4.

It sounds like the nature of this problem is that, Mozilla internally thinks of
a single Table Element as 2 elements, an outer frame and an inner, and the inner
dismisses the position settings (top, left, right, etc)?

Trying to get a handle on the C++ code linked to... .
Comment 19 User image David Baron :dbaron: ⌚️UTC-8 2003-11-24 13:13:46 PST
Fixed by checkin of bug 205790.

However, Ian's testcase still doesn't work because of a z-ordering bug that
should probably be filed if it isn't already...
Comment 20 User image David Baron :dbaron: ⌚️UTC-8 2003-11-24 13:22:06 PST
Actually, never mind about the z-ordering bug.  The testcase requires scrolling...
Comment 21 User image Ger Teunis 2003-11-25 15:12:18 PST
*** Bug 220906 has been marked as a duplicate of this bug. ***
Comment 22 User image David Baron :dbaron: ⌚️UTC-8 2003-11-25 23:31:06 PST
*** Bug 220906 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.