Closed
Bug 53663
Opened 24 years ago
Closed 21 years ago
position:absolute table's top/left 'auto' treated as 0 [ABS POS]
Categories
(Core :: Layout: Tables, defect, P2)
Core
Layout: Tables
Tracking
()
RESOLVED
FIXED
Future
People
(Reporter: jruderman, Unassigned)
References
()
Details
(Keywords: css2, testcase, Whiteboard: relnote-devel)
Attachments
(3 files)
246 bytes,
text/html
|
Details | |
288 bytes,
text/html
|
Details | |
677 bytes,
patch
|
Details | Diff | Splinter Review |
[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.
Reporter | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
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•24 years ago
|
||
Comment 4•24 years ago
|
||
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... RELEASE NOTE ITEM 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.
Assignee: pierre → attinasi
QA Contact: chrisd → py8ieh=bugzilla
Summary: position:absolute table without top,left treated as 0,0 → position:absolute table's top/left 'auto' treated as 0 [ABS POS]
Target Milestone: --- → Future
Comment 5•24 years ago
|
||
Accepting. Ian, you are probably correct about the root of the problem, but I'll have to look closer when we get a chance.
Status: NEW → ASSIGNED
Updated•24 years ago
|
Whiteboard: relnote-devel
Comment 6•24 years ago
|
||
Nominating nsbeta1 for goal of achieving cross-browser and backward compatibility.
Keywords: nsbeta1
Updated•23 years ago
|
QA Contact: ian → amar
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.)
status? DBaron: if the patch is wrong, what should be done in this case?
Comment 10•22 years ago
|
||
Reconfirmed using FizzillaCFM/2002071208. Setting All/All.
Attachment #53470 -
Flags: needs-work+
Comment 11•22 years ago
|
||
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 http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsHTMLReflowState.cpp#1031 and make there a special treatment if a outer-table frame is encountered.
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.
(But yes, making the code that looks at 'top' and 'left' know about outer-tables ought to fix the bug.)
Comment 14•22 years ago
|
||
*** Bug 188647 has been marked as a duplicate of this bug. ***
Comment 15•22 years ago
|
||
*** Bug 189257 has been marked as a duplicate of this bug. ***
Comment 16•22 years ago
|
||
Test case: http://www.hixie.ch/tests/adhoc/css/box/absolute/008.html
Comment 17•21 years ago
|
||
.
Assignee: attinasi → table
Status: ASSIGNED → NEW
Component: Style System → Layout: Tables
Priority: P3 → --
QA Contact: amar → madhur
Target Milestone: Future → ---
Updated•21 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Priority: P3 → P2
Comment 18•21 years ago
|
||
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... .
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...
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Actually, never mind about the z-ordering bug. The testcase requires scrolling...
Comment 21•21 years ago
|
||
*** Bug 220906 has been marked as a duplicate of this bug. ***
*** Bug 220906 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
•