- 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