On Friday 2006-05-19 12:42 -0400, Mike Dougherty wrote:
> Is there any known performance impact to possibly overly specific selectors?
>
> ex:
> #CategoryList li.Category ul li.product ul li.ciDsc a:hover {}
> (vs.)
> li.ciDsc a:hover {}
>
> The first case is extremely specific and clues the reader to the structure of
> the document
>
> Does the second case incur less parse/render overhead?
Mozilla's selector matching implementation matches from the end of the
selector to the start, i.e., it matches a:hover first, and if that
matches it tries to match li.ciDsc, and so on. I suspect this is the
way other implementations work as well.
Parsing shouldn't be a big deal compared to selector matching, but yes,
the second is less expensive for both. For the example you give, there
is only a selector matching difference for elements that match the
second, since for the first there are more things to be checked. So it
mainly depends on how many elements (partly) match and how many things
there are to test.
It's also worth noting that child combinators (">") are less expensive
than descendant combinators (" "), although combinations of the two can
actually be more expensive than descendant combinators only.
It may also be worth noting that Mozilla (in particular, probably not
common to other browsers) optimizes selector matching based on element
type, class, and id selectors that match the subject of the selector (in
this case, the subject is the element matched by a:hover), and also has
separate optimizations for pseudo-class and attribute changes.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
pgpALgRqESlR6.pgp
Description: PGP signature
______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
