W3C home > Mailing lists > Public > www-style@w3.org > January 2009

:nth-col() extension

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 27 Jan 2009 19:59:07 -0600
Message-ID: <dd0fbad0901271759s7e3814f0yc1ce02eb48c4b597@mail.gmail.com>
To: www-style@w3.org

Today I was considering a data table I was going to be working with,
and thinking of ways to make it easier to work with.  Putting a subtle
background on the row you're hovering with a "tr:hover" rule is nice,
but for this it would be nice to have it highlight the *column* that
you're hovering over as well.  A bit of playing around revealed that
there doesn't appear to be any way to do this within CSS.  "col:hover"
doesn't work, at least, and the few discussion I found about it
through searching were JS-based.  (From my knowledge of the :hover
class, it's implemented with a mouseover event listener on the root,
which is why col:hover doesn't work - the event doesn't bubble through
the col element.)

This brought to mind the discussion on the :nth-col() pseudoclass that
started last December[1][].  While :nth-col() doesn't immediately
admit this technique either, there was also discussion of a more
general :col() pseudoclass, which takes a selector and matches table
cells associated with a column matched by the selector.  With a
slightly imaginative interpretation, this might allow what I'm looking
for, via the rule "td:col(:hover)".

Assuming for a moment that the :col() pseudoclass were planned for
implementation, would :col(:hover) (and presumably :col(:active) and
:col(:focus)) pose any substantial problem?

[1]: http://lists.w3.org/Archives/Public/www-style/2008Dec/0207.html

~TJ

PS: While I'm here, it feels a little better for a :col or :nth-col to
instead be ::col or ::nth-col, that is, for it to be a pseudoelement
rather than a pseudoclass.  This might seem weird (<col> is a real
element in the DOM!), but it's really not, because you're *not*
targeting the <col> directly, you're targeting an imaginary element
which wraps <td>s across <tr> boundaries.  This approach has obvious
problems, namely that the pseudoelement *really* wouldn't be an
element in the DOM (unlike, say, ::first-line, which can pretend to be
an actual element in *most* cases), and to put it to any good use
you'd need to break the pseudoelement syntax and allow it to have
children.

tl;dr: Keeping it as a pseudoclass is almost certainly a better idea,
it just doesn't feel quite ideal in my brain.

PPS: The aforementioned playing around with tables revealed that IE
doesn't implement "tr:hover" very well.  While the spec explicitly
leaves it undefined when :hover applies, there's no reasonable
interpretation of the rule that would allow *some* cells from the
hovered row to gain a background, and for exactly *which* cells have
the said background to depend on how you move your mouse through the
table.
Received on Wednesday, 28 January 2009 01:59:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:15 GMT