Hacker News Reader

Comment by alxprc | Hacker News Reader

Sure, but what if you have more than another section that should be styled differently? Classes can help differentiate same-name elements with different contexts, so you don't need unwieldy structure-specific CSS selectors like

  main > section > main

just

  main.semantic-class

View on HN

You'll also get major specificity issues when using element selectors with other class/id type selectors. My rule of thumb is classes and only classes for styling, it really makes life a lot easier. (Even if you have a unique element on the page, don't use the ID in your selector to style it.)

    <section class="body">
        <main class="content"></main>
        <aside class="sidebar"></aside>
    </section>

I have as a rule that if you are in a situation where there can only be 1 element with those properties (it would make no sense at all to have more), I should use the id.

The top elements are one example. It makes no sense to include them inside any other element, and if that ever changes, all the styling will need to change anyway.

What if you had a requirement to create variation styles of those elements? How would you do that? Would you add you base style in your id selector, and then variations with classes? Again, you'll face specificity issues with that approach. Keeping things simple is the best approach here IMO. I've done a heck-load of CSS and have seen how hacky a stylesheet can become because of specificity issues. Sticking with classes and keeping selectors short will make your stylesheet easier to follow and more maintainable, but this is just my approach!

> I have as a rule that if you are in a situation where there can only be 1 element with those properties (it would make no sense at all to have more), I should use the id.

Not a good idea: IDs take massive priority over classes in the cascade.

As someone who often has to override an enormous stylesheet which is all styled to IDs, this is a serious pain point.

Simple example: http://jsfiddle.net/B7tSz/

Totally agreed. And more generally, specificity is by far the most difficult challenge in large-scale CSS. Without discipline and some well-defined conventions for selector construction, you will end up with the equivalent of spaghetti code and late-nights deciphering unexpected cascading from other people's styles.

Since large projects will inevitably have to rely on non-semantic HTML and class names anyway (e.g. to differentiate between sibling <p> tags), a simple rule of thumb would be to only use class names in selector construction. HTML elements can still be semantic for other purposes, but the CSS should not care about it.

The other half of the specificity problem is nesting. I advocate strongly against the descendant combinator ` ` in favor of the child combinator `>`. E.g. `.body > .content` is much more robust than `.body .content`. However, an alternate approach would be:

    <section class="body">
        <main class="body-content"></main>
        <aside class="body-sidebar"></aside>
    </section>

Either way, don't leave it up to individual developers. This has to be adopted by the team.

Agree that structure-specific CSS is unwieldy. However, it's robustness is still a worthy benefit. If you use a white-space sensitive CSS preprocessor, it is not unwieldy, and actually quite maintainable and elegant, since it's structure reflects nicely-formatted HTML. E.g.

  main
    > section
      > main
        text-decoration blink

Thus, things that are easy to change in HTML structure (cutting, pasting, and changing indentation) are similarly easy to change in CSS.

Reply on news.ycombinator.com