Hi Chetan,
> > Why going through so many elements? It can't be good regarding
> performance
> > and it increases specificity for no reason.
> >
> > I'd go with a simple: #last {...}
>
> Point accepted. In general, one should keep selectors as simple as
> possible, with just as much specificity as one needs.
>
> However, in this case, #last{...} does *not* work see:
> http://roughtech.com/t/polar.html
> The selector #mainmenu li has to be overridden.
>
> Also, I personally prefer to prefix id selectors with the element
> name. This makes it easier for me to read and understand a stylesheet,
> I wont have to constantly refer to the html file. For example, I
> prefer li#last over #last because at a later time I would know, with
> one glance, that the id is on an <li>.
Imho, using element#id to increase the weight of a rule makes sense, but not
when it is used as a hint to help us read and understand rules. I'd think
/*comments*/ are better suited for that.
> Another thought: Is #last really faster than #container #mainmenu ul
> li#last ? It appears to me that the latter should be faster because
> the browser does not have to traverse the entire DOM tree looking for
> #last, it can just start from #container.
That's if browsers were reading from left to right, but they actually do the
opposite.
So consider this:
#mainmenu ul li#last #donations {font-size:1.24em;}
vs.:
#donations {font-size:1.24em;}
With the latter, once they've found the *key selector* (the rightmost one),
they are done! With the former, they need to keep going until they reach
#mainmenu
--
Regards,
Thierry
@thierrykoblentz
www.tjkdesign.com | www.ez-css.org | www.css-101.org
______________________________________________________________________
css-discuss [cs...@lists.css-discuss.org]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
