CSS: Does it render "ul > li" faster than "ul li"? - css

Question

using ">" rather than " " make the rendered faster as I heard from few people?
.slide:hover > div > span {
border-color: #c8c8c8;
}
OR
.slide:hover div span {
border-color: #c8c8c8;
}
Thanks a lot!
update: question
any reliability problem for any of this?

Answer 1

You should very seriously reconsider listening to the people who tell you this type of thing.
The difference is utterly insignificant at best. No one should waste time, energy, or brainpower considering such things. This isn't a useful optimization. Don't fall into the trap of premature optimization, especially for a dynamic language like HTML/CSS.
Write code that is clear, maintainable, and functional first, before worrying about anything else.
If ul > li looks clearer to you than ul li, then write it that way. If not, don't. Keep it simple.

Answer 2

.slide:hover > div > span is more efficient than .slide:hover div span.
However, you're never going to notice the difference with average size pages.
If you used the Child Selector instead of the Descendant Selector everywhere in your stylesheet for a really freaking massive/complex page, you could shave off a noticeable portion of the render time (see comment by #Boris Zbarsky).
With average size pages, you might shave off a few milliseconds.
There is one disadvantage to using the Child Selector - IE6 does not support it.
For 99% of sites, IE6 support is not an issue, but some people still do use it:
http://ie6countdown.com/

Answer 3

Which is faster?
Like Cody and thirtydot said, theoretically using > should be faster, but even styling for IE6 is less a waste of your time than styling for performance. Browsers are fast enough; trust your browsers, not the people who tell you this, especially not those who don't provide any browser benchmarks to back their claims.
any reliability problem for any of this?
Sure. Besides IE6 not supporting > at all as thirtydot mentions, there's also the difference in elements matched since > and the whitespace combinators select different things:
<section class="slide">
<div>
<span></span> <!-- [1] -->
<div>
<span></span> <!-- [2] -->
</div>
</div>
<div>
<p>
<span></span> <!-- [3] -->
</p>
</div>
</section>
What's selected and what's not:
Selected by both selectors
This span is a child of a div which is a child of an element with class slide. Since span is a child of div, it's also a descendant of div. Likewise for div and its .slide parent/ancestor.
On hovering the .slide element, this span is selected. The rule applied is the second one because both selectors are of equal specificity, but the second one, well, comes second.
Selected only by .slide:hover div span
This span is in a div, but its parent div is located in another div that doesn't have the class slide. So the first selector doesn't find this element.
The inner parent div is, however, a grandchild of a .slide element. Regardless of depth, it's still in some way a descendant of .slide (it's contained somewhere within it).
On hovering the .slide element, this span is selected. The rule applied is the second one because it's the only one that matches.
Selected only by .slide:hover div span
This span's parent is a p element, not a div. Easy enough; the first selector doesn't find this element.
The span is, however, a grandchild of a div element, which itself is inside a .slide.
On hovering the .slide element, this span is selected. The rule applied is the second one because it's the only one that matches.
One last thing: in all three scenarios do you find that the rules in only the second selector are applied. This is purely coincidental; the differences in how supporting browsers look for elements to match are still real.