Closed Bug 132773 Opened 22 years ago Closed 16 years ago

<td width> is ignored

Categories

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

x86
All
defect

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: wolfiR, Unassigned)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020320
BuildID:    

in the above URL there is a <td width="70"> which is ignored.

I found that this is deprecated in HTML4.01 but should be rendered
by user agents for backward compatibility.

Reproducible: Always
Steps to Reproduce:
1. open the URL above

Actual Results:  the second <table> is divided 50%/50%

Expected Results:  the first column should have a width of 70px and the second
should be the left space of the page
Confirming W2K 2002031104. OS -> All. Reassigning to HTMLTables.

Severity -> major - lots of sites assume that setting the width attribute for
the first table cell will affect the rest of the column.

I've produced a simplified testcase, which I will attach.
Assignee: attinasi → karnaze
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Layout → HTMLTables
Ever confirmed: true
Keywords: testcase
OS: Linux → All
QA Contact: petersen → amar
Attached file Testcase
Here's a testcase which demonstrates this bug, plus some additional wierdness.

Observations:
* Setting 'width' attribute on only the first TD in a column is ignored
(examples 1, 2, 7, 8).
* Setting 'width' attribute for all cells in column works fine (3, 4, 5, 6).
* The 'cols' attribute to TABLE changes the table layout slightly, even though
'cols' isn't a valid attribute for TABLE in HTML 4 or HTML 3.2, unless all TDs
in a column have the width attribute set (1&2, 7&8 vs. 3&4, 5&6)
* All the above apply in Quirks mode only (the !DOCTYPE given in the original
URL isn't correct enough to engage Standards mode)
cols are a quirk inherited from NN, and have been something which would be
today implemented via table-layout:fixed instead. I dont see why this bug is
major. For me the bug is either invalid or wontfix
Ah, I wondered what the cols attribute was.

Anyway, the original report was for the ignoring of the width attribute on the
TD in Quirks mode, and this still stands.
just a quote from the manual (NN4x):
 
http://developer.netscape.com/docs/manuals/htmlguid/tags9.htm

COLS="numOfCols"
indicates how many virtual columns of equal width fit in the width of the
window. Each actual column in the table occupies a virtual column. You would
typically set the COLS attribute to be equal to the number of columns in the
table to indicate that all the columns in the table have the same width.
Navigator 3.0

If the WIDTH attribute is supplied, the COLS attribute indicates how many
virtual columns fit in the specified width. If the WIDTH attribute is not
supplied, the COLS attribute indicates how many virtual columns fit in the
current window or frame. Each column in the table occupies one of the virtual
columns.

Suppose that the WIDTH attribute is "80%" and the COLS attribute is 4. In this
case, each virtual column takes up 20% of the width of the window. Each actual
column in the table occupies a virtual column, so it occupies 20% of the width
of the window, so long as the table has from 1 to 4 columns inclusive.

Note, however, that if the minimum width needed to display the contents of an
actual column is graeter than the width of a virtual column, then the width of
the column is expanded to fit its contents.

If the table has more actual columns than the COLS value, then the columns in
excess of the COLS value are displayed in the minimum width required to fit
their contents, and the other columns divide the remaining space equally between
them.

For example, suppose the table has 4 columns, the WIDTH attribute is "80%", and
the COLS value is 3. What happens here is that the table takes up 80% of the
width of the window. The fourth column uses the minimum width necessary to
display the contents of the column. The other 3 columns divide the remaining
width of the table equally between them. 

That is what mozilla is doing here.

So far for my claim, about marking invalid, the really interesting part is that
NN4x did not implement as well the spec as mozilla now does. So it boils down to
how far we would like to go in implementing NN quirks behaviour.

It would require some tweaking of BasicTableLayoutStrategy.cpp, but it will
definetely not happen before 1.0 -> this bug deserves only the milestone:
future. If somebody would like to get this bug fixed then pelase provide a a
regression tested patch. 
Severity: major → normal
Priority: -- → P4
Target Milestone: --- → Future
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
*** Bug 253694 has been marked as a duplicate of this bug. ***
Works for me.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070221 Minefield/3.0a3pre
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: