cannot position tr/td/th

RESOLVED FIXED in mozilla1.5alpha

Status

()

Core
Layout: Tables
P3
normal
RESOLVED FIXED
16 years ago
12 years ago

People

(Reporter: tapio.markula, Assigned: dbaron)

Tracking

Trunk
mozilla1.5alpha
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
Mozilla doesnt' apply  'position' for table elements, which are descendants of the element 'TABLE' ('th', 'td' etc.).

I have discussed that with Boris Zbarsky, when I send shew a test page:
http://www.nic.fi/~tapio1/Tests/MacTest1.html

Mozilla doesn't position two 'td' elements on the main menu of the dynamic menu. They remain about 20px too high.


>Yeah, that's a bug (our table construction 
>code looks at "display" but not "position" (and I never cease to wonder 
>why the hell those are separate properties)). 

I partial disagree an agree with that opinion. It is possible to handle both 'position' and 'display' for table elements. If table cells, rows etc. have been positioned, the question is, how to handle the structure of the non-positioned elements in the table:
a) Should positioned handle as if they have 'display:none' if positioned elements have the values 'absolute' or 'fixed' ? Then taking cells off the table would broke the table structure.
b) Should positioned cells handle as if they have would have properties 'empty-cells:hide; height:0; width:0;' (<td style="empty-cells:hide;  height:0; width:0;"></td>)? Then taking of cells from table doesn't broke the table structure, but positioned element are that mean out of the normal flow that width and height values don't affect anything to the width and height values on non-positioned elements if positioned elements have the values 'absolute' or 'fixed'.

I agree that in the table section should be rules, how to handle positioned table elements like the table section define rule for 'visibility:hidden'. Concerning table 'position' should not be totally independent property, when it has been applied for table elements. The latter alternative is in my mind reasonable. It would be consistent with the handling of 'visibility:hidden'.

>File a bug.  Do _not_ use that page as the testcase. 
>Use a clear testcase like:
>
><html>
><body>
><table>
>   <tr>
>     <td>
>       This text should overlap
>     </td>
>   </tr>
>   <tr>
>     <td style="position:absolute; top: 1px">
>       This text should overlap
>     </td>
>   </tr>
></table>
></body>
></html>
(Reporter)

Comment 1

16 years ago
Created attachment 103500 [details]
show the problem
Created attachment 103501 [details]
The testcase

tapio, how hard is it to attach a testcase I _mailed_ you??
Attachment #103500 - Attachment is obsolete: true
Tha basic issue is that table element processing in nsCSSFrameConstructor never
looks at the position; only at the display (unlike the normal
ConstructFrameInternal() code).
Assignee: attinasi → karnaze
Status: UNCONFIRMED → NEW
Component: Layout → HTMLTables
Ever confirmed: true
OS: Windows 98 → All
QA Contact: petersen → amar
Hardware: PC → All

Comment 4

16 years ago
I believe this is dupe of bug 10209. We have tons of pos bug against tables.
Boris why do you confirm instead of duping it away?
(Assignee)

Comment 5

16 years ago
This is for internal table elements, not tables.  (And yes, positionining should
work, and cause anonymous table boxes to be created.)
resummarizing to unconfuse bernd
Summary: position doesn't work with most table elements → cannot position tr/td/th

Updated

16 years ago
Depends on: 35168
*** Bug 180481 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Priority: -- → P3
Target Milestone: --- → Future
*** Bug 190765 has been marked as a duplicate of this bug. ***

Comment 9

15 years ago
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---

Updated

15 years ago
Target Milestone: --- → Future

Comment 10

14 years ago
Created attachment 155727 [details]
More comprehensive testcase

WFM with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614
Firefox/0.9

The other testcase works as well.

Comment 11

12 years ago
re: comment 3 table elements like tr, td , th should never lookup the position in the frame constructor code for abs. pos. frames as they will *never* have a table-cell or table-row display type if they are abs. positioned.
(Assignee)

Updated

12 years ago
Assignee: layout.tables → dbaron
QA Contact: madhur → layout.tables
(Assignee)

Comment 12

12 years ago
Fixed by nsRuleNode.cpp changes that were part of bug 210873.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.5alpha
(Assignee)

Updated

12 years ago
Depends on: 210873
(Assignee)

Comment 13

12 years ago
(That is, the absolute positioning part is; the relative positioning part is covered by bug 35168.  There is also a bug on positioned tables not being a containing block.)
You need to log in before you can comment on or make changes to this bug.