609720 - FF does not accurately render a TD cell's width based on its COLSPAN.

Status: RESOLVED INVALID

(Core :: Layout: Tables, defect)

Description

[Simon]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GIS IE 6.0 Build 20080321; .NET CLR 2.0.50727; .NET CLR 1.1.4322; InfoPath.2; MS-RTC LM 8)
Build Identifier: 3.6.12

FF does not render a TD as a fraction of its COLSPAN to the total COLSPAN for all TDs in the row...and it should :-(

Reproducible: Always

Steps to Reproduce:
Create a simple HTML file and open in FF.

<html>
  <head>
  <body >
  <table  cellspacing="2" cellpadding="1" width="100%" border="1">
     <tr>
        <td height="20" colspan="2" >
        &nbsp;
        </td>
        <td height="20" colspan="8" >
        &nbsp;
        </td>
     </tr> 
     <tr>
        <td height="20" colspan="8" >
        &nbsp;
        </td>
        <td height="20" colspan="2" >
        &nbsp;
        </td>
     </tr> 
  </table>
</body>
</html>
Actual Results:  
The TD cell with COLSPAN 2 does not render as (2 / (2 + 8)) of the width of the row.
The TD cell with COLSPAN 8 does not render as (8 / (2 + 8)) of the width of the row.

Expected Results:  
The TD cell with COLSPAN 2 should render as (2 / (2 + 8)) of the width of the row.
The TD cell with COLSPAN 8 should render as (8 / (2 + 8)) of the width of the row.

The browser should total up the COLSPAN for the row, especially if COLSPAN is specified for every TD and it should render the width of the TD as fraction of its COLSPAN / TOTAL COLSPAN.

Adding a dummy row with a TD of COLSPAN one...where the number of TDs is equal to the total of COLSPAN for the row, makes FF render all TDs nicely.

e.g. since the COLSPANs 2 and 8 add up to 10, add a dummy row with 10 TDs of COLSPAN 1, like this:

     <tr>
        <td height="20" colspan="1" >
        &nbsp;
        </td>
        <td height="20" colspan="1" >
        &nbsp;
        </td>
        <td height="20" colspan="1" >
        &nbsp;
        </td>
        <td height="20" colspan="1" >
        &nbsp;
        </td>        
        <td height="20" colspan="1" >
        &nbsp;
        </td>
        <td height="20" colspan="1" >
        &nbsp;
        </td>       
        <td height="20" colspan="1" >
        &nbsp;
        </td>
        <td height="20" colspan="1" >
        &nbsp;
        </td>        
        <td height="20" colspan="1" >
        &nbsp;
        </td>
        <td height="20" colspan="1" >
        &nbsp;
        </td>
     </tr>

Comment 1

[Nickolay_Ponomarev]

Attachment: testcase from the reporter

Comment 2

[Boris Zbarsky [:bzbarsky]]

> The TD cell with COLSPAN 2 should render as (2 / (2 + 8)) of the width of the
> row.

Why?  There's no spec that says so, and in fact doing that would break web sites, which depend on a quite different behavior due to the way IE (and Netscape before it) has historically handled this case.

Comment 3

[Simon]

Hi Boris,

I understood that the browser, in lieu of any specific width info could use its own judgement to determine width of cells.

My suggestion/desire is that in this scenario where each TD has a colspan it would be reasonable for each column to get a width based on the proportionate fraction that its colspan represents.


Cheers,

Simon

Comment 4

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

(In reply to comment #3)
> My suggestion/desire is that in this scenario where each TD has a colspan it
> would be reasonable for each column to get a width based on the proportionate
> fraction that its colspan represents.

This happens when none of the columns spanned already have widths that come from cells with smaller colspans.

However, when some columns spanned have widths that come from cells with smaller colspans, additional width is distributed in proportion to the existing width.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> I understood that the browser, in lieu of any specific width info could use its
> own judgement to determine width of cells.

Yes, and we do.  But using some algorithms here turns out to break sites, as I said, which makes it impossible to actually ship a browser using those algorithms.  That's why the smaller colspan behavior dbaron mentions in comment 4 is there: it's necessary to be compatible with existing web content.