• David BachmannDavid Bachmann, over 5 years ago


    4 points
  • Diederik EenschootenDiederik Eenschooten, over 5 years ago

    As a front-ender I don't really agree on all points. I agree with the part of the specific nesting. Nav A will do.

    But i'm not a huge fan of giving every single element a class. But hey, that's just my opinion

    1 point
    • Ashley Watson-NolanAshley Watson-Nolan, over 5 years ago

      I definitely don’t think you have to do this on every element, but it can help as your sites scale to give clearer hierarchy to modules.

      It’s useful to provide flexibility as modules change over time too.

      0 points
  • Bennett WongBennett Wong, over 5 years ago (edited over 5 years ago )

    Not a bad read. I find it's hard to mandate a team to follow any specific rules or style when writing any code, but Chris Coyier's Sass style guide is generally a good guide.

    His take on specificity is just: - Maximum nesting should be 3 levels deep - Maximum nested code shouldn't exceed 50 lines

    All of the other stuff about consistency and !important is valid, but there is an optimum point between being hygenic with your code and wasting too much time being too pedantic setting up rules to follow.

    I think a crucial part of keeping CSS / Sass clean is setting up a clear process for a team on what to drop in the icebox file (Coyier calls it the 'shame.scss' file) and how to integrate these embarassing bits into the core - after all, these weak, embarassing bits largely define how good your CSS is actually organised - anyone can write amazingly neat CSS if the project is simple or organised enough to allow that naturally, but that rarely happens when you have more than a handful of stakeholders, large sites with dark patterns, responsive / adaptive layouts.


    0 points
  • James ColemanJames Coleman, over 5 years ago

    Nice write up, Ashley. We've recently tried to tackle our variable issue, which is one you've raised but didn't really talk about.

    $white: #FFF; $white-dark: #AAA; $white-dark-2: #CCC;

    We all understand why that is wrong, but what's the alternative in your eyes?

    We're going down the path of using the actual color name, so:

    $color-white: #FFF; $color-silver-chalice: #AAA; $color-silver: #CCC;

    And then at the top of each individual file, we assign the color variable to a more descriptive variable, like $color-headings-hover: $color-silver.

    Variables are important to us - the manipulation we apply to rgba is highly beneficial. Also, we have one scss file per component, so sharing the color palette across all of our components with a central place to update is handy.

    0 points
  • Jodi WarrenJodi Warren, over 5 years ago

    Good post.

    On the point of @extends, I try to mostly @extend from a non-semantic %class, which means that it should (hopefully) not be added to with fussy object-specific properties.

    I'm stunned you're seeing any use of !important at all. The only use case I can think of are overriding some inline styles.

    0 points
    • Ashley Watson-NolanAshley Watson-Nolan, over 5 years ago

      Bizarrely, !important is one of the more frequent things that crop up – I was pretty surprised too.

      Only reasonable explanation I can think of is that some freelancers feel under the cosh to get bugs fixed towards the end of a project and know they won’t need to maintain the code. No real excuse though – it doesn’t happen much anymore internally as people know how much I hate seeing it…!

      0 points
      • Tom HareTom Hare, over 5 years ago

        It's definitely a lazy quick fix if they're dotted about the place but !important has its uses if used correctly.

        Utility classes (width classes or .text-left, for example) are a good use-case where !important is handy as you're unlikely to have the required level of specificity to enact a change from just the class alone.

        0 points