If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Tables: <td width=100%><\td><td>Graphics x 2<\td> problem

VERIFIED FIXED in M16

Status

()

Core
Layout: Tables
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: g.boehm, Assigned: rods (gone))

Tracking

Trunk
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [4.xP][TESTCASE], URL)

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
take look at it with this brwoser version and the 4.7 version
regards, lenix

Updated

18 years ago
Whiteboard: [MAKINGTEST] gervase.markham@univ.ox.ac.uk
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]
Created attachment 4675 [details]
test case
*** Bug 25668 has been marked as a duplicate of this bug. ***
Created attachment 5496 [details]
Test case, attempt 2
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

18 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

18 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

18 years ago
Created attachment 7820 [details]
Button tag is overlapped by neighboring text.

Comment 9

18 years ago
Created attachment 7821 [details]
Simplified TESTCASE w/o styles or images.

Comment 10

18 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 11

18 years ago
fixed
Status: NEW → ASSIGNED
(Assignee)

Comment 12

18 years ago
for got to set "fixed"
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 13

18 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

17 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.