Printing tables

The W3C added THEAD, TFOOT and TBODY elements to facilitate the
printing of long tables, so that header and footer information could
be repeated on each page.

While I have seen this discussed briefly in a number of text books, I
have never seen it applied in reality satisfactorily.

Can anyone point me to a real situation where this has been done
please? I have tried in vain to find examples, but have been deluged
with irrelevant information so that I can't see the wood for the
trees!

Does anyone know of limitations? Very many thanks.

On 12/26/2007 9:48 AM, johnacooke (AT) gmail (DOT) com wrote:

The W3C added THEAD, TFOOT and TBODY elements to facilitate the
printing of long tables, so that header and footer information could
be repeated on each page.

While I have seen this discussed briefly in a number of text books, I
have never seen it applied in reality satisfactorily.

Can anyone point me to a real situation where this has been done
please? I have tried in vain to find examples, but have been deluged
with irrelevant information so that I can't see the wood for the
trees!

Does anyone know of limitations? Very many thanks.

In Gecko browsers (e.g., Firefox, SeaMonkey, Camino), there is a
well-known bug that prevents proper printing of long tables. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=294991>. Despite the
Summary, this also appears to affect tables without captions.

--
David E. Ross
<http://www.rossde.com/>

Natural foods can be harmful: Look at all the
people who die of natural causes.

David E. Ross wrote:

On 12/26/2007 9:48 AM, johnacooke (AT) gmail (DOT) com wrote:
The W3C added THEAD, TFOOT and TBODY elements to facilitate the
printing of long tables, so that header and footer information could
be repeated on each page.

While I have seen this discussed briefly in a number of text books, I
have never seen it applied in reality satisfactorily.

Can anyone point me to a real situation where this has been done
please? I have tried in vain to find examples, but have been deluged
with irrelevant information so that I can't see the wood for the
trees!

Does anyone know of limitations? Very many thanks.

In Gecko browsers (e.g., Firefox, SeaMonkey, Camino), there is a
well-known bug that prevents proper printing of long tables. See
https://bugzilla.mozilla.org/show_bug.cgi?id=294991>. Despite the
Summary, this also appears to affect tables without captions.

I was surprised by this item dated 2005-06-19:

The problem seems to be that we reflow the
inner table, *then* we reflow and place the
caption, which moves the inner table down.
The inner table no longer fits on the page
so bad things happen.

It looks like we want to reflow the table
first to find the table width before we reflow
the caption, but we need to reflow the
caption first so we know the available height
... I'm not sure how to resolve this
circularity. Any ideas

I don't see any circularity. Once computed, the table width should
remain the same and apply to every part of the table no matter how many
pages it covers. After that, the height of the caption can be
determined, and now the only thing that that affects is the choice of a
subset of rows to print on each page. Am I missing one or more
considerations?

On 2007-12-26, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

David E. Ross wrote:
[...]
In Gecko browsers (e.g., Firefox, SeaMonkey, Camino), there is a
well-known bug that prevents proper printing of long tables. See
https://bugzilla.mozilla.org/show_bug.cgi?id=294991>. Despite the
Summary, this also appears to affect tables without captions.

I was surprised by this item dated 2005-06-19:

The problem seems to be that we reflow the
inner table, *then* we reflow and place the
caption, which moves the inner table down.
The inner table no longer fits on the page
so bad things happen.

It looks like we want to reflow the table
first to find the table width before we reflow
the caption, but we need to reflow the
caption first so we know the available height
... I'm not sure how to resolve this
circularity. Any ideas

I don't see any circularity. Once computed, the table width should
remain the same and apply to every part of the table no matter how many
pages it covers. After that, the height of the caption can be
determined, and now the only thing that that affects is the choice of a
subset of rows to print on each page. Am I missing one or more
considerations?

No I don't think so.

It may be that the Gecko code only computes the width of a table as a
side-effect of reflowing it, so it's a hassle to re-organize, but there
is no real circularity that I can see: the width of the table doesn't
depend on the height of the caption.

Wed, 26 Dec 2007 17:24:54 -0600 from Ben C <spamspam (AT) spam (DOT) eggs>:

It may be that the Gecko code only computes the width of a table as a
side-effect of reflowing it, so it's a hassle to re-organize, but there
is no real circularity that I can see: the width of the table doesn't
depend on the height of the caption.

And the bug occurs even when there's no caption. I have this problem
with pretty nearly every table that crosses a page boundary, and I
use captions rarely or never.

--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2.1 spec: http://www.w3.org/TR/CSS21/
validator: http://jigsaw.w3.org/css-validator/
Why We Won't Help You:
http://diveintomark.org/archives/200..._wont_help_you

Harlan Messinger wrote:

David E. Ross wrote:
On 12/26/2007 9:48 AM, johnacooke (AT) gmail (DOT) com wrote:
The W3C added THEAD, TFOOT and TBODY elements to facilitate the
printing of long tables, so that header and footer information could
be repeated on each page.

While I have seen this discussed briefly in a number of text books, I
have never seen it applied in reality satisfactorily.

Can anyone point me to a real situation where this has been done
please? I have tried in vain to find examples, but have been deluged
with irrelevant information so that I can't see the wood for the
trees!

Does anyone know of limitations? Very many thanks.

In Gecko browsers (e.g., Firefox, SeaMonkey, Camino), there is a
well-known bug that prevents proper printing of long tables. See
https://bugzilla.mozilla.org/show_bug.cgi?id=294991>. Despite the
Summary, this also appears to affect tables without captions.

I was surprised by this item dated 2005-06-19:

The problem seems to be that we reflow the
inner table, *then* we reflow and place the
caption, which moves the inner table down.
The inner table no longer fits on the page
so bad things happen.

It looks like we want to reflow the table
first to find the table width before we reflow
the caption, but we need to reflow the
caption first so we know the available height
... I'm not sure how to resolve this
circularity. Any ideas

I don't see any circularity. Once computed, the table width should
remain the same and apply to every part of the table no matter how many
pages it covers. After that, the height of the caption can be
determined, and now the only thing that that affects is the choice of a
subset of rows to print on each page. Am I missing one or more
considerations?

If there are any floats beside the table, I can see how the *height* of
the rows might need to be recomputed as some of the ones whose text
would have wrapped at the floated element will have been pushed down
beneath it. But that's easy--there still isn't any circularity involved.

On 2007-12-27, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

Harlan Messinger wrote:
David E. Ross wrote:
[...]

In Gecko browsers (e.g., Firefox, SeaMonkey, Camino), there is a
well-known bug that prevents proper printing of long tables. See
https://bugzilla.mozilla.org/show_bug.cgi?id=294991>. Despite the
Summary, this also appears to affect tables without captions.

I was surprised by this item dated 2005-06-19:

The problem seems to be that we reflow the
inner table, *then* we reflow and place the
caption, which moves the inner table down.
The inner table no longer fits on the page
so bad things happen.

It looks like we want to reflow the table
first to find the table width before we reflow
the caption, but we need to reflow the
caption first so we know the available height
... I'm not sure how to resolve this
circularity. Any ideas

I don't see any circularity. Once computed, the table width should
remain the same and apply to every part of the table no matter how many
pages it covers. After that, the height of the caption can be
determined, and now the only thing that that affects is the choice of a
subset of rows to print on each page. Am I missing one or more
considerations?

If there are any floats beside the table, I can see how the *height* of
the rows might need to be recomputed as some of the ones whose text
would have wrapped at the floated element will have been pushed down
beneath it.

What I think you're describing can't happen. You can't have text inside
a table cell flowing around a float that originates outside the table
cell (including outside the table). This is because table cells are
"block formatting contexts"-- which means floats never leak into or out
of them.

The whole table itself may become narrower if there's a float to one
side of it though, and the presence of the caption may mean it clears
the float, and can be wider after all. So there is an additional
complexity there, but as you say, not a circularity.

But I think all this may be a red herring anyway, since the
table-breaking bug seems to occur even when there isn't a caption.

Harlan Messinger wrote:

Ben C wrote:

What I think you're describing can't happen. You can't have text inside
a table cell flowing around a float that originates outside the table
cell (including outside the table). This is because table cells are
"block formatting contexts"-- which means floats never leak into or out
of them.

I'm not sure how that follows. A div is a block formatting context, and
the text within a div will certainly flow around a floated element that
precedes the div.

OK, I'd been looking at the section block formatting contexts. I just
looked at the section on floats and found the relevant explanation:

"The border box of a table, a block-level replaced element, or an
element in the normal flow that establishes a new block formatting
context (such as an element with 'overflow' other than 'visible') must
not overlap any floats in the same block formatting context as the
element itself. If necessary, implementations should clear the said
element by placing it below any preceding floats, but may place it
adjacent to such floats if there is sufficient space. They may even make
the border box of said element narrower than defined by section 10.3.3.
CSS2 does not define when a UA may put said element next to the float or
by how much said element may become narrower."

I just ran a test with a p styled float: right and width: 10em followed
by a table styled width: 100% and three rows containing five columns of
text each, and found that that IE6 puts the whole table underneath the
paragraph and then gives it the width of the browser, while Firefox 2
ignores the paragraph completely when positioning and layout the the
table, also giving the table the full width of the browser, but also
overlapping the paragraph in full. My FTP server is refusing my
connection right now so I can't upload my test file for inspection but
it's below for anyone who wants to look.

It appears for once that it's IE6 that exhibits an acceptable behavior
while Firefox 2 doesn't.

On 2007-12-27, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

Ben C wrote:
On 2007-12-27, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:
[...]
If there are any floats beside the table, I can see how the *height* of
the rows might need to be recomputed as some of the ones whose text
would have wrapped at the floated element will have been pushed down
beneath it.

What I think you're describing can't happen. You can't have text inside
a table cell flowing around a float that originates outside the table
cell (including outside the table). This is because table cells are
"block formatting contexts"-- which means floats never leak into or out
of them.

I'm not sure how that follows. A div is a block formatting context,

No, not just any div. Only one that's overflow: anything-except-visible,
floated, display: inline-block or table-cell, etc. (see CSS 2.1 9.4.1) A
regular div is a block box, but not necessarily, and often not, a block
formatting context.

and the text within a div will certainly flow around a floated element
that precedes the div.

Yes, but only if the floated element is in the same block formatting
context as the div. Not in the same block box-- floats often leak out of
one block box into another and inline content has to flow around them.
But they don't cross the "city walls" of block formatting contexts.

I just ran a test with a p styled float: right and width: 10em followed
by a table styled width: 100% and three rows containing five columns of
text each, and found that that IE6 puts the whole table underneath the
paragraph and then gives it the width of the browser, while Firefox 2
ignores the paragraph completely when positioning and layout the the
table, also giving the table the full width of the browser, but also
overlapping the paragraph in full. My FTP server is refusing my
connection right now so I can't upload my test file for inspection but
it's below for anyone who wants to look.

CSS 2.1 9.5 says:

The margin box of a table, a block-level replaced element, or an
element in the normal flow that establishes a new block formatting
context [p. 126] (such as an element with 'overflow' other than
'visible') must not overlap any floats in the same block formatting
context as the element itself. If necessary, implementations should
clear the said element by placing it below any preceding floats, but
may place it adjacent to such floats if there is sufficient space.

Firefox is wrong here, and IE6 right. The table ought to go below the
float if you've set it to width: 100%.

But the one thing you will never see is inline boxes inside the table
cells flowing around that float since it originates outside the table
cells and therefore in a different BFC.

On 2007-12-27, Harlan Messinger <hmessinger.removethis (AT) comcast (DOT) net> wrote:

Harlan Messinger wrote:
Ben C wrote:

What I think you're describing can't happen. You can't have text inside
a table cell flowing around a float that originates outside the table
cell (including outside the table). This is because table cells are
"block formatting contexts"-- which means floats never leak into or out
of them.

I'm not sure how that follows. A div is a block formatting context, and
the text within a div will certainly flow around a floated element that
precedes the div.

OK, I'd been looking at the section block formatting contexts. I just
looked at the section on floats and found the relevant explanation:

"The border box of a table, a block-level replaced element, or an
element in the normal flow that establishes a new block formatting
context (such as an element with 'overflow' other than 'visible') must
not overlap any floats in the same block formatting context as the
element itself. If necessary, implementations should clear the said
element by placing it below any preceding floats, but may place it
adjacent to such floats if there is sufficient space. They may even make
the border box of said element narrower than defined by section 10.3.3.
CSS2 does not define when a UA may put said element next to the float or
by how much said element may become narrower."
[...]
It appears for once that it's IE6 that exhibits an acceptable behavior
while Firefox 2 doesn't.

Yup, I was just saying exactly the same thing in another post