- From: Brad Kemper <brkemper@comcast.net>
- Date: Fri, 25 Jul 2008 19:22:24 -0700
- To: Joshua Cranmer <Pidgeot18@verizon.net>
- Cc: Francois Remy <fremycompany_pub@yahoo.fr>, Andrew Fedoniouk <news@terrainformatica.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, www-style list <www-style@w3.org>
On Jul 25, 2008, at 2:41 PM, Joshua Cranmer wrote:
> Brad Kemper wrote:
>> I can really see no use case for a "has-child" pseudo-class to look
>> at all descendants.
> I see only one case that would be common:
>
> tr:has-grandchild(input:checked) -- to change the background of a
> row based on whether or not a checkbox was checked
I was thinking that you could just put it in at a deeper level or
something, but yes, I am convinced now that there are indeed times
when you would want to do deeper levels without resorting to something
messy like this:
tr:has-child(td:has-child(input:checked))
...which maybe should not even be allowed. Maybe a second sub-value to
indicate how deep it should look would be better:
tr:has-child(input:checked,2) {
/* search 2 generations down instead of just 1 */
}
tr:has-child(input:checked,all) {
/* search all descendants */
}
But my point remains, that if multi-level descendent matching is too
slow and heavyweight, then we should at least still have a single
generation has-child type of thing, as there lots of good uses for
that. I actually really like Tab's "matches" syntax that would allow a
child or sibling match.
Received on Saturday, 26 July 2008 02:23:07 UTC