CSS is almost too flexible to be able to stick to some sort of convention. I find myself trying to code in one style, and then doing it differently or disliking it on a different project.
I try to make some of it self-documenting, so will only class out a particular element then, through CSS, enforce a strict order of child elements by using the direct descendant/sibling selectors, etc. I'll usually include the element hierarchy in the definition where necessary. But then I don't like it because there's so much repetition.
body > header { ... }
body > header > h1 { ... }
body > header > h1 + small { ... }
That KSS attempts to better document CSS is great, and I'll certainly look into that more. But in some ways I think the difficulty comes from CSS itself being pretty flat when a DOM tree is anything but. And for the sake of easy re-use and documentation, sometimes you'd rather not just have a huge list of styled classes and IDs to wade through when you really don't need that many.
One problem with the approach you've pointed out is very very specific selectors. This really couples the structure of your HTML to how it displays. This works well for a while, but on bigger projects it has fallen down for me every time.
I've been finding that keeping my selectors no more than 3 deep is a good balance. It also forces me to abstract container styles into re-usable bits, and name things properly instead of exploiting the structure of the HTML.
The issue with doing it this way is that you're making the CSS processor doing unnecessary work. If you are writing:
div#sidebar > form#login-form input
then you are actually searching for input, then #login-form, then form, then #sidebar, then div. It adds up on a really big site. If you had just written
#login-form input
you get the same selection without the additional processing. Even if you want to track the full "stack", don't use those extra tag qualifiers.
Why the hell doesn't the lookup code work left-to-right, like you write CSS? Is there a good reason, or is it just there to make you eschew best practices after you learn them?
I try to make some of it self-documenting, so will only class out a particular element then, through CSS, enforce a strict order of child elements by using the direct descendant/sibling selectors, etc. I'll usually include the element hierarchy in the definition where necessary. But then I don't like it because there's so much repetition.
Or Why is there nothing (without Less/Sass/some other package) like That KSS attempts to better document CSS is great, and I'll certainly look into that more. But in some ways I think the difficulty comes from CSS itself being pretty flat when a DOM tree is anything but. And for the sake of easy re-use and documentation, sometimes you'd rather not just have a huge list of styled classes and IDs to wade through when you really don't need that many.