- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Mon, 29 Dec 2008 21:02:22 -0500
- To: Brad Kemper <brad.kemper@gmail.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, Rainer Åhlfors <rahlfors@wildcatsoftware.net>, "Tab Atkins Jr." <jackalmage@gmail.com>, mongolie2006-w3c@yahoo.fr, CSS mailiing list W3C <www-style@w3.org>
Quoting Brad Kemper <brad.kemper@gmail.com>:
> Still... presumably the UA knows what column a given cell is in (or
> started in), in order to apply the COL properties that it does. If
> "nth-child" is OK and not too burdensome for the UA, then what makes
> "nth-col" (or nth-column) so much worse?
It's not that much worse (though a good bit more expensive to compute, due to
having to get attributes and having to deal with rowspans). Isn't this what
dbaron proposed be added?
That still won't help if you do:
td:nth-col(2), td:nth-col(3) { display: block; }
since at that point the td:nth-col(4) will actually be in the third column in
the table. But that's the author's problem, of course.
> If the first column TD of the row was a colspan (and not part of a
> rowspan), then nth-col(2) would be ignored. And if the first column
> TD of the row was a in a rowspan and was not the first TD of the
> span, then it would be ignored.
Ignored meaning what? That it wouldn't match nth-col(1), or that the thing to
its right would? I assume you mean the former, and that the thing to
its right
would not match nth-col(1) and would match nth-col(2)?
> It does not seem like this would make the rendering harder
It sure does, just not a huge amount.
> and could be something that COL mapped to.
This would need to be very carefully defined, but yes.
-Boris
Received on Tuesday, 30 December 2008 02:09:19 UTC