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.

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.

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 :-)

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.

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.

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

• This PR is about updating Thai translation URL to a new URL.
• Thai translation URL has been changed to https://rscss.apirak.com/ and http://rscss.in.th/ does no longer exist

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; }
}

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.

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

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?

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.

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?

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.

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).

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 :)