W3C home > Mailing lists > Public > www-style@w3.org > July 2008

Re: Parent Combinator / Parent pseudo-class

From: Brad Kemper <brkemper@comcast.net>
Date: Fri, 25 Jul 2008 19:22:24 -0700
Cc: Francois Remy <fremycompany_pub@yahoo.fr>, Andrew Fedoniouk <news@terrainformatica.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, www-style list <www-style@w3.org>
Message-Id: <3470E709-E523-4924-A25E-EE5D5A1305C5@comcast.net>
To: Joshua Cranmer <Pidgeot18@verizon.net>


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:10 GMT