Closed Bug 26665 Opened 25 years ago Closed 25 years ago

tables not expanding in the right places, etc...

Categories

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

x86
Windows 98
defect

Tracking

()

VERIFIED DUPLICATE of bug 19961

People

(Reporter: stew777, Assigned: karnaze)

References

()

Details

(Whiteboard: [TESTCASE])

Attachments

(4 files)

Hi! This is my first bug report so I hope I'm doing it right... I'm developing a website (you can see a beta at http://www.angelfire.com/ut/ptest/) and it renders pretty closely on Netscape and IE (with the exception ofcourse of Netscapes limited CSS support). However, it's just a mess in Mozilla (I'm using M12). The two main problems are 1. At the top of the pages there ae a bunch of nested tables that make up the title/banner add section. Only two tables in the whole "assmebly" have a 100% value, the outside one and one near the right hand side. You would expect then for the outside table to resize to the width of the screen and the other table with the 100% value to expand inside of it, making up the room. This is exactly what happens in IE and Netscape but not Mozilla (try it out). I hope you can fix this (it seems liek a serious bug to me). The other, less serious problem, is that there is a large ammount of space between the two rows of tables in the "nav" bar, as if there were a <p> tag or larger text somewhere. It shows up normally in IE and Netscape. THANX! Ryan Stewart stew777@email.msn.com
...sorry that didn't wrap for soem reason :)
OS: other → Windows 98
Priority: P3 → P2
Whiteboard: [MAKINGTEST] mielke@licel.com
The problem seems to me to be related how the width arguments, are propagated in nested tables. For instance with pagetest2.html my favourite rendering is produced by IE5 (I hate to admit that) It computes the width for the first two cells and leaves the space to the third cell, where a width argument of 100% leads to a complete expansion. The pagetest5.html also breaks with IE5 and Netscape 4.6. The notes in the HTML specification are not very precise for me, so I doubt wether it is really a bug or an unusual feature.
Whiteboard: [MAKINGTEST] mielke@licel.com → [TESTCASE]
I hope you can fix it. It must be a bug as there doesn't seem to be any way around it. Even if I do it with all tables (eg: instead of cells with 100% values I make tables without cell width values, and then put a table with a 100% value in that to make it expand) it will again work in IE but suprisingly not in mozilla or netscape.
...I"ve heard, like you said, it could be a problem with the HTML specs not indicating wether it's 100% of the table or the page, but either way I think it should still work...
Another exemple in 'http://www.forbes.com/tool/html/00/feb/0216/featb.htm' (Build ID 2000021516 NT4 ) joao
I just tested my testcases with Amaya, the rendering was also interesting. So it seems to me that the nesting of tables is some tricky stuff.
Attached file further_reduction_of_testcase (deleted) —
In the BasicLayoutStrategy.cpp there is a comment, which indicates that if more space for the columns is available, the fixed width will be overwritten. So I would call this a problem within the algorithm inherited from the Navigator (doing the same), and no wonder that in the table test case, the width argument is never used for table cells, so it is the typical case of: Not tested not working.
Problem #2 looks invalid - looks the reason there are big spaces between the two table rows is that every other cell in the first row has a nested paragraph which has a top and bottom margin of 1em. This is creating the space. If you take the paragraphs out, the space is reduced. Working on problem #1.
Thanks, mielke@licel.com, for identifying this as a dup of bug #19961 - marking it so. In 1st testcase, the first cell of parent table is being extended beyond its 245px specificity. *** This bug has been marked as a duplicate of 19961 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Verified dup of #19961
Status: RESOLVED → VERIFIED
THANX! for the heads up on the paragraph thing. I didn't really notice them, and they aren't nesicarry if tables are working correctly :) If you or anyone cares you check out a cleaner version of the code, but with the same major heading bug, at http://www.paintball.org
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: