CSS Child VS Descendent Selector

CSS Child vs Descendant selectors

Just think of what the words "child" and "descendant" mean in English:

  • My daughter is both my child and my descendant
  • My granddaughter is not my child, but she is my descendant.

Is there a difference in performance between the child and descendant selectors?

Please be aware that both selectors doesn't give you same output! In your example, it does.

But let's check the next HTML code, which contains two links.

<div id="test">
<p> lorum ipsum <a href="#">here</a> dolor </p>
<a href="#">read more</a>
</div>

There is a link between the text, and a link after the paragraph, to allow the user to read more text. (like on news sites).

If you use

#test a {
...
}

Then you will select both links.

If you use

#test > a {
...
}

it will only select the direct descendant link of #test, which is the read more-link ! That is because > is a child combinator. The link in the paragraph won't be selected.

Here below is a snippet to show you the difference.

#test a {  color: red;}#test > a {  font-weight: bold;  font-size: 18px;}
<div id="test">  <p>lorum ipsum <a href="#">here</a> dolor</p>  <a href="#">read more</a></div>

CSS child vs descendent selector

Theoretically the child selector will be faster than the descendant selector because the browser can stop checking child nodes after the first level. However, I suspect that any performance enhancement you see from this will be negligible as browsers parse CSS quickly in the first place.

As NullUserException pointed out, the selector doesn't work in IE6, so if you care much about IE6 I wouldn't load your CSS with it. But a good thing to keep in mind is that you should have a very clear idea of which to use in which situation. Ask yourself, "do I want this declaration to cover all matching children, or do I want it to cover only direct matching children?" It may seem obvious to ask yourself such a question, but it really is the only way you should choose between the two. Don't use > unless you mean it.

Also see my question Is there an advantage to using very specific selectors in CSS?

See also: CSS selector support per browser

Difference between Child and Descendant Combinator Selectors

In your first example, there is only one .One element and only one .Two element, and that .Two is a child of that .One. So whether you use the child or descendant combinator isn't going to make any difference — both selectors are going to match just that lone .Two element. Any E > F pair is necessarily also an E F pair; the former is a proper subset of the latter.

Your second example is flawed for two reasons:

  • If you want to compare the child and descendant combinators, avoid using color — as others have mentioned it's inherited which can confuse you. (This applies to both examples.)

  • The only reason it's not actually being inherited by the inner ol is because you're not correctly nesting it within one of the outer li elements.

However, it nevertheless demonstrates why the child combinator works as advertised: because the inner li elements are not children of the outer ul. They are children of the inner ol.

What is the difference direct descendent () vs. descendant in jQuery selectors?

$("#mainblock > div") = the childs only level

$("#mainblock div") = all the childs+ desendents.

Difference between universal and descending selector in CSS

The general rule is to use the universal selector very sparsely due to its bad impact on performance. You basically almost never use it.

The descendant selector, as the name suggests, targets descendants of the element preceding the descendant selector.

Please note that both selectors you show are not exactly the same.

It helps alot to read selector from right to left:

div * .test targets

  • items that have a css class test (.test)
  • which are descendants
  • of any element *
  • which is a descendant
  • of a div element.

See this example:

div * .test{
color: red;
}
<div>
<div class="test">test</div>
</div>

What's the difference between CSS child selector without space ab and with space a b?

CSS is very forgiving. The CSS selectors specification mentiones that whitespaces around combinators (like your > here) are optional:

The following selector represents a p element that is child of body:

body > p

The following example combines descendant combinators and child combinators.

div ol>li p

It represents a p element that is a descendant of an li element; the li element must be the child of an ol element; the ol element must be a descendant of a div. Notice that the optional white space around the ">" combinator has been left out.

— Section 8.2 of the CSS Selectors Level 3 recommendation

To further back this up, the specification's Grammar section makes this really apparent with an implementation approach:

combinator
/* combinators can be surrounded by whitespace */
: S+ | S* [ '>' | '+' | '~' | COLUMN | '/' IDENT '/' ] S*
;

— Section 10 of the CSS Selectors Level 3 recommendation

For this reason, the following are all valid as CSS parsers should simply strip the spaces out:

a>b {}
a > b {}
a> b {}
a >b {}
a > b {}

So to answer your question: no, there is no difference.

As for which one you should use, however: that's purely a question of personal preference. For me, I'd opt for a > b, simply because I feel it makes it easier to read, but if you want to type a>b or even a > b it's entirely up to you - although anyone who has to read your code will probably not be your number 1 fan with the latter approach!



Related Topics



Leave a reply



Submit