- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 30 Dec 2008 09:31:44 -0600
- 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> <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
necessary.
(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.
~TJ
Received on Tuesday, 30 December 2008 15:32:25 UTC