rstacruz / rscss

Reasonable System for CSS Stylesheet Structure

Viewing this from GitHub? Visit the website for the full experience. ricostacruz.com/rscss →

---

rscss

Styling CSS without losing your sanity

Reasonable System for CSS Stylesheet Structure.
A set of simple ideas to guide your process of building maintainable CSS.

Introduction

Any CSS greater than 1000 lines will get unwieldy. You'll eventually run into these common pitfalls:

• "What does this class mean?"
• "Is this class still being used?"
• "If I make a new class green, will there be a clash?"

rscss is an attempt to make sense of all these. It is not a framework. It's simply a set of ideas to guide your process of building maintainable CSS for any modern website or application.

Let's get started by learning about components. Continue →

---

rscss © 2015+, Rico Sta. Cruz. Released under the MIT License.
Authored and maintained by Rico Sta. Cruz with help from contributors (list).

ricostacruz.com  ·  GitHub @rstacruz  ·  Twitter @rstacruz

rscss's Issues

Consideration for prefixes

I've been using RSCSS exclusively in my latest projects, with great success. However, instead of using the two-word rule for components, I prefix all of my components, such as .my-button or .foo-modal.

This gives a few benefits:

• Namespacing - eliminates naming collisions
• Prefixes help easily identify which styles are "yours" rather than 3rd-party styles
• No more need to think of a two-name class. Prefixes are the first name.

What do you think? Maybe it's worth mentioning in the docs?

Pseudo selectors

Are pseudo-selectors like :nth-child ok? Or it is better to use variants (-top, -bottom)?

Extending variant depreciation

Using variants in the RSCCS guide, I expect to be able to extend a specific variant of a componant. Like so:

.bad-button {
  &.-red { background-color: red; }
  &.-large { font-size: 500em; }
}

.search-form {
  > .submit {
    @extend .search-button;
    @extend .search-button.-large;
    @extend .search-button.-red;
  }
}

.search-button {
  width: 100%;
  &.-red { color: red; }
  &.-large { font-size: 1000em; }
}

which produces, as expected:

.bad-button.-red { background-color: red; }

.bad-button.-large { font-size: 500em; }

.search-button, .search-form > .submit { width: 100%; }

.search-button.-red, .search-form > .submit { color: red; }

.search-button.-large, .search-form > .submit { font-size: 1000em; }

DEPRECATION WARNING on line xx of example.scss:
Extending a compound selector, .search-button.-large, is deprecated and will not be supported in a future release.
Consider "@extend .search-button, .-large" instead.
See http://bit.ly/ExtendCompound for details.

DEPRECATION WARNING on line xx of example.scss:
Extending a compound selector, .search-button.-red, is deprecated and will not be supported in a future release.
Consider "@extend .search-button, .-red" instead.
See http://bit.ly/ExtendCompound for details.

Okay, a depreciation warning from Dart Sass, even though it's exactly what I wanted. Let's see what happens when I follow the depreciation warning so this feature doesn't break my website in the future:

.bad-button {
  &.-red { background-color: red; }
  &.-large { font-size: 500em; }
}

.search-form {
  > .submit {
    @extend .search-button, .-large, .-red;
  }
}

.search-button {
  width: 100%;
  &.-red { color: red; }
  &.-large { font-size: 1000em; }
}

.bad-button.-red, .search-form > .bad-button.submit { background-color: red; }

.bad-button.-large, .search-form > .bad-button.submit { font-size: 500em; }

.search-button, .search-form > .submit { width: 100%; }

.search-button.-red, .search-form > .submit { color: red; }

.search-button.-large, .search-form > .submit { font-size: 1000em; }

Okay, it looks fine, but it looks like it's bleeding a bit. The extra rules are:

.search-form > .bad-button.submit { background-color: red; }

.search-form > .bad-button.submit { font-size: 500em; }

That doesn't look very dangerous. Does anyone see a concern? Was I worried for nothing?

If so, should the recommended syntax be added to the RSCCS nested components guide?

Pseudo selectors.

Since RSCSS is just a guideline, quite a bit of it is open to interpretation...

Should I delegate pseudo selector events like :hover, :active, and :focus to the elements themselves, or through a variant?

I feel like having them be declared through variants is the better option, but I'm not really a front-end expert.

Perhaps you could touch a little bit on them. I'd like to know a good style to declare them in since pretty much everything else defined in the guide I agree with and like.

Translation to spanish

Translate the docs to Spanish language

Propose a file structure

RSCSS has conventions on how to name your classes and so on, but doesn't really tell you how to organize your files in any way except "one component per file".

In my projects with RSCSS, it's often used with something like ITCSS (inverted triangle CSS), where we have:

@import './variables';
@import './base/*';
@import './components/*';
@import './mixins/*';
@import './helpers/*';

Where:

• variables - yep ($sans: 'source sans pro', sans-serif; $blue: #adf;)
• mixins - yep
• base - things that style bare tags (eg, h1 { font-size: 2.5em })
• components - actual components (eg, .photo-card { ... }) *
• helpers - helper classes (eg, ._nomargin { margin: 0 !important; })

(* The components tree usually gets split up per feature, eg, articles/ profiles/ and so on.)

This all mirrors ITCSS conventions, just with names that I believe are more friendly. (settings → variables, generic → base, trumps → helpers)

I think this should start being an official recommendation of RSCSS. anyone with any thoughts?

About nested components

Your structure does't work when we have nested components with same elements names.

.foo-1 {
  .bar {}
}

.foo-2 {
  .bar {}
}

.foo-1
  .bar
  .foo-2
    .bar

In this case selector .foo-1 .bar affects on "bar" element of "foo-2" component

In BEM it's fine

Suggestion for naming with multiple words to camelCase

http://rscss.io/elements.html#element-selectors

IMO I find it hard to read long class names that are not capitalized. Perhaps you should consider making multiple words to be in camelCase.

Projects that have used RSCSS

I am researching and currently looking for projects references that were implemented using the 'RSCSS'.

Analyze a greater volume of code would help me understand the implementation of the ideas with variations.

Create wiki

A wiki would be nice.

If you want, I could make it.

Question regarding documentation website

What did you use to build the site? It's awesome. From scratch?

Nesting Level Contradiction

At Variants of nested components, the article states not to reach in and use nesting to solve this issue.

.vote-box {
  &.-highlight {
    > .up { /* ... */ }
  }
}

Then at Avoid over-nesting, the article states one should avoid nesting more than 1 level deep. This would make the previous example incorrect and the following example correct which was stated as incorrect in the article.

.article-header {
  > .vote-box > .up { /* ✗ avoid this */ }
}

Could you add some clarification to this?

Tag selectors

What in case, that I have in some div many paragraphs or anchors, should I use class or tag selection?

<div class="header-text">
<p>Lorem</p>
<p>Lorem</p>
<p>Lorem</p>
</div>

.header-text {
    p { color: black; }
}

Or:

<div class="header-text">
<p class="paragraph">Lorem</p>
<p class="paragraph">Lorem</p>
<p class="paragraph">Lorem</p>
</div>

.header-text {
    .paragraph { color: black; }
}

Deny flex-item rules in components

I want to raise a question about flex-item rules.

I think that it's better not to use flex-item rules at least in default component state because component itself can't know if it will be used in flex-container or not, and even inside flex-container flex-item rules will have different behavior with different flex-container rules on component's parent (flex-direction, flex-wrap, ...)

I guess we should start recommending for flex-item rules the same approach as for positioning.

First, I want to discuss this question with community, maybe other solutions will be found. And then I can try to implement PR (or maybe someone with better English).

Add "Cannot start with two dash"

It would be better for you to add to "Why dash?".

...they cannot start with a digit, two hyphens, or a hyphen followed by a digit. ..
http://www.w3.org/TR/CSS21/syndata.html#characters

Nested components and how to handle interactive states (pseudo class)

I'm using RSCSS at work and in private for quite a while now and I really love it. Though there is one thing where I would like to receive some feedback from other users or the author.

How do you guys handle interactive states like :hover etc. between multiple components? Let me demonstrate it with a simple example.

.user-profile {}

.user-image {

    // the actual user image
    > .image {}
    > .caption {}

    // etc…
}

.user-details {
    > .name {}
    > .bio {}
}

<div class="user-profile">
    <div class="user-image">
        <img src="" alt="" class="image">
        <span class="caption">Lorem ipsum…</span>
    </div>
    <div class="user-details">
        <span class="name">John Doe</span>
        <span class="bio">What's up?</span>
    </div>
</div>

Now imagine I want to change the appearance of .user-details > .name and .user-image > .image when I hover .user-profile — remember this is quite a simple example. How do you guys do that? Is this the case where you break the rules and do something like this:

// …
.user-details {
    .user-profile:hover & > .name {
        // …
    }
}

Or do you handle it with JS? I know it's quite simple if we just talk about hover states on a single component, but when you need to change multiple nested components when a parent component is interacted with it's quite tricky I think.

So, how do you guys have solved this?

Integration of Bootstrap // custom Themes // JS Plugins

Hi guys!

We're using Twitter Bootstrap and a custom Theme for our Web App, but (or should I say "therefore") over time our CSS got really messy and so we are looking into Object Oriented CSS to solve our CSS issues.

At the moment, our HTML is full with Bootstrap classes and classes from our theme, which both are used by some Java Script functions. This makes it hard for us to simply replace these class names with rscss-style class names.

Can you provide any advice how to move forward from our situation? Also for the future, how do you integrate predefined plugins into your OOCSS and how do you handle updates of frameworks you use?

Thanks for any help and best regards,

Daniel

What to do in this case?

Hey, great project!

I've a navbar with two rows and each row has columns.

Is this correct or should I use something different?

.top-navbar
  .subnavbar-one
    .column
    .column
  .subnavbar-two
    .column
    .column

How can I style deeply nested HTML elements using RSCSS?

Heya!

I'm not sure how to organize my components and/or elements when I have deeply nested components and I'm not really allowed to use the > CSS selector component.

For ex., I have the following markup:

<div class="question-box">
  <h1 class="title">My Question App</h1>
  <form>
    <div class="avatar">
      <img (...)>
    </div>
    <div class="question">
      <h2>Who's the one on the photo?</h2>
      <ul>
        <li class="answer">
          <input type="radio" id="option-1">
          <label for="option-1">Option #1</label>
        </li>
        <li class="answer">
          <input type="radio" id="option-2">
          <label for="option-2">Option #2</label>
        </li>
        <li class="answer">
          <input type="radio" id="option-3">
          <label for="option-3">Option #3</label>
        </li>
      </ul>
      <button class="submit" type="submit"></button>
    </div>
  </form>
</div>

In this case, I have a .question-box component, which holds the entire markup, and I have elements that are nested with multiple levels. For example, I need to keep a <form> element for HTML validation purposes, but then I'm unable to use the > CSS selector.

So, I would like to know how you have been tackling scenarios like this one :-)

Protuguese Translation

Translated to portuguese (brazilian portuguese).
it's on the following link https://silvamateus.gitbooks.io/rscss/content/

Comlpex Components

I'm trying to get my head around this so I can start using this with some of my projects. I was just starting to work on refactoring my base files to use this system, and I immediately ran in to a fairly major problem: How should I go about styling complex components?

For example, I may have this HTML for a gallery component:

<div class="gallery-block">
    <div class="imagelist">
        <figure class="figure -active" data-img="1">
            <img class="image" src="http://placehold.it/600x600" />
        </figure><!--/.figure-->
        <figure class="figure" data-img="2">
            <img class="image" src="http://placehold.it/600x600" />
        </figure><!--/.figure-->
        <figure class="figure" data-img="3">
            <img class="image" src="http://placehold.it/600x600" />
        </figure><!--/.figure-->
    </div><!--/.imagelist-->
    <menu class="thumbnaillist">
        <li class="thumbnailitem -active"><button class="button" data-img="1"><img class="thumbnail" src="http://placehold.it/100x100" /></button></li>
        <li class="thumbnailitem"><button class="button" data-img="2"><img class="thumbnail" src="http://placehold.it/100x100" /></button></li>
        <li class="thumbnailitem"><button class="button" data-img="3"><img class="thumbnail" src="http://placehold.it/100x100" /></button></li>
    </menu><!--/.thumbnaillist-->
</div><!--/.gallery-block-->

I'm getting confused about how i should go about styling something as deep as my .image or .thumbnail in this instance. Would it be something like this?

.gallery-block {
    & {
        /* some styles */
    }

    > .imagelist {
        /* some styles */
    }

    > .imagelist > .figure {
        /* some styles */
    }

    > .imagelist > .figure.-active {
        /* some styles */
    }

    > .imagelist > .figure > .image {
        /* some styles */
    }

    > .thumbnaillist {
        /* some styles */
    }

    > .thumbnaillist > .thumbnailitem {
        /* some styles */
    }

    > .thumbnaillist > .thumbnailitem > .button {
        /* some styles */
    }

    > .thumbnaillist > .thumbnailitem > .button > .image {
        /* some styles */
    }
}

Or is that over complicating things? Would be nice if you could put up a sample project somewhere for us to peruse :)

Naming mixins

So, I have a generic btn mixin.

@mixin btn() {
  /* */
}

How do you suggest I name its modifiers? Or should I just accept arguments?

Project state

Sad to see that this awesome project was abandoned 😢

Advantages over SuitCSS and SMACSS?

What might be the advantages of using rscss over other systems like SuitCSS and SMACSS:
http://suitcss.github.io/
https://smacss.com/

Class for namespace?

Hi,

Why not add in the RSCSS "specification" or whatever you want to call it a syntax for namespace classes?

When working on customising specific parts of an existing website with a very large CSS code base, it is often a bad idea to directly modify the original CSS file directly (especially when this one is very messy) as this can lead to unforeseen consequences. In my case, I decided to go with an additional style-sheet using RSCSS just to style the custom components I create.
The original CSS can override the styles I create, because it does not use RSCSS hence its selectors have more priority over mines. This is easy to fix with helpers. The real problem is: it can apply additional style to elements I do not want to specify properties for.
For example, let's say I have a .link element. When hovered, the .link needs to be underlined. Now the original style might define a background for hovered a elements. I don't want that. I might just override the background value with another one like background-color: transparent; or background: none;. But what if a .link element needs to have a background when focused? This would mean my .link elements would not have a background when they are focused and hovered in the same time, which is not what we want.
One solution for this is to edit the original CSS file, and one way to do it in a very safe way is to use the :not selector.
However, when dealing with a very large number of elements, this leads to very lengthy list of :not selectors.
So, why not allow, in the RSCSS specification, a way to namespace any kind of component or element? For example, we could add. __my-namespace to any element or component which would only be used as a way to prevent certain properties from being applied to the element/component. In the original stylesheet, we would just need to add :not(.__my-namespace).

Advise against using '&-modifier'

As this makes search for selectors quite a pain in most if not all editors.

As much as i like this approach it makes refactoring a bit of a nightmare.

Is it typo on nested-components.md?

Hi,

I may found a typo on nested-components.md.
This is below:

---

.article-header {
  > .vote-box > .up { /* ✗ avoid this */ }
}

Instead, prefer to add a variant to the nested component and apply it from the containing component.

<div class='article-header'>
  <div class='vote-box -highlight'>
    ...
  </div>
  ...
</div>

---

"article-header" shall be "article-link".
If you don't mind this, I would fix typos.
See #83.

Overuse of child selectors (>) make refactoring a nightmare

I really want to love this, it is really close to many of the things I like. But there is way too much use of direct child selectors. The CSS should not be so heavily tied to the DOM structure, plus they increase specificity, which is best to keep as low as possible. Yes, you have to give up the potential of having nested class names, but that seems like an anti-pattern.

From the MDN section on efficient CSS:
Tag category rules should never contain a child selector
Avoid using the child selector with tag category rules.

and

Question all usages of the child selector
Exercise caution when using the child selector. Avoid it if you can.

While I know that specific article was written a while ago, there is still the argument that the child selectors too tightly ties to the DOM structure. Sometimes you may not have 100% control of the markup (i.e. when writing templates for a CMS) or you may want to refactor the HTML. Child selectors make that extremely difficult. I don't believe the benefits of using the child selector outweigh the maintainability issues using them presents.

How to handle nesting with grid css

Hey!

So I've been using rcss lately and really enjoying it. I find it really whittles my markup down to a more pure, readable structure.

That being said I've hit a bit of a speed bump with the way I would normally integrate layout (grid and flex) behaviour because when used within components theres often the need for an extra level of nesting in order to account for it, so what would ordinarily be direct descendants are now nested another one or two levels deep.

Take for example a form that consists of multiple steps, each step displayed within a nested component. Step 1 might look like this:

It kind of presents the issue whereby the nested element defines the layout of the elements of the parent.

    <form action="..." class="ui-form">

      {{#if step1}}

        <div class="ui-panel -split">

          <fieldset class="formsection">
            <input type="text" name="firstname" class="field">
            <input type="text" name="lastname" class="field">
            <input type="text" name="username" class="field">
          </fieldset>

          <div class="formsection">
            <img src="images/avatar.png" class="image -profile">
            <input type="file" name="avatar" value="" class="field">
          </div>

        </div>

        <div class="_right">
          <button class="ui-button -step">Next</button>
        </div>

      {{/if}}

      {{#if step2}}

        <div class="ui-panel">
          <fieldset class="formsection">
            <textarea type="text" class="field -multiline"></textarea>
          </fieldset>
          <button type="submit" class="ui-button -submit" value="Submit">Submit</button>
        </div>

      {{/if}}

    </form>

    <style>

      .ui-panel {
        background: #999;
        border-radius: 8px;
      }

      .ui-panel.-split {
        display: grid;
        grid-template-columns: 1fr 1fr;
      }

      /*
        In order for styling to be consistent across all forms this would
        have to be the rule because formsection is not a direct decendant
        of ui-form in this case
      */
      .ui-form .formsection {
        /* This is against the rules, right? */
      }

      .formsection > .field {
        /* This is fine */
      }

    </style>

There's probably a better way to do this that avoids this problem but in trying to adapt my past approach to this kind of pattern I wasn't quite sure what a robust solution might be that is within the conventions of rcss.

Recommended way to handle variants of variants?

I'm a little confused about how to handle variants of variants in a good way. This probably isn't that common, but sometimes it's nice to have a variant with some options too.

---

This is the best way I could think of handling it, but there's a rule about how not to use dashes in variant names. Maybe this could be a use case?

.component-name {
  &.-variant {
    padding: em($padding);

    &-large { @extend #{&}; @include scale(1.5); }
    &-small { @extend #{&}; @include scale(0.75); }
  }

  &.-another {
    // ...
  }
}

<div class='component-name -variant'></div>
<div class='component-name -variant-small'></div>
<div class='component-name -variant-large'></div>

---

This is another way but this could be confused about what is a modifier of what...

.component-name {
  &.-variant {
    padding: em($padding);

    &.-large { @include scale(1.5); }
    &.-small { @include scale(0.75); }
  }

  &.-another {
    // ...
  }
}

<div class='component-name -variant'></div>
<div class='component-name -variant -small'></div>
<div class='component-name -variant -large'></div>

Child variants

I'm into utility classes. How do I write the clearfix hack with this guide? Given that this implementation usually consists of 3 classes, clearfix, left, and right (left and right being the Child invariants (not sure what to call them)).

I find the example below okay.

.u-clearfix
  //

  .-left
    float: left;

  .-right
    float: right;

But I thought maybe we could use double hyphens (--) to indicate child variants, like the refactor below:

.u-clearfix
  //

  .--left
    float: left;

  .--right
    float: right;

Question: Are these examples for SASS only?

Hello!

I was wondering if the examples in this repo are meant for SASS only. I never tried it so I can't recognize its syntax, but the nesting, classes beginning with "&." and things like that don't seem like regular CSS (Although it might simply be things I didn't know about !)

Thanks

Starting classes with - (hypen) not advised

I'm glad you address that "starting classes with a hypen" may be hard for some to do. Either as an additional caveat in that section, or perhaps to consider revising altogether, it should be noted that per the CSS spec, while it is valid to start a class with a hyphen, it limits your next character to a letter.

In CSS, identifiers (including element names, classes, and IDs in selectors) can contain only the characters [a-z0-9] and ISO 10646 characters U+00A1 and higher, plus the hyphen (-) and the underscore (_); they cannot start with a digit, or a hyphen followed by a digit.

There could also be confusion with the recommendation that beginning a identifier with a hyphen be reserved in keywords and property names, but that doesn't specifically apply to classes.

In CSS, identifiers may begin with '-' (dash) or '' (underscore). Keywords and property names beginning with '-' or '' are reserved for vendor-specific extensions.

Nested components and fallback fonts for web fonts

Hello,

We're trying out font loading using the technique described in this article:

https://www.filamentgroup.com/lab/font-events.html

Basically, the html or body element gets a class applied to it after a JS library has determined that a web font has been loaded.

In our case, we're loading 2+ web fonts. For example:

/* This would work for something like the body element itself */
.site-root {
  & {
    font-family: serif;
  }

  &.-webfontloaded {
    font-family: 'Font A';
  }
}

/* Not sure about this */
.meta-data {
  & {
    font-family: sans-serif; /* Note: different than root element */
  }
}

.site-root.-webfontloaded {
  .meta-data {
    & {
      font-family: 'Font B';
    }
  }
}

In this example, I don't know the nesting relationship between .site-root/body and the .meta-data element so I don't think I can use >. With the above I'm receiving the following lint message:

Descendant combinator not allowed: '.webfonts-loaded .meta-data'   rscss/no-descendant-combinator
Invalid element name: '.meta-data'

Do you guys have any recommendations on how to structure this or any other font techniques that have worked for you? One thing I considered was keeping track of elements with web fonts different than the body and then applying a variant class to them in the JS.

Thanks!

About Simplifying nested components

In section Simplifying nested components the example given is this:

<div class='search-form'>
  <input class='input' type='text'>
  <button class='search-button -red -large'></button>
</div>

It curious how the "search button" is labeled as a component (or a nested component in this example) rather than an element, such as:

<div class='search-form'>
  <input class='input' type='text'>
  <button class='searchbutton -red -large'></button>
</div>

... and then for the solution it's "converted" to an element with class submit. This is pretty confusing, because the solution not only suggesting using @extend, but also refactors the DOM. I know you shouldn't reach into nested components however, so the following is not good:

.search-form {
  > .search-button { /* ... */ }
}

But then I don't quite follow how good is @extend as a solution to a non-problem in the first place. I am pretty confused.

I guess my question is pretty much aligned with #9 at this point, although I would like to hear more on this.

Thanks

Search not working

There's a magnifying glass icon on the menu near the "rscss" heading. I assume this is a search function but clicking on it does nothing.

RSCSS vs SMACSS

Good day!

Can you compare RSCSS with SMACCS, please? I want to talk about differences...

Thanks!

New chapters to write

It's probably time to extend this guide with more specific guidelines on scenarios that people want to hear more from.

• On @extend and refactoring them to mixins
• On structuring your components, layouts, and helper files
• Avoiding > selector overcomplexity (#7)
• Add notes on using preprocessors (#3)
• Add guidelines for writing responsive media queries (#27)

The recomendations of @extend are concerning

I like what you've got going here, but by using @extend when nested inside a descendent selector, the final comma separated CSS selectors can be a nightmare. Keeping final CSS output in mind is vital to successfully scaling any CSS/Sass solution.

If you're going to use @extend in different files for different components, then the final CSS selector can not only be a mess of selectors, but you also potentially create a relationship between classes that shouldn't have a relationship. You've advised putting all components in their own file (nice), but by linking classes via @extend then your final CSS and selectors are no longer grouped by component only; they're also grouped by some shared properties.

If you've decided that you want all the CSS properties of a class, then just add the class to the component instead of using @extend. You're final CSS output will be smaller, there's less need for sourcemaps to figure out where a rule came from (actually, I don't even know how well source maps deal with @extend to be honest), and the HTML becomes much clearer to any developer that views it.

Ignoring that .search-button wouldn't be an ideal class name in the first place here, the HTML in your @extend example might become something like:

<div class='search-form'>
  <input class='input' type='text'>
  <button class='submit search-button -red -large'></button>
</div>

Print media CSS for styled components, any suggestions?

Great list so far!

So anything additional for dealing with print media? same file, new file? Any organisational suggestions? We seem to find an increased use of !important in print media styling.

Perhaps the same question goes to any media for responsive layouts maybe.

Layout components should have a prefix

Layout components should explicitly start with a prefix (like on SMACSS).
Areas may also be defined as well.

Apart from separating concerns, a nice feature would be "enabling" outline on areas of a layout. With that, would be easier to visualize and separate your components when creating a component library.

So this outline you have manually created could actually be automatically created based on [class^=l-]

IE ignoring classes starting with dashes?

Anyone else having problems with class names starting with a "-" (dash) in IE? Any class starting with "-" just get ignored.

CSS Structure: About glob matching for Less

Chapter: https://github.com/rstacruz/rscss/blob/master/docs/css-structure.md#use-glob-matching

Maybe add information about Less?

https://github.com/just-boris/less-plugin-glob

Any automatic checker/linter tools?

I open this issue to research any tools that could automatically check if my styles are rscss-compliant.

Maybe a fork of https://github.com/postcss/postcss-bem-linter would do?
Maybe https://github.com/brigade/scss-lint with some custom config?

This is important for me, because there are many people working on styles in my project and I know that without a tool I can plug to CI build, we will eventually diverge from the rscss standard. I think that this will also be useful to other people using rscss.

And if as a result of discussion here we find some solution, I believe it'd be definitely worth putting in the README.

RSCSS example sites

I want to have a section that showcases RSCSS-based codebases.

Here are some of mine:

• https://github.com/rstacruz/hledger-vis/blob/master/assets/css
• https://github.com/rstacruz/til/tree/gh-pages/_sass (http://ricostacruz.com/til)
• https://github.com/rstacruz/bcds/tree/master/sass (http://bcds.design)

Here are some from others I've found through a GitHub search:

• https://github.com/jeroenvisser101/rscss-demo
• https://github.com/rogerhutchings/hb-rog

Homepage logo/search icon

Found the magnifying glass icon on the rscss page rather confusing. Might just be a personal preference, but I expected it to open some sort of search functionality.

PR for clarify variant naming

Dear @rstacruz

Thank you so much for making RSCSS. It is such a good naming/guideline for CSS. I like it a lot.
However, I would like to make a PR to clarify variant naming. This is because:

Given:

• A variant class name can only start with a letter _ or - but dash are is easier to type than underscores so dash is preferred.

Therefore:

• These are valid variant names: -big, -disable, _wide, _active.

However, it is not clear to me how we name it if its name is longer than one word.
I have noticed that we use an underscore prefix for a helper and it can have dash in a middle name e.g. _pull-right

With this fact, we can distinguish variant naming by merging multiple word to one word and not use dash in a middle.
Do it like what we do for element naming.

FYI, the current document of variant can lead to misnaming convention if someone see the last example word -emit-last in this sentence.

It kind of resembles switches in UNIX commands (gcc -O2 -Wall -emit-last).

For your consideration, if I understand it correctly, please confirm it to me.
I am happy to create a PR to add a multiple words section in variant like what we have done in Elements section.

On multiple words
For a variant that need two or more words, concatenate them without dashes or underscores.

.shopping-card {
  > .title { /* ... */ }
  > .title.-small { /* ... */ } 
  > .title.-largeunderline { /* ... */ }
}

Thank you.

AMCSS

What do you think about http://amcss.github.io/? I think that it might work quite well with rscss and lead to even cleaner code. Examples of the combination could be added to the docs :)

Conventions about space between blocks?

I think it would be useful to define some conventions about the spaces between code block in SASS and LESS.

For example:

.my-component {
  color: blue;
  > .element1 {
    color: blue;
    &.-active {
      color: blue;
    }
  }
  > .element2 {
    color: blue;
  }
}

or

.my-component {
  color: blue;

  > .element1 {
    color: blue;
    &.-active {
      color: blue;
    }
  }

  > .element2 {
    color: blue;
  }
}

?

About FIle Structure

I have some concerns about the recommended file structure for big projects. Im starting one now and Im trying to use RSCSS but i`m struggling with the file structure. The guidelines talk about making one file per component. While this makes sense for me for small/medium projects, sounds like a nightmare for big web applications. Is there any other recommendations, like putting layouts in another folder? combining some components in the same file? Or any other thing that could help