Posted by Ben C on 10/19/07 09:23

On 2007-10-19, rf <rf@invalid.com> wrote:
>
> "Alan Searle" <aj_searle@xxxxxxyahoo.com> wrote in message
> news:ff9opc$9nf$1@newsreader2.netcologne.de...
>> Bergamot wrote:
>
>> Ah, yes, let me expand: I am presenting some big tables of data and so,
>> in the header I present the titles followed by a division break and then
>> the table below becomes scrollable (with the header/titles always
>> displayed). This is great but of course you have to make sure that the
>> column widths of the table are exactly the same width as the titles that
>> you have declared in the header. Otherwise you have skewed columns under
>> the headers which makes it difficult to read.
>>
>> On most of the reports this works great but, wherever there is a long item
>> of text in a particular column, then the whole thing gets distorted.
>>
>> Any tips would be most welcome.
>
> This has been asked many, many times before (at least once a month). The
> answer is "this is how tables work".
>
> Google for further information but consider overflow: hidden; which will
> work but will also hide your content.

I think that does work in some browsers but not in others. And I'm not
sure about it.

The spec (CSS 2.1 17.5.2.2) says:

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 ...

So what does "may not overflow the cell box" mean?

If overflow is set to hidden, in the technical CSS sense, the box still
overflows. The overflow property just says what to do about, not that it
hasn't happened.

But if the overflowing bit has been clipped, because overflow was set to
hidden, then you might say in ordinary language that the box no longer
overflows.

On the former interpretation, which I favour, the value of the overflow
property should make absolutely no difference to minimum content width.
So it shouldn't stop table-cells growing past their set widths to fit
long unbreakable sequences.

The same thing applied to shrink-to-fit calculations for floats was
behind the anomaly observed by dorayme on htmldog.com recently. Firefox
allowed a big <pre> element to be shorter than its minimum content width
because it had overflow: scroll.

[...]
> By the way, you did *not* provide an example of what your page will
> eventually look like. Your example page has only one table, not the
> "division break" you hint at above. So, it is actually still a little
> unclear what you exactly want.

Yes, it sounds like the best thing would be one big table. That will
make sure the headings line up with the columns properly.

[Back to original message]