Re: [css3-selectors] :parent selector

Le Sun, 24 Sep 2006 16:25:04 +0300, Matthew Raymond  
<mattraymond@earthlink.net> a écrit:

>    Let me see if I understand this right. Here's an example from the
> email you link too:
>
> | input[type="radio"] < form:not(input[type="radio"]:checked < form)
>
>    Here, "<" is the parent selector, so your :parent pseudo-class is
> pretty much "< *". If we wanted to use :parent to reproduce the above
> example, we could to the following:
>
> | form > input[type="radio"]:not(:checked):parent
>
>    The problem here is that you have to check all of the parent's
> children to see if they match the part of the selector before :parent,
> which strikes me as a serious performance hit.

The given selector is already quite complex.

Allow me to understand how this would work:

The UA searches for all "form" nodes, then goes for all "input" child  
nodes (not recursively in the tree, only the direct child nodes), then  
picks all of those input child nodes which are not checked, of type=radio.  
Having :parent only "asks" the UA to apply the properties to the parent  
nodes of the picked "input" child nodes. The UA already has the parent  
nodes (the "form" nodes), since it matched them previously to get to the  
inputs.

If this is not how things work now (most likely), then how do they work?

If the above is not entirely wrong, then why is it a huge performance hit  
to apply the properties to the parent instead of the child?

> On top of this, it could be recursive:
>
> | element1 > element2 > element3 > element4:parent:parent:parent
>
>    In the above, the user agent has to check every child of every
> element in the chain. If you assume that each element has just two
> children, then you're checking 2 + 4 + 8 (14) nodes.

Should something recursive be avoided at all costs in CSS?


-- 
http://www.robodesign.ro
ROBO Design - We bring you the future

Received on Sunday, 24 September 2006 14:41:30 UTC