Misrendered table cells width specified with CSS (colspan)

Followup-to set: comp.infosystems.www.authoring.stylesheets

Hello fellow alt.html and comp.infosystems.www.authoring.stylesheets
colleagues,

I need a second opinion on a precise webpage testcase which I
submitted as a bug CSS spec violation) occuring in IE 7 and in latest
IE 8 build to Microsoft IE Team. Microsoft IE Team closed that bug.
Were they right? If so, why?

Testcase URL:
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspan-test1.html

Bug report:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=384963
in which it is said
"This behavior is by design and consistent with IE7 and Opera. The CSS
2.1 specs does not specifiy how to distribute witdth in colspan cells.
The internal algorithm IE use mainly mimics IE7 behavior."

Further reading:
IE Blog's Table rendering post:
http://blogs.msdn.com/ie/archive/2005/02/10/370721.aspx
which states
"Internet Explorer does support progressive rendering of content as it
arrives. This is true however for table rendering. When Internet
Explorer encounters a table it measures all the content of the table
before rendering so that it knows what the widths of the columns are
to render the content correctly. (...) we parse the entire table
content first"

So, IE seems to prioritize content over specified CSS declarations for
table cells or even table columns in automatic table layout rendering
mode (table-layout: auto). IE seems to prioritize content over
specified CSS declarations for table cells or even table columns in
automatic table layout rendering mode (table-layout: auto) up to a
point of ignoring/overruling specified CSS declarations for table
cells or even table columns.

I'm perplex... because

CSS 2.1, section 17.5.2.2 Automatic table layout
states
"Input to the automatic table layout must only include the width of
the containing block and the content of, and any CSS properties set
on, the table and any of its descendants. "
http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

Regards, Gérard

Followup-to set: comp.infosystems.www.authoring.stylesheets

On 2009-01-20, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:

Followup-to set: comp.infosystems.www.authoring.stylesheets

Hello fellow alt.html and comp.infosystems.www.authoring.stylesheets
colleagues,

I need a second opinion on a precise webpage testcase which I
submitted as a bug CSS spec violation) occuring in IE 7 and in latest
IE 8 build to Microsoft IE Team. Microsoft IE Team closed that bug.
Were they right? If so, why?

I think it's OK to close it.

Testcase URL:
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspan-test1.html

Bug report:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=384963
in which it is said
"This behavior is by design and consistent with IE7 and Opera. The CSS
2.1 specs does not specifiy how to distribute witdth in colspan cells.
The internal algorithm IE use mainly mimics IE7 behavior."

Exactly. The problem here is that your table has two columns, and one
cell which spans both of them. How wide should the two columns be?

One logical interpretation of your styles is that the second column must
be 400px, and the two columns together must be 600px. Therefore the
first column should be 200px.

So Firefox and Safari are doing a good job by making the first column
200px.

But in the general case, laying out a table with spanning cells can get
very complicated if you don't allow the simplification of first
converting it to a strictly square grid. If you do that, you tend to
translate widths on spanning cells to widths on the individual columns
they span. So 600px on a spanning cell might be simplified to "300px on
each column". In fact most browsers don't just split the width up
evenly, but distribute it in some way related to the content widths of
the spanned cells. It looks like that's what Opera and IE are doing
here.

The CSS 2.1 spec is non-normative when it comes to tables. In fact you
will find just about every browser ignores this:

1. Calculate the minimum content width (MCW) of each cell: the
formatted content may span any number of lines but may not
overflow the cell box. If the specified 'width' (W) of the cell
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
is greater than MCW, W is the minimum cell width. A value of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
'auto' means that MCW is the minimum cell width.

Most browsers will shrink a cell down to its content minimum width
regardless of a width set on it if other cells with more content in them
are demanding more of the available total width.

But rule No. 3 provides some justification for what Opera and IE are
doing here:

3. For each cell that spans more than one column, increase the
minimum widths of the columns it spans so that together, they are
at least as wide as the cell. Do the same for the maximum widths.
If possible, widen all spanned columns by approximately the same
amount.

So according to that, the MCW of columns 1 and 2 must be widened by
approximately the same amount so their MCWs add up to 600.

That means widening the 400px column and therefore the other column
becomes less than 400px.

See also RFC1942, line 1353.

For cells which span multiple columns, a simple approach, as used by
Arena, is to evenly apportion the min/max widths to each of the
constituent columns. A slightly more complex approach is to use the
min/max widths of unspanned cells to weight how spanned widths are
apportioned. Experimental study suggests a blend of the two
approaches will give good results for a wide range of tables.

Opera and IE are doing the "slightly more complex approach" here. The
simple approach would just make columns 1 and 2 both 300px wide. What
Firefox is doing is even more complex.

I quote RFC1942 not because it's not 12 years old or any kind of a
standard (check the top of the document), but because it does give some
insight into the rationale behind the table layout behaviour of older
browsers. Modern browsers have mostly been just keeping that behaviour
for compatibility.

Further reading:
IE Blog's Table rendering post:
http://blogs.msdn.com/ie/archive/2005/02/10/370721.aspx
which states
"Internet Explorer does support progressive rendering of content as it
arrives. This is true however for table rendering. When Internet
Explorer encounters a table it measures all the content of the table
before rendering so that it knows what the widths of the columns are
to render the content correctly. (...) we parse the entire table
content first"

So, IE seems to prioritize content over specified CSS declarations for
table cells or even table columns in automatic table layout rendering
mode (table-layout: auto).

You should find only where colspan is involved.

IE seems to prioritize content over
specified CSS declarations for table cells or even table columns in
automatic table layout rendering mode (table-layout: auto) up to a
point of ignoring/overruling specified CSS declarations for table
cells or even table columns.

I'm perplex... because

CSS 2.1, section 17.5.2.2 Automatic table layout
states
"Input to the automatic table layout must only include the width of
the containing block and the content of, and any CSS properties set
on, the table and any of its descendants. "
http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

They're not using anything else as input-- just juggling width between
spanning columns in a way that is a bit unintuitive in this case.

But this is not precisely specified anywhere. The advice to authors is
don't use colspan if you want pixel-perfect widths, and the advice to
implementors is just "try to do something sensible". Now in this case I
agree Firefox does intuitively a better job with those column widths,
but I wouldn't call this an IE bug, just a legitimate difference.

On 2009-01-20, Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-01-20, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:
[...]
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspan-test1.html
[...]
But rule No. 3 provides some justification for what Opera and IE are
doing here:

3. For each cell that spans more than one column, increase the
minimum widths of the columns it spans so that together, they are
at least as wide as the cell. Do the same for the maximum widths.
If possible, widen all spanned columns by approximately the same
amount.

So according to that, the MCW of columns 1 and 2 must be widened by
approximately the same amount so their MCWs add up to 600.

That means widening the 400px column and therefore the other column
becomes less than 400px.

I meant "less than 200px".

On Mon, 19 Jan 2009 17:22:07 -0800 (PST), GTalbot
<newsgroup (AT) gtalbot (DOT) org> wrote:

Followup-to set: comp.infosystems.www.authoring.stylesheets

Hello fellow alt.html and comp.infosystems.www.authoring.stylesheets
colleagues,

I need a second opinion on a precise webpage testcase which I
submitted as a bug CSS spec violation) occuring in IE 7 and in latest
IE 8 build to Microsoft IE Team. Microsoft IE Team closed that bug.
Were they right? If so, why?

Testcase URL:
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspan-test1.html

Bug report:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=384963
in which it is said
"This behavior is by design and consistent with IE7 and Opera. The CSS
2.1 specs does not specifiy how to distribute witdth in colspan cells.
The internal algorithm IE use mainly mimics IE7 behavior."

Further reading:
IE Blog's Table rendering post:
http://blogs.msdn.com/ie/archive/2005/02/10/370721.aspx
which states
"Internet Explorer does support progressive rendering of content as it
arrives. This is true however for table rendering. When Internet
Explorer encounters a table it measures all the content of the table
before rendering so that it knows what the widths of the columns are
to render the content correctly. (...) we parse the entire table
content first"

So, IE seems to prioritize content over specified CSS declarations for
table cells or even table columns in automatic table layout rendering
mode (table-layout: auto). IE seems to prioritize content over
specified CSS declarations for table cells or even table columns in
automatic table layout rendering mode (table-layout: auto) up to a
point of ignoring/overruling specified CSS declarations for table
cells or even table columns.

I'm perplex... because

CSS 2.1, section 17.5.2.2 Automatic table layout
states
"Input to the automatic table layout must only include the width of
the containing block and the content of, and any CSS properties set
on, the table and any of its descendants. "
http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

Regards, Gérard

Followup-to set: comp.infosystems.www.authoring.stylesheets

#red-cell-undefined-width
{
background-color: red;
color: white;
}

<td id="red-cell-undefined-width">should = 200px</td>

well duhh.
where do you see 200px in the css?
I'd say IE is showing what you say to show.
If you want it to show as 200px, then define it that way.

If you were smarter, you would use a container for the 3 cells.
Define the container at a fixed width.
Then you would define red as 200px or green as 400px, not both.

On 19 Jan 2009, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:

Followup-to set: comp.infosystems.www.authoring.stylesheets

Hello fellow alt.html and comp.infosystems.www.authoring.stylesheets
colleagues,

I need a second opinion on a precise webpage testcase which I
submitted as a bug CSS spec violation) occuring in IE 7 and in latest
IE 8 build to Microsoft IE Team. Microsoft IE Team closed that bug.
Were they right? If so, why?

Testcase URL:
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspa
n-test1.html

Bug report:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID
=384963 in which it is said
"This behavior is by design and consistent with IE7 and Opera. The
CSS 2.1 specs does not specifiy how to distribute witdth in colspan
cells. The internal algorithm IE use mainly mimics IE7 behavior."

Further reading:
IE Blog's Table rendering post:
http://blogs.msdn.com/ie/archive/2005/02/10/370721.aspx
which states
"Internet Explorer does support progressive rendering of content as
it arrives. This is true however for table rendering. When Internet
Explorer encounters a table it measures all the content of the table
before rendering so that it knows what the widths of the columns are
to render the content correctly. (...) we parse the entire table
content first"

So, IE seems to prioritize content over specified CSS declarations
for table cells or even table columns in automatic table layout
rendering mode (table-layout: auto). IE seems to prioritize content
over specified CSS declarations for table cells or even table columns
in automatic table layout rendering mode (table-layout: auto) up to a
point of ignoring/overruling specified CSS declarations for table
cells or even table columns.

I'm perplex... because

CSS 2.1, section 17.5.2.2 Automatic table layout
states
"Input to the automatic table layout must only include the width of
the containing block and the content of, and any CSS properties set
on, the table and any of its descendants. "
http://www.w3.org/TR/CSS21/tables.html#auto-table-layout

Well, regarding the automatic vs. fixed table layout thang, I've never
really gotten it to work the way I thought it _should_ work in any
browser. Admittedly, my testing hasn't been extensive - especially
since I shy away from tables, anyway.

--
Neredbojias
http://www.neredbojias.org/
http://www.neredbojias.net/
The road to Heaven is paved with bad intentions.

On 20 jan, 04:00, Ben C <spams... (AT) spam (DOT) eggs> wrote:

On 2009-01-20, GTalbot <newsgr... (AT) gtalbot (DOT) org> wrote:


Testcase URL:
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colsp...

Bug report:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackI...
in which it is said
"This behavior is by design and consistent with IE7 and Opera. The CSS
2.1 specs does not specifiy how to distribute witdth in colspan cells.
The internal algorithm IE use mainly mimics IE7 behavior."

Exactly.

Hello Ben,

I'm sorry I couldn't reply to your post before: I had health problems
(severe broken forearm fracture, 4 screws, 2 external fixating
rods...).
I read your post - they are usually well substantiated, I always
appreciate that and all your posts - but did not have the energy to
reply (too much pain - that disturbs reading and serene thinking - and
only 1 typing hand)

The problem here is that your table has two columns, and one
cell which spans both of them. How wide should the two columns be?

The interesting thing is that there is an algorithm working (and
specified in CSS 2.1 when involving colspanned cells) and being
applied when in table-layout: fixed [formating] mode.

One logical interpretation of your styles is that the second column must
be 400px, and the two columns together must be 600px. Therefore the
first column should be 200px.

So Firefox and Safari are doing a good job by making the first column
200px.

But in the general case, laying out a table with spanning cells can get
very complicated if you don't allow the simplification of first
converting it to a strictly square grid. If you do that, you tend to
translate widths on spanning cells to widths on the individual columns
they span. So 600px on a spanning cell might be simplified to "300px on
each column". In fact most browsers don't just split the width up
evenly, but distribute it in some way related to the content widths of
the spanned cells. It looks like that's what Opera and IE are doing
here.

They seem, as you say, to simplify the width allocation of colspanned
cells by splitting evenly and then making some adjustments based on
content. Although Opera 9.63 creates a table as wide as 694px in this
test:

http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspan-test2.html

and not a 600px wide table. It's not necessarly a bug since horizontal
table formatting is unspecified when involving colspanned cells.

The CSS 2.1 spec is non-normative when it comes to tables. In fact you
will find just about every browser ignores this:

* * 1. Calculate the minimum content width (MCW) of each cell: the
* * * *formatted content may span any number of lines but may not
* * * *overflow the cell box. If the specified 'width' (W) of thecell
* * * * * * * * * * * * * * * ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* * * *is greater than MCW, W is the minimum cell width. A value of
* * * *^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* * * *'auto' means that MCW is the minimum cell width.

So content can override specified width. In fact, it does so often.

[snipped]

The advice to authors is
don't use colspan if you want pixel-perfect widths, and the advice to
implementors is just "try to do something sensible". Now in this case I
agree Firefox does intuitively a better job with those column widths,
but I wouldn't call this an IE bug, just a legitimate difference.

Thank you very mich for your expert opinion on all this: this is very
much appreciated. Again

Regards, Gérard (with 1 hand and 1 typing finger)
--
Internet Explorer 7 bugs: 173 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/
Internet Explorer 8 bugs: ~=115 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/

On 2009-01-24, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:

On 20 jan, 04:00, Ben C <spams... (AT) spam (DOT) eggs> wrote:
On 2009-01-20, GTalbot <newsgr... (AT) gtalbot (DOT) org> wrote:


Testcase URL:
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colsp...

Bug report:
https://connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackI...
in which it is said
"This behavior is by design and consistent with IE7 and Opera. The CSS
2.1 specs does not specifiy how to distribute witdth in colspan cells.
The internal algorithm IE use mainly mimics IE7 behavior."

Exactly.

Hello Ben,

I'm sorry I couldn't reply to your post before: I had health problems
(severe broken forearm fracture, 4 screws, 2 external fixating
rods...).

Ouch!

I read your post - they are usually well substantiated, I always
appreciate that and all your posts - but did not have the energy to
reply (too much pain - that disturbs reading and serene thinking - and
only 1 typing hand)

Not to mention the drugs you were probably/should have been on. I had my
leg nailed and screwed back together once so I know what you mean.

Get well soon and look after that arm.

The problem here is that your table has two columns, and one
cell which spans both of them. How wide should the two columns be?

The interesting thing is that there is an algorithm working (and
specified in CSS 2.1 when involving colspanned cells) and being
applied when in table-layout: fixed [formating] mode.

Yes, and that is very simple. In table-layout: fixed column widths are
all determined by the first row. Your first row contains two cells with
widths auto and 400px in a table that's 600px. So column 1 must be 200px
and column 2 400px. That's established before it even gets to the
spanning cell.

But swap your two rows around, using table-layout: fixed, so the
spanning row is first. i.e.:

<-----auto, colspan 2----------->
<---auto--><---------400px------>

And both columns will be 300px wide. i.e. you'll get this:

<------------------------------->
<---------------><-------------->

One logical interpretation of your styles is that the second column must
be 400px, and the two columns together must be 600px. Therefore the
first column should be 200px.

So Firefox and Safari are doing a good job by making the first column
200px.

But in the general case, laying out a table with spanning cells can get
very complicated if you don't allow the simplification of first
converting it to a strictly square grid. If you do that, you tend to
translate widths on spanning cells to widths on the individual columns
they span. So 600px on a spanning cell might be simplified to "300px on
each column". In fact most browsers don't just split the width up
evenly, but distribute it in some way related to the content widths of
the spanned cells. It looks like that's what Opera and IE are doing
here.

They seem, as you say, to simplify the width allocation of colspanned
cells by splitting evenly and then making some adjustments based on
content. Although Opera 9.63 creates a table as wide as 694px in this
test:

http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/table-width-colspan-test2.html

and not a 600px wide table. It's not necessarly a bug since horizontal
table formatting is unspecified when involving colspanned cells.

Yes, although what Opera has done with that is not very desirable.
There's plenty of room there to make the second column 400px and the
whole table 600px.

As a content author you can't complain because it's unspecified, but
it's still something you might put on your TODO list to look at if you
worked at Opera.

The CSS 2.1 spec is non-normative when it comes to tables. In fact you
will find just about every browser ignores this:

* * 1. Calculate the minimum content width (MCW) of each cell: the
* * * *formatted content may span any number of lines but may not
* * * *overflow the cell box. If the specified 'width' (W) of the cell
* * * * * * * * * * * * * * * ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* * * *is greater than MCW, W is the minimum cell width. A value of
* * * *^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* * * *'auto' means that MCW is the minimum cell width.


So content can override specified width. In fact, it does so often.

Yes, but this is a different rule. This rule is saying that specified
width overrides the minimum width of the actual content.

It's saying that if you set width: 100px on a cell with little or no
content in it, it will never come out narrower than 100px (assuming
enough available width in the table altogether).

But that's not what most browsers do.

For example:

<tr>
<td style="width: 100px">a</td>
<td style="width: 100%">more content here</td>
</tr>

Most browsers will make the first column just wide enough for the letter
"a" even if that is less than 100px. i.e. the MCW of that cell is not
100px, but the width of "a"-- the real minimum content width.

[snipped]

The advice to authors is
don't use colspan if you want pixel-perfect widths, and the advice to
implementors is just "try to do something sensible". Now in this case I
agree Firefox does intuitively a better job with those column widths,
but I wouldn't call this an IE bug, just a legitimate difference.

Thank you very mich for your expert opinion on all this: this is very
much appreciated. Again

It's a very hard thing to specify which is why they haven't managed to
do it. It's difficult to say exactly what a browser should do with
(often contradictory) widths and percentages especially in the presence
of colspan; and whatever it does do also has to be compatible with
existing web content.

As your examples show, many browsers fail even in cases where it's
intuitively fairly obvious what they should do.

This is the strongest practical argument against using tables for layout
in my opinion.

In article <slrngnlqeo.356.spamspam (AT) bowser (DOT) marioworld>,
Ben C <spamspam (AT) spam (DOT) eggs> wrote:

On 2009-01-24, GTalbot <newsgroup (AT) gtalbot (DOT) org> wrote:
....
I'm sorry I couldn't reply to your post before: I had health problems
(severe broken forearm fracture, 4 screws, 2 external fixating
rods...).

Ouch!

....
Not to mention the drugs you were probably/should have been on. I had my
leg nailed and screwed back together once so I know what you mean.

You two should stop being such action men! Sit quietly at home. Read,
watch movies, use your computer. It's dangerous out there. Why take
risks?

--
dorayme