Closed
Bug 25541
Opened 25 years ago
Closed 24 years ago
Tables: <td width=100%><\td><td>Graphics x 2<\td> problem
Categories
(Core :: Layout: Tables, defect, P3)
Tracking
()
VERIFIED
FIXED
M16
People
(Reporter: g.boehm, Assigned: rods)
References
()
Details
(Whiteboard: [4.xP][TESTCASE])
Attachments
(4 files)
take look at it with this brwoser version and the 4.7 version regards, lenix
Updated•25 years ago
|
Whiteboard: [MAKINGTEST] gervase.markham@univ.ox.ac.uk
Comment 1•25 years ago
|
||
Verified on M13 Win95, but could be all platforms. NS4.7 and M13 cope with the situation where a <td> is width=100% and then there's another one in the same row, and that second <td> contains two graphics, differently. NS4.7 puts them together horizontally, M13 vertically. Testcase, boiled down from URL above, attached. It uses publically available (http://www.bbc.co.uk) graphics for simplicity. Note: if you insert a newline between the two <img> tags in the testcase, NS4.7 starts doing the same thing as Mozilla - i.e. arranging them vertically. Gerv
OS: other → Windows 95
Summary: problem with displaying the tablesetting in the correct way → Tables: <td width=100%><\td><td>Graphics x 2<\td> problem
Whiteboard: [MAKINGTEST] gervase.markham@univ.ox.ac.uk → [4.xP][TESTCASE]
Comment 2•25 years ago
|
||
Comment 4•24 years ago
|
||
Comment 5•24 years ago
|
||
Sorry about that - the first test case _had_ the abovementioned \n in it, and so appeared the same in both browsers. Verified still a problem in 2000021615 W95. Gerv
Comment 6•24 years ago
|
||
Having a % based cell determine the width of an auto width table is a "quirk" and violates the standard. IE gets around this in the 2nd attachment by ensuring that the adjacent images never wrap, which isn't necessarily the right thing to do. I'm not sure how to fix this in "quirks mode" because, I thought that the behavior was to let the 100% cell get as much width as it could. This test case disproves that theory.
Status: NEW → ASSIGNED
Target Milestone: M16
Comment 7•24 years ago
|
||
I just ran into this same problem. I have an element that I want to take up 100% of the width EXCEPT for the space another cell is taking up. As you mentioned, IE has found a way around this problem. Here's my comments on the subject for what little it is worth :-) I agree with Mozilla's implementation, not IE's. A good way around this problem SHOULD be to insert extra TD tags. HOWEVER, it does not work correctly with BUTTON tags. In my opinion, this is the problem that needs to be addressed. Refer to the coming testcase where table cells overlap, and the orginal testcase is FIXED.
Comment 8•24 years ago
|
||
Comment 9•24 years ago
|
||
Comment 10•24 years ago
|
||
Rod, it looks like the button (3rd attachment) is reporting a max element width smaller than its desired width during the table's unconstrained reflow. When the table later reflows it with the max element width it spills into the next cell.
Assignee: karnaze → rods
Status: ASSIGNED → NEW
Assignee | ||
Comment 12•24 years ago
|
||
for got to set "fixed"
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 13•24 years ago
|
||
I guess I can't actually verify this since I didn't report it. Whatever, I agree that this is fixed.
Comment 14•24 years ago
|
||
Verified fixed. Nav and Netscape 6 display identically with 9/14 build.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•