RSCSS (github.com)

over 7 years ago from , UI Designer & Front End Developer


  • Jens K., over 7 years ago (edited over 7 years ago )

    I wholeheartedly disagree with most of these points, mostly because they don't fix the problems he stated. Let me comment on your statements point-by-point:

    Think in components: I agree with this one:)

    Child elements of component should only have one word: I don't think this is a very scalable solution:

    • This makes your CSS slower because browsers read the CSS document from right-to-left instead of left-to-right. So when having the code .search-form .field it first looks for all .field classes, and then looks at .search-form.
    • This makes your code very hard to search through, especially when having a very large codebase. .title could match for hundreds of CSS elements, while .search-form__title will probably match only one (if not, you didn't name your code correctly).
    • This creates over-nesting
    • Clashes with other sub-components when having a large codebase. Your tip for using descendant selectors everywhere indicates a clear problem.

    Instead of this, use BEM. This creates a readable format for CSS classes that is easy to search, requires no nesting and is very fast. Clashes are a thing of the past.

    One component per file: Although I agree, I do think it's better to not just throw all components in a single "components" folder. With a large codebase you will probably get different types of component, which you might want to split up.

    Use @extend to simplify nested components: This is another pitfall of just using single-worded CSS classes. Use BEM for this and make sure you're using @extend in the way it was supposed to: http://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/

    Avoid over-nesting: This is ironic, because your tips creates the problem of over-nesting. Your proposal is a hack that can be prevented by using something like BEM.

    But dashes suck: No they don't, but that's probably a personal preference.

    Solutions for the stated problems: The following problems were stated:

    Any CSS greater than 1000 lines will get unwieldy. You'll eventually run into these common pitfalls: 1. "What does this class mean?" 2. "Is this class still being used?" 3. "If I make a new class green, will there be a clash?"

    Solutions: 1. Use BEM and common sense to name your CSS elements. If you don't understand, you're not naming your elements right. 2. Fix this with automated linters and integrate this into your CI builds. Or just do a quick search with your code editor. 3. Not if you name your elements correctly.

    2 points
    • Jim SilvermanJim Silverman, over 7 years ago

      Avoid over-nesting: This is ironic, because your tips creates the problem of over-nesting. Your proposal is a hack that can be prevented by using something like BEM.

      a single level of nesting within a single component is fine. it's a simpler and cleaner solution, imo. deeper nesting is what can create scalability issues. if anything, BEM's flat hierarchy feels like a hack of the way CSS was intended to be used.

      personal preference, i guess.

      2 points
      • Jens K., over 7 years ago

        I think LESS/SASS changed the way we write CSS, and I think that's not bad. It's the same how I feel about BEM: it has changed the game, but for the good. Especially now that SASS has a tighter integration with BEM that allows us to write BEM like this:

        .component { // Style &__element { // Style } &--modifier { // Style } }

        which compiles to this CSS:

        .component { // Style } .component__element { // Style } .component--modifier { // Style }

        Great things are happening in the world of CSS.

        1 point