Posted by Ben C on 06/16/07 09:41

On 2007-06-16, JD <user@example.net> wrote:
> Ben C wrote:
><snip good post>
>> In fact using a selector rather than inline styles may be a tiny bit
>> faster because of the reduced amount of parsing.
>>
>> A more complex selector like div td div { ... } will be slightly harder
>> to match since it's a little bit like an easy version of matching a
>> regular expression, but I wouldn't worry about it.
>
> Sort of reminds me of a question I was thinking about recently.
>
> Is 'optimisation' any valid reason to consciously limit the depth of
> descendant selectors in CSS? For example, suppose I have a list of links
> inside a #navbar div. To style the a elements in the navbar, I could do
> this:
>
> #navbar a { ... }
>
> but I prefer to do this:
>
> #navbar ul li a { ... }
>
> just because I find the latter slightly more lucid when reading the
> stylesheet.
>
> Is there any circumstance where this coding style could noticeably slow
> things down? Or is worrying about this stuff a waste of time because the
> speed differences are so negligible?

I wouldn't worry about it. The second selector _may_ take longer to
match, but even that's an assumption, and compared to all the other
things the browser's got to do it's unlikely to be very much.

The time when you might notice things like this is popup-menu systems
that use complicated selectors involving :hovers halfway up them and
where any sluggishness would be noticeable on a slow machine. Unlikely
to matter on a PC but if you've got a browser on a mobile phone you
might see a difference, depending on how the browser's been implemented.

[Back to original message]