CSS Naming Best Practice in MVC Layouts

Question

I need to create a CSS naming convention in an MVC Project with Layouts.

The use of Layouts creates the need to be very careful when it comes to choose the name of a class because it can be override by one declared in the Layout CSS file.

One rule I use is to have only element classes for style and element ID's for jQuery use.

Let say I have a layout like this:

<div class="lyb-ctn">
    <div class="lyb-wrp">

        @RenderBody()

        <div class="lyb-ctn-rgt">
            <div class="lyb-ctn-subscribe">
                <p class="lyb-ctn-subscribe-title">Subscribe</p>
                <input placeholder="Email" /><input type="button" />
            </div>
            <div class="lyb-ctn-categories">
                <p class="lyb-ctn-categories-title">Categories</p>
                <div class="lyb-ctn-categories-ctn-list">
                    <div class="category">
                        <p>Cars</p>
                        <p>Boats</p>
                    </div>
                </div>
            </div>
        </div>
    </div>
</div>

One option would be:

.lyb-ctn {
    position:fixed;
    padding:0px;
    margin:0px;
    width:100%;
    height:100%;
    background-color: #f2f2f2;
    padding-top: 50px;
}

.lyb-wrp {
    max-width: 960px;
    width: 95%;
    margin: auto;
    background-color: #ffd800;
}

.lyb-ctn-rgt {
    float: right;
    width: 235px;
    border: solid 1px #ff6a00;
}

.lyb-ctn-subscribe {
    width: 100%;
}

.lyb-ctn-subscribe-title {
    color: #80bd01;
}

.lyb-ctn-categories {
    width: 100%;
}

.lyb-ctn-categories-title {
    color: #80bd01;
}

I also build an other option but this one, I think, is dangerous because if it happens to exist a ".rgt-ctn" in the parent layout, it can override this one:

.lyb-ctn {
    position:fixed;
    padding:0px;
    margin:0px;
    width:100%;
    height:100%;
    background-color: #f2f2f2;
    padding-top: 50px;
}

.lyb-ctn .wrp {
    max-width: 960px;
    width: 95%;
    margin: auto;
    background-color: #ffd800;
}

.lyb-ctn .wrp .rgt-ctn {
    float: right;
    width: 235px;
    border: solid 1px #ff6a00;
}

.lyb-ctn .wrp .rgt-ctn .subscribe-ctn {
    width: 100%;
}

.lyb-ctn .wrp .rgt-ctn .subscribe-ctn .title {
    color: #80bd01;
}

Here is another one that seems clean but we can't see the hierarquy of the DOM when we look at it, and I think it maybe more difficult to find an element to edit:

.lyb-ctn {
    position:fixed;
    padding:0px;
    margin:0px;
    width:100%;
    height:100%;
    background-color: #f2f2f2;
    padding-top: 50px;
}

.lyb-wrp {
    max-width: 960px;
    width: 95%;
    margin: auto;
    background-color: #ffd800;
}

.ctn-side-options {
    float: right;
    width: 235px;
}

.ctn-subscribe,
.ctn-categories,
.ctn-tags {
    width: 100%;
}

.ctn-subscribe .title, 
.ctn-categories .title,
.ctn-tags .title {
    color: #80bd01;
    padding: 25px 0 10px 5px;
}

.ctn-categories .ctn-list, 
.ctn-tags .ctn-list {
    width: 100%;
    background-color: #fff;
    border: solid 1px #e6e6e6;
    border-radius: 3px;
    margin: 0;
    padding: 0;
}

Or is there a better approach?

Answer 1

TLDR : Get organised.

Firstly, I strongly recommend you read up on:

OOCSS - http://www.smashingmagazine.com/2011/12/12/an-introduction-to-object-oriented-css-oocss/

SMACSS - https://smacss.com/

and

BEM - http://csswizardry.com/2013/01/mindbemding-getting-your-head-round-bem-syntax/

Putting some effort into gaining an understanding of a modular approach to CSS at the start of a project will pay huge dividends as the project becomes larger. Having a strong naming convention will make life a lot easier if you are working on a project with two or more developers.

Next, if you aren't already doing so, it it well worth transitioning to a CSS pre-processor such as SASS - http://sass-lang.com/, LESS - http://lesscss.org/ or STYLUS - http://learnboost.github.io/stylus/

Using a pre-processor helps organisation because you can break your stylesheets into as many files as you want, then import them all into one at compile time to follow performance best practice. (See also - http://thesassway.com/advanced/modular-css-naming-conventions)

You mention you have a rule of only using classes as CSS hooks and IDs as JS hooks - this is a good start, however I recommend moving away from using IDs and move towards a js- prefixed class. In this way your JS also becomes re-usable.

The next thing to look at is creating a pattern library - a great example of this is Mailchimp's example - http://ux.mailchimp.com/patterns

So much for general guidance - how is all this relevant to:

"I need to create a CSS naming convention in an MVC Project with Layouts. The use of Layouts creates the need to be very careful when it comes to choose the name of a class because it can be override by one declared in the Layout CSS file."

You will see all of the above guides all aim towards organising your CSS (and JS) in to chunks of reusable code. The key to this is planning, and having a canonical reference for each chunk you are going to use - hence the pattern library.

In your example you might like to create a guide for each of your layouts - how is each layout used and how does / should it affect descendant content?

Where you want layouts to pro-actively influence their descendant content you will want to scope them. So wrap them in a class which can act as a namespace. I.e.

<div class="layout-one">[ALL DESCENDANT CONTENT HERE]</div>
.layout-one p {
    color: green;
}

<div class="layout-two">[ALL DESCENDANT CONTENT HERE]</div>
.layout-two p {
    color: red;
}

However, I take it your concern is more that your layouts are going to re-actively influence descendant content in a way which breaks your design. So scope any styles which relate only to the layouts but not the descendants more tightly.

Rather than: .layout-one p {} as above, go for .layout-one__p {}, .layout-one__h4 {}

As you can see this BEM inspired naming convention makes it immediately clear the the style in question is directly part of the layout. We would not expect to see this class being used outside of the layout HTML, so we can write styles without any concerns about them affecting descendant content.

Or, we can write styles within a layout's namespace and be sure that our styles will be affected as we want.