273069 - Improper display of tables and colspan, where IE and Netscape 7.1 display as intended.

Status: NEW

(Core :: Layout: Tables, defect)

Description

[PolyNSBE Webmaster]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)

This particular page looks as intended in IE and Netscape 7.1 (however not in
Netscape 7.2, but thats besides the point). 

The problem is that all of the <td> elements should be centered and aligned with
both the header and footer panels, but in Mozilla this is not the case. Instead
Mozilla seems to arbitrarily choose which kind of colspan to use. 

I validated both my HTML and my CSS for this page and the only discrepency is my
use of IE specific functions in my CSS. My HTML is well validated.

Reproducible: Always
Steps to Reproduce:
1. goto url: http://polynsbe.org
2. goto url: http://polynsbe.org
3. goto url: http://polynsbe.org

Actual Results:  
Columns are not aligned properly.

Expected Results:  
Table should have the same width throughout. All of the table rows should have
the same exact width.

Works in IE, Netscape 7.1 and less.

Comment 1

[Phil Ringnalda (:philor)]

I wouldn't think that the NN7.2 display is beside the point, since that means
that anything based on Gecko more recent than the spring of 2003 doesn't like
it, not just Firefox.

Comment 2

[Boris Zbarsky [:bzbarsky]]

This seems to work OK in a current trunk build... Could you possibly attach a
screenshot of expected rendering and a screenshot of what you see, using
https://bugzilla.mozilla.org/attachment.cgi?bugid=273069&action=enter ?

Comment 3

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 4

[Bradley Meck]

Attachment: Test case using sizing and multiple colspan with background.

Comment 5

[Daniel.S]

In this case we can't really talk about a bug.

1. The testcase is rendered in quirks mode, with all silly rules applied to it. For Example width and height attributes are actually not allowed on inline elements, but each browser handleds them in one way or the other.

2. The table itself is overconstrained, the first row got 6 cells, the second one got 7 cells.

Except for the height of the table, the other browsers agree with our result in Standards Mode.

Please try to write more simply code. When thinking about what each property causes, you can master the design.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Hold on.  Hold on.  The point of quirks mode is to match IE in some common cases.  If it doesn't, that's a bug.  If it doesn't match IE and standards mode does, that's particularly bad.  This is a bug database, not a "tell the web developer to code differently" exercise.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Confirming bug.  We're not giving the table the width it should have, looks like.

dbaron, dholbert, any idea what's up here?

Comment 8

[Daniel.S]

(In reply to comment #6)
> This is a bug database, not a "tell the web developer to code differently"
> exercise.

Didn't mean to make it look like that. However, there are not many (if any)
similar reports, so I figured that this is likely a difference that isn't
necessary for web compat.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Ah, I see.  Our rendering is the same in standards and quirks mode and IE's is not.

OK, in that case this might be invalid after all, but that's up to the module owner to decide.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What are the relevant details of the testcase?  It's got a display:inline on the table, a whole bunch of widths that don't have units, lots of styles on elements, etc.?