W3C home > Mailing lists > Public > www-style@w3.org > December 2008

Re: [CSS2.1] col attributes: XHTML and CSS inconsistency?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 30 Dec 2008 09:31:44 -0600
Message-ID: <dd0fbad0812300731j4fd01537o9f681ea7a9b2baef@mail.gmail.com>
To: Simetrical <simetrical@gmail.com>
Cc: "Brad Kemper" <brad.kemper@gmail.com>, "Boris Zbarsky" <bzbarsky@mit.edu>, fantasai <fantasai.lists@inkedblade.net>, "Rainer ┼hlfors" <rahlfors@wildcatsoftware.net>, mongolie2006-w3c@yahoo.fr, "CSS mailiing list W3C" <www-style@w3.org>

On Tue, Dec 30, 2008 at 8:11 AM, Simetrical <simetrical@gmail.com> wrote:
> On Mon, Dec 29, 2008 at 10:06 PM, Brad Kemper <brad.kemper@gmail.com> wrote:
>> Is it? I tend to think of it as the first cell stretching across the second,
>> and taking its place, but not BEING the second cell (the second column cell
>> is missing, because the first column cell is taking its place, just like in
>> the markup).
> Well, what uses do you generally see colspans being put to?  The first
> use that comes to mind is on Wikipedia's "Comparison of" articles:
> <table>
> <tr><th>&nbsp; <th>Feature 1 <th>Feature 2 <th>Feature 3
> <tr><th>Thing 1 <td colspan="3">Yes
> </table>
> In this case, the semantics are that "Yes" is the value for all three
> columns.  If you wanted the third and fourth columns to be have no
> entries at all, with "Yes" only being the value for column two, you'd
> add the extra cells but leave them blank.
> I guess that if Feature 3 was really important you might want to have
> :nth-col(4) { font-weight: bolder; }
> but then it's not clear if you'd want this to apply to the other two
> features also, if a cell overlaps all three.  If you want to set apart
> one column by styling it differently, you'd likely avoid colspans that
> run over that row, so I'm not sure if it makes a difference how
> colspans are treated here.  The advantage of :nth-col() would be that
> you could safely style cells where colspans occurred *earlier* in the
> row.

Nod to Simetrical.  In my own use, and many uses I see in the wild, a
colspan indicates that a particular cell is semantically part of
several columns, and thus should probably take styling from all the
columns it participates in.  If I did want a colspan'd <td> to only
take the styling of a particular column, it's not clear that I'd
typically want it to inherit from its first column.  I'd rather leave
that sort of specificity alone and let @class or @id handle it when

(Of course, rowspan'd <td>s offer the same arguments, but they *can*
be styled appropriately with :nth-child and/or easily @class'd in a
single place.  Since the decision has already been made for us, there
is no need to change it.  However, it does offer a consistency
argument toward making colspan'd <td>s inherit styles from their first
column only.)

> Boris Zbarsky wrote:
>> Quoting Brad Kemper <brad.kemper@gmail.com>:
>> But the whole range of styling possibilities would apply to td:nth- col(), if I am following this correctly. Right? That's kind of the whole idea?
> I'd think so, yes.

If :nth-col can apply the full range of styling (not just the standard
4 attributes), then why can't we just move this functionality into
<col>?  Does the fact that it's a pseudoclass rather than a normal
element allow you to defer the styling decisions somehow?  If it is at
all possible I'd like to avoid introducing a new entity when there are
existing ones begging to be enhanced.

Received on Tuesday, 30 December 2008 15:32:25 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:42 UTC