W3C home > Mailing lists > Public > www-style@w3.org > February 2004

Re: [CSS2] More on tables

From: fantasai <fantasai@escape.com>
Date: Mon, 09 Feb 2004 21:40:14 -0500
Message-ID: <4028448E.7090503@escape.com>
To: www-style@w3.org

Ian Hickson wrote:
> On Mon, 9 Feb 2004, fantasai wrote:
>>   # A column box occupies **one or more columns** of grid cells.
>>Each column box should only encompass _one_ column.
> There are two issues here.
> First, can a column box span multiple columns. There is no reason why this
> should not be the case, as far as I can see. One could imagine in CSS3
> having:
>    mycolumn { display: table-column; col-span: 2; }
> ...be meaningful.

What's the *point*? You already have column groups; these are meant to
span multiple columns. You don't need columns to span multiple columns.
And besides, that's a ridiculously recursive concept: columns spanning
multiple columns.

Rows, Ian, do not span multiple rows. There's no reason why columns
should span multiple columns, and there are reasons (simplicity, backwards-
compatability, common sense) to have them not span multiple columns.

> The second issue is whether it is possible to represent <col span="">
> using CSS and display:table-column. It would appear to me that it is not,

Of course it's not. But if "mycolumn { display: table-column; col-span: 2; }"
were to mean anything in CSS, I would expect it to use 'col-span' to handle
the <col> element's 'span' attribute.

>>WinIE, Opera, and Mozilla all seem to follow this interpretation.
>>(Opera and Mozilla respect borders, WinIE and Mozilla respect width.)
> WinIE doesn't support table-column, Opera and Mozilla both have hard-coded
> ways of interpreting properties on <col>.

Then the WinIE on my computer must be special, because it's handling
CSS 'width' on <col> just fine.

*points out, before Ian objects to the substitution of <col> for a
'table-column' element, that <col> is practically the only case worth

> There is no current way to test if a UA actually supports what the spec
 > says or not, since there is no way to specify how many columns ...
 > column boxes should span.

Then there's absolutely no reason why CSS2.1 should even suggest that such
a thing would be possible.

 > no way to specify how many columns cell boxes ... should span

http://www.w3.org/TR/CSS21/tables.html#q7 point 5 explicitly allows
CSS UA to use language-specific knowledge to determine the cell's
row & col span. Such as the understanding the 'colspan' and 'rowspan'
attributes in HTML4.

  >>Border-Collapse Border-Box Dimensions
>>The problems with collapsed outer table borders noted in
>>   http://lists.w3.org/Archives/Public/www-style/2003Mar/0003.html
>>don't seem to have been addressed by the last draft.
>>I'd like to note that this problem *has* to be addressed by
>>incorporating the outer border into the margin space, not the
>>border space or the overflow. Otherwise, you get some really
>>awful renderings. See
>>   http://fantasai.inkedblade.net/style/demos/border-collapse-overflow/
>>for a demonstration.
> This seems to just be a browser bug. The backgrounds shouldn't spill
> outside the table edge. I suppose this might result in an irregular
> background clipping rectangle.

I'm not pointing out the "bug". Mozilla just happens to implement two
different algorithms for handling outer collapsed table borders, both
of which are under consideration here.

Standards mode is about as close to the current (somewhat ambiguous)
text as you can get. Therefore it demonstrates the problem with a
(logical) interpretation of the current prose: the border overflows
the table, painting over adjacent elements such as the paragraphs
above and below the table in that example.

   Note that adding margins *won't work* for buffering left/right borders
   if you want the table centered: that requires margins: auto, which
   means margins: 0 if the table is wide enough.
   Besides, that's a hackish way of doing things, and one that we can
   (and therefore ought to) avoid.

Quirks mode is an implementation of "behave as if the border width of
the table is as wide as the widest border on that side", which, hyatt
tells me, is what he proposed as a solution to the problem posed by the
Standards interpretation. It, too, demonstrates a problem: the background,
being bounded by the artificially-expanded border edges, spills over the
actual borders and makes a visual mess. (I pointed this out in my email
last March, too.)

As for your "solution" of clipping it to the visual border edges, there
are two problems with that:
   1.) It's complicated to implement. I can assure you that the probability
       of Mozilla implementing such a thing is quite low, especially since
       there are better (easier, more aesthetically pleasing, more consistent
       with the rest of CSS) ways of handling it.
   2.) Its concept of border-edge does not match that of any other table
       elements, all of which interpret the grid lines (the middle of the
       borders) as the border edges.

The current version of CSS specifies that these outer collapsed table
borders be part of the margin area, and this is indeed the best way to
handle it. The only adjustment it needs is to either specify *how* it
is part of the margin area OR to emphasize that it is *in* the margin
area, and therefore _the margin area may need to be adjusted to make
sure of that_.

> Again, if UAs don't implement this right, the spec will have to change
> before exiting CR.

Define "right".

Received on Monday, 9 February 2004 21:41:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:26 GMT