Skip to content

Instantly share code, notes, and snippets.

@cblanquera
Last active December 5, 2017 05:53
Show Gist options
  • Save cblanquera/6194f09e9c20087af18a95ab735a8c2d to your computer and use it in GitHub Desktop.
Save cblanquera/6194f09e9c20087af18a95ab735a8c2d to your computer and use it in GitHub Desktop.
Front End Style Guide Recommendations

1. HTML Style Guide

The purpose of this style guide is to improve code quality by documenting a set of expected rules that can consistently apply across all projects. The main benefits are the following.

  • Easier for new developers to on board on a project
  • Easier to troubleshoot code across different projects
  • Easier to contribute additional code
  • Easier to adjust for SEO across all projects
  • Easier to identify strategy and logic that can be applied to different projects

The following helps navigate through these guidelines.

1.1. Typography

Do not use all uppercase text.

This is correct

Cum sociis natoque

This is correct

cum sociis natoque

This is correct

Cum Sociis Natoque

This is incorrect

CUM SOCIIS NATOQUE

1.2. Spacing and Overflows

Generally, do not exceed 80 characters per line. Most IDEs already made visible the overflow line. Inline text such as <p>Inline Text</p> is acceptable so long as it does not exceed the overflow line.

Text that cannot fit inline should be brought to the next line such as the following.

This is correct

<p>
    Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
    penatibus et magnis dis <strong>parturient montes</strong>, nascetur
    ridiculus mus. Nullam id dolor id nibh ultricies vehicula.

    Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
    ridiculus mus.
</p>

This implies that text that needs to be overflowed should not start with their parent tag. In other words the following is NOT allowed.

This is incorrect

<p>Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
penatibus et magnis dis <strong>parturient montes</strong>, nascetur ridiculus
mus. Nullam id dolor id nibh ultricies vehicula.

Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
ridiculus mus.</p>

The <strong> tag in the above example since it is an inline tag, should also be treated as inline.

This is incorrect

<p>
    Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
    penatibus et magnis dis
    <strong>parturient montes</strong>,
    nascetur ridiculus mus. Nullam id dolor id nibh ultricies vehicula.

    Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
    ridiculus mus.
</p>

The correct example above does imply that when opening a new tag, its content should be tabbed with 4 spaces like the following example.

This is correct

<div>
    <span>Cum sociis natoque penatibus et magnis dis</span>
</div>

However if it can still fit within 80 characters the following the acceptable.

This is correct

<div><span>Cum sociis natoque penatibus et magnis dis</span></div>

This is incorrect

<div><span>Cum sociis natoque penatibus et magnis dis parturient montes
nascetur ridiculus mus.</span></div>

1.2.1. Long Attributes

When dealing with tags having a lot of attributes, you should drop and tab each attribute. The closing tag should be separated in a new line.

This is correct

<a
    class="post-like"
    data-do="post-like"
    data-id="123"
    data-on="click"
    href="javascript:void(0)"
    title="This will send your information to the Job Seeker"
>
    Click Me
</a>

This is correct

<img
    alt="Logo"
    src="logo.png"
    width="200"
/>

This is incorrect

<a class="post-like" data-do="post-like" data-id="123" data-on="click" href="javascript:void(0)" title="This will send your information to the Job Seeker">
    Click Me
</a>

This is incorrect

<a class="post-like"
    data-do="post-like"
    data-id="123"
    data-on="click"
    href="javascript:void(0)"
    title="This will send your information to the Job Seeker">
    Click Me</a>

This is incorrect

<img src="logo.png"
    alt="Logo"
    width="200" />

1.3. Tags

When laying out a page, or laying out a block take advantage of <header><aside><section><footer> where applies.

Page
------------------------------------------------
|                                              |
|                  Header                      |
|                                              |
------------------------------------------------
|                   Body                       |
|  ------------------------------------------  |
|  |     ASIDE     |        SECTION         |  |
|  |               |                        |  |
|  |  -----------  |  --------------------  |  |
|  |  |         |  |  |                  |  |  |
|  |  | BLOCK 1 |  |  |    ARTICLE 1     |  |  |
|  |  |         |  |  |                  |  |  |
|  |  -----------  |  --------------------  |  |
|  |               |                        |  |
|  |  -----------  |  --------------------  |  |
|  |  |         |  |  |                  |  |  |
|  |  | BLOCK 2 |  |  |    ARTICLE 2     |  |  |
|  |  |         |  |  |                  |  |  |
|  |  -----------  |  --------------------  |  |
|  ------------------------------------------  |
|                                              |
------------------------------------------------
|                                              |
|                  Footer                      |
|                                              |
------------------------------------------------

Article tags <article> should be used to explain content sections. This means, you should use article even when describing a post, product, event etc.

1.3.1. Block and Inline

Under no circumstance should a block tag be found in an inline tag.

This is correct

<h3><a href="#">A good example</a></h3>
<p><span>A good example</span></p>

This is incorrect

<a href="#"><h3>A bad example</h3></a>
<span><p>A bad example</p></span>

Additionally, paragraph tags should not have block tags.

This is incorrect

<p><h3>A bad example</h3></p>
<p><div>A bad example</div></p>

1.3.2. Self Closing

Self closing tags should have a space followed by a forward slash.

This is correct

<hr />
<br />
<img alt="" src="" />
<input />

This is incorrect

<hr>
<br>
<img alt="" src="">
<input>

1.3.3. Headers

Headers are used to help outline a page; to help figure out the important parts of a page there by help making it possible to summarize its content.

There should be no more than one <h1> tag per page. Otherwise, there can be multiple instances of header tags, but do not skip header numbers. For example if there is an <h3>, you should also have an <h2>. Header text should be less than 140 characters.

This is correct

<h2>Nullam Quis Risus Eget Urna</h2>

This is incorrect

<h2>
    Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
    penatibus et magnis dis <strong>parturient montes</strong>, nascetur
    ridiculus mus. Nullam id dolor id nibh ultricies vehicula.

    Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
    ridiculus mus.
</h2>

Headers should be treated as subject titles. This implies that the text found inside headers should follow a titling convention.

This is correct

<h2>A Major Title in Example</h2>

This is incorrect

<h2>a major title in example</h2>

This is incorrect

<h2>A MAJOR TITLE IN EXAMPLE</h2>

The above implies that no all caps is incorrect. If there are styles that require the text to be in all caps, you can do so in CSS instead.

1.3.4. Links

All link tags should have the title="" attribute. Titles should not exceed 140 characters.

1.3.5. Images

All image tags should have the alt="" attribute. Alts should not exceed 140 characters.

1.3.6. Line Breaks

Break Tags <br /> are only allowed if it is between text.

This is correct

<p>Nullam quis risus eget urna <br /> mollis ornare vel eu leo.</p>

This is correct

<span>
    Nullam quis risus eget urna
    <br />
    mollis ornare vel eu leo.
</span>

This is correct

<div>
    Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
    penatibus et magnis dis <strong>parturient montes</strong>, nascetur
    ridiculus mus. Nullam id dolor id nibh ultricies vehicula.
    <br />
    Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
    ridiculus mus.
</div>

Do not use <br /> to space blocks. Use CSS instead.

This is incorrect

<div>
    Nullam quis risus eget urna mollis ornare vel eu leo. Cum sociis natoque
    penatibus et magnis dis <strong>parturient montes</strong>, nascetur
    ridiculus mus. Nullam id dolor id nibh ultricies vehicula.
</div>
<br />
<div>
    Cum sociis natoque penatibus et magnis dis parturient montes, nascetur
    ridiculus mus.
</div>

The horizontal ruling tag <hr /> is used to define a thematic change in the content. Like break tags, do not use it to space blocks.

This is correct

<h1>HTML</h1>
<p>HTML is a language for describing web pages.....</p>

<hr />

<h1>CSS</h1>
<p>CSS defines how to display HTML elements.....</p>

1.3.7. Scripts and Styles

All stylesheet tags <link> should have an href, rel and type attribute. Script tags <script> should have at least a type attribute.

This is correct

<link href="/custom.css" rel="stylesheet" type="text/css" />

This is correct

<script type="text/javascript"></script>
<script type="text/javascript" src="custom.js"></script>

This is incorrect

<script src="custom.js"></script>
<script></script>

1.3.8. HTML 4

Usage of <b> to bold, <i> for italics, <s> to strike out are prohibited. Please find their HTML5 and/or CSS3 equivalents. Do not use <font> under no circumstances.

1.4. Attributes

Attribute values should be within double quotes at all times.

This is correct

<input value="4" />

This is incorrect

<input value='4' />

This is incorrect

<input value=4 />

Attributes should placed in alphabetical order.

This is correct

<input class="form-control" name="post_count" type="text" value="4" />

This is incorrect

<input name="post_count" class="form-control" value="4" type="text" />

1.4.1. IDs

IDs should have unique values per page. IDs should only be used when dealing directly with javascript. You should not add styles to IDs; use classes instead. ID values should use all lowercase and dashes to separate words.

This is correct

<div id="unique-id-1"></div>
<div id="unique-id-2"></div>

This is incorrect

<div id="unique_id_1"></div>
<div id="unique_id_1"></div>

1.4.2. Classes

You should not use classes to indicate a particular style change. The following describes what classes not to use.

This is incorrect

<div class="pad-top margin-bottom center"></div>

Exceptions are usage of classes already defined in Twitter Bootstrap. The following for example is acceptable, however you want to try as much as possible to try other ways.

This is acceptable

<div class="pull-right pull-left text-success"></div>

Classes should have meaningful names and minimized as much as possible. If a class has more than 5 names, you should reconsider and organize your styles. Class names should be unique enough to group HTML while considering its use across the entire site.

This is correct

<h3 class="post-title">Some Title</h3>

This is incorrect

<h3 class="title">Some Title</h3>

As implied above it is best practice to describe each class name with at least two words. Class names should use all lowercase and dashes to separate words.

This is correct

<div class="post-summary"></div>

This is incorrect

<div class="post_summary"></div>

This is correct

<div class="post-item">
    <h3 class="post-title">Some Title</h3>
</div>

This is incorrect

<div class="post">
    <h3 class="title">Some Title</h3>
</div>

Overall classes should be strategically placed and minimized as much as possible.

Lastly, classes should be alphabetical.

This is correct

<div class="active post-summary pull-right"></div>

This is incorrect

<div class="pull-right post_summary active"></div>

1.4.2.1 Clearfix

The clearfix class is used to properly adjust the height and width of a tag where all of its children are using float. The proper way of using clearfix is the following.

This is correct

<div class="clearfix">
    <div class="pull-left">
        Item 1
    </div>
    <div class="pull-right">
        Item 2
    </div>
</div>

This is incorrect

<div>
    <div class="pull-left">
        Item 1
    </div>
    <div class="pull-right">
        Item 2
    </div>
    <div class="clearfix"></div>
</div>

This is incorrect

<div>
    <div class="pull-left">
        Item 1
    </div>
    <div class="pull-right">
        Item 2
    </div>
</div>
<div class="clearfix"></div>

1.5. Comments

Use Comments to describe sections, blocks and states. This is helpful when troubleshooting code and automated acceptance testing. Comments should wrap at least each major section in the following format example.

This is correct

<!-- START: Post Image -->
<div class="post-image">
    <img alt="This is a post image" height="60" src="avatar.png" />
</div>
<!-- END: Post Image -->

This is correct

<!-- START: I am logged in -->
<li>
    <a href="/logout">Log Out</a>
</li>
<!-- END: I am logged in -->

This is incorrect

<!-- Post Image -->
<div class="post-image">
    <img alt="This is a post image" height="60" src="avatar.png" />
</div>

This is incorrect

<!-- I am logged in -->
<li>
    <a href="/logout">Log Out</a>
</li>

Just like our backend code, we encourage more comments on the front end code.

1.6. Inline Scripts and Styles

Inline styles are only permitted when dealing directly with javascript or with email HTML. Otherwise inline styles should be placed into a separate file

This is correct

<link href="/custom.css" rel="stylesheet" type="text/css" />
<h1>Some Title</h1>

This is incorrect

<style>
h1 {
    font-weight: bold;
}
</style>
<h1>Some Title</h1>

This is incorrect

<h1 style="font-weight: bold;">Some Title</h1>

Inline scripts are only permitted when instructed by a third party vendor or inline a tag used to activate a script in a separate file. If it is custom code, it should be placed into a separate file.

This is correct

<h1 id="post-title-1">Some Title</h1>
<script src="custom.js" type="text/css"></script>

This is correct

<img onerror="this.parentNode.parentNode.removeChild(this.parentNode)" />

This is incorrect

<h1 id="post-title-1">Some Title</h1>
<script type="text/javascript">
    //do some script
    var title = document.getElementById('post-title-1');
</script>

Templates wrapped around script tags however are acceptable.

This is correct

<script tyle="text/x-template">
    <h1>Some Title</h1>
</script>

1.7. Handlebars

At all times Handlebars should be treated as backend code, thus all regular backend style guidelines should apply.

1.7.1. Spacing

Code in blocks should separated by lines where there is an opportunity to do so. Code inside of Handlebar blocks should be indented with 4 spaces.

This is correct

<!-- START: Profile Name -->
<h3 class="profile-name">
    {{#if profile_name}}
        <span>{{profile_name}}</span>
    {{else}}
        <span>{{_ 'Guest'}}</span>
    {{/if}}
</h3>
<!-- END: Profile Name -->

This is incorrect

<!-- START: Profile Name -->
<h3 class="profile-name">
{{#if profile_name}}
<span>{{profile_name}}</span>
{{else}}
<span>{{_ 'Guest'}}</span>
{{/if}}
</h3>
<!-- END: Profile Name -->

This is incorrect

<!-- START: Profile Name -->
<h3 class="profile-name">
    <span>{{#if profile_name}}{{profile_name}}{{else}}{{_ 'Guest'}}{{/if}}</span>
</h3>
<!-- END: Profile Name -->

This is correct

<!-- START: Profile Name -->
<h3
    class="profile-name
        {{~#if logged_in}}
            profile-logged-in
        {{~else}}
            profile-logged-out
        {{/if~}}
    "
>
    {{profile_name}}
</h3>
<!-- END: Profile Name -->

This is incorrect

<!-- START: Profile Name -->
<h3 class="profile-name{{#if logged_in}} profile-logged-in{{else}} profile-logged-out{{/if}}">
    {{profile_name}}
</h3>
<!-- END: Profile Name -->

1.7.2. Partials

To keep HTML in the 80 character limit per line, consider using partials in order to reset the tab count.

This is incorrect

<div class="post-search-body post-{{type}}" >
    {{#unless profile_banner}}
        <form action="/post/search" class="post-search-form">
            <div class="search-group">
                <div
                    class="tag-field"
                    data-do="tag-field"
                    data-name="q"
                    data-suggest=true
                >
                    {{#each q}}
                        <div class="tag bordered">
                            <input
                                autocomplete="off"
                                class="tag-input text-field"
                                data-do="suggestion-field"  
                                name="q[]"
                                placeholder="{{_ 'Enter Search'}}"
                                type="text"
                                value="{{this}}"
                            />
                            <a class="remove" href="javascript:void(0)">x</a>
                        </div>
                    {{/each}}
                    {{#if type}}
                        <input name="type" type="hidden" value="{{type}}">
                    {{/if}}
                    <div class="pull-right search-icon">
                        <button type="submit">
                            <i class="fa fa-search" aria-hidden="true"></i>
                        </button>
                    </div>
                </div>
                <div class="text-blue">Suggested Filters:</div>
                <div class="suggested-terms">
                    {{#each terms}}
                    <a
                        class="btn btn-white"
                        data-do="add-keyword"
                        data-on="click"
                        data-value="{{term_name}}"
                    >
                        {{term_name}}
                    </a>
                    {{/each}}
                </div>
            </div>
        </form>
    {{/unless}}
</div>

This is correct

<div class="post-search-body post-{{type}}" >
    {{#unless profile_banner}}
        <form action="/post/search" class="post-search-form" >
            {{> search_fields}}
        </form>
    {{/unless}}
</div>

Use partials to keep the HTML code as small as possible while providing reusability on HTML code blocks.

1.7.3. i18n

Always consider that every product will be launched in different countries.

This is correct

<h2>{{_ 'A Major Title in Example'}}</h2>

This is correct

<h2>{{_ 'A Major %s in %s' post_title post_location}}</h2>

This is correct

<h2>
    {{#_ 'A Major %s in %s'}}
        {{post_title}} __ {{post_location}}
    {{/_}}
</h2>

This is incorrect

<h2>Will complete in {{post_complete}} year{{#when post_complete '>' 1}}s{{/when}}</h2>

The reason why the example above is invalid is because year{{#when post_complete '>' 1}}s{{/when}} cannot scale to different languages.

1.8. Bootstrap

Before deciding to style HTML from the ground up, it is good practice to first find the bootstrap example that closely resembles the desired output. After this, if you still need to style a UI from the ground up, talk to your team lead first.

1.8.1 Grids

The original purpose of Bootstrap Grids should only be used to layout a page, not to be used within specific blocks. It is recommended to use custom styling instead.

Page
------------------------------------------------
|                                              |
|                  Header                      |
|                                              |
------------------------------------------------
|                   Body                       |
|  ------------------------------------------  |
|  |     ASIDE     |        SECTION         |  |
|  |               |                        |  |
|  |  -----------  |  --------------------  |  |
|  |  |         |  |  |                  |  |  |
|  |  | BLOCK 1 |  |  |    ARTICLE 1     |  |  |
|  |  |         |  |  |                  |  |  |
|  |  -----------  |  --------------------  |  |
|  |               |                        |  |
|  |  -----------  |  --------------------  |  |
|  |  |         |  |  |                  |  |  |
|  |  | BLOCK 2 |  |  |    ARTICLE 2     |  |  |
|  |  |         |  |  |                  |  |  |
|  |  -----------  |  --------------------  |  |
|  ------------------------------------------  |
|                                              |
------------------------------------------------
|                                              |
|                  Footer                      |
|                                              |
------------------------------------------------

Before using rows and col-* be sure you fully understand the subject. Consult with the team lead if you are unsure about using this.

1.9. Template One

All custom website themes should have a template one page made before development. The rationale is to increase the flexibility of UI components and to reduce the need to review custom code everytime we introduce a new UI component.

The following is how a template one page would look like. The minimum requirement for a template one page is HTML and CSS, though having the page JS and handlebars enabled would make it easier to layout different pages with the template one page.

template-one

2. CSS Style Guide

The purpose of this style guide is to improve code quality by documenting a set of expected rules that can consistently apply across all projects. The main benefits are the following.

  • Easier for new developers to on board on a project
  • Easier to troubleshoot code across different projects
  • Easier to contribute additional code
  • Easier to identify strategy and logic that can be applied to different projects

The following helps navigate through these guidelines.

2.1. Spacing

To simplify styling to be concise across all projects, the following should apply.

  • Selectors separated by commas should be on a new line.
  • Each property should be on a new line. (Even if it is one property)

This is correct

html,
body {
    font-size: 15px;
    height: 100%;
    margin: 0;
}

This is correct

.post-title {
    font-size: 15px;
}

This is incorrect

html, body { font-size: 15px; height: 100%; margin: 0; }

This is incorrect

.post-title { font-size: 15px; }

2.2. Stylesheet Structure

  • Global
  • Components
  • Partials
  • Pages

Structure should be expressed by comment docing the layout.

/* Global - Tags
------------------------------*/
/* Global - Classes
------------------------------*/
/* Global - Bootstrap
------------------------------*/
/* Component - [NAME]
------------------------------*/
/* Component - [NAME]
------------------------------*/
/* Partial - [NAME]
------------------------------*/
/* Partial - [NAME]
------------------------------*/
/* Page - [NAME]
------------------------------*/
/* Page - [NAME]
------------------------------*/

2.2.1. Global

Global styles are applied globally defined by first level selectors.

First Level Selector Examples

body {
    height: 100%;
}
.wrapper {
    padding: 10px;
}
.text-success {
    color: #00FF00;
}

Second Level Selector Examples

body p {
    height: 100%;
}
.wrapper .item {
    padding: 10px;
}
.text-success span {
    color: #00FF00;
}

You should not have second level (or more) selectors in global sections. Exceptions to this rule is overriding a bootstrap class.

2.2.2. Component

Components are commonly used UI elements. Some example of components are pagination, tag field, image field, date field etc.

When styling components, the first level selector should reference the top level component class name.

This is correct

.pagination {
    padding: 0;
}

.pagination .pagination-item {
    margin: 0;
}

This is incorrect

.pagination-item {
    margin: 0;
}

2.2.3. Partials

Partials are HTML blocks usually used with Handlebars in loops and normally is a group of random HTML and UI components.

When styling partials, the first level selector should reference the top level partial class name. This implies that partials should have a singular top level parent.

This is correct

.post-item {
    padding: 0;
}

.post-item .post-title {
    margin: 0;
}

This is incorrect

.post-title {
    margin: 0;
}

2.2.4. Pages

Page sections describes styles that should only be applied per page. By practice we place the page class in the <html> tag.

Page class names should start with page- like page-about-us. When styling partials, the first level selector should reference the top level page class name.

This is correct

.post-about-us {
    padding: 0;
}

.post-about-us .about-us-detail {
    margin: 0;
}

This is incorrect

.about-us-detail {
    margin: 0;
}

2.3. Selectors

Selectors should be separated by one space only. Selectors should be unique per stylesheet.

This is correct

.post-item .post-title a {
    color: #FFFFFF;
}

.post-item .post-title h3 a {
    padding: 10px;
}

This is incorrect

.post-item .post-title a {
    color: #FFFFFF;
}

.post-item .post-title a {
    padding: 10px;
}

A standard practice is to minimize the amount of selectors needed to make it easier to override. The only exception to this rule is when you are attempting to override an existing style without using the !important value.

This is generally incorrect

body .head nav .nav-header span img.brand-logo {
    width: 50px;
}

.post-item .post-title ul li a {
    padding: 10px;
}

The first selector in the example above body .head nav .nav-header span img.brand-logo makes it difficult to override this style because we started with the body element and has a total of 6 selectors. In order to properly override this, we need to match the number of selectors or increase the selector count at least by one.

The second selector above .post-item .post-title ul li a is also incorrect because having an <li> tag implies that there is a <ul> parent already.

This implies another practice which is not to over complicate each selector. The first way to do this is prefer to use class names over tag names. This is because tag names are more likely to change than class names and you should not select a tag and a class name in one selector as in strong.label.

To make that rule more viable it is considered bad practice for the same class name to be used in different sibling HTML tags.

This is preferred

.post-item .post-title .label {
    padding: 10px;
}

.post-item .post-title.active .label {
    padding: 10px;
}

This is incorrect

.post-item .post-title.active strong.label {
    padding: 10px;
}
.post-item .post-title span.label {
    padding: 10px;
}

2.3.1 Direct Child

Direct child separator > should be separated by spaces.

This is correct

.post-item > .post-title > .label {
    padding: 10px;
}

This is incorrect

.post-item>.post-title>.label {
    padding: 10px;
}

2.4. Properties

Properties should be organized in alphabetical order.

This is correct

body {
    font-size: 15px;
    height: 100%;
    margin: 0;
}

This is incorrect

body {
    margin: 0;
    height: 100%;
    font-size: 15px;
}

2.4.1. Browser Specific

Browser specific properties denoted by - as in -webkit-user-select should be placed on the top order of selectors and then alphabetical.

This is correct

.mobile-pointer {
    -moz-user-select: none;
    -webkit-pointer-events: none;
    -webkit-user-select: none;
    pointer-events: none;
    user-select: none;
}

This is incorrect

.mobile-pointer {
    -webkit-pointer-events: none;
    pointer-events: none;
    -webkit-user-select: none;
    -moz-user-select: none;
    user-select: none;
}

2.5. Values

2.5.1 Decimals

When using zero-point decimals, you should express the zero 0 before the decimal.

This is correct

opacity: 0.45

This is incorrect

opacity: .45

2.5.2. Colors

When expressing colors using hexadecimal, you should express it using capital letters and in 6 characters. You should use the rgba function to explain colors with alpha-transparency and you should not express colors by their word name.

This is correct

#000000
#A14C24
rgba(40, 40, 40, 0.45)

This is incorrect

#000
#a14c24
white

2.5.3. Important

You should try to avoid the use of !important in most circumstances. Styles can be overriden in two other ways

  1. Simply use the same selector count later in the file or in a file that is declared after the original file.
  2. Add an extra selector count like from .post-detail to .post .post-detail.

The only acceptable use of !important is if you are overriding a style that is also using the !important value.

2.6. Responsive

Generally, responsive styles should be placed at the bottom of each Stylesheet Structure.

This is correct

@media(max-width:767px) {
    .notify {
        left: 10px;
        width: auto;
    }
}

/* Component - Pagination
------------------------------*/

This is incorrect

/* Component - Notify
------------------------------*/
.notify {
    left: 10px;
    width: auto;
}

@media(max-width:767px) {
    .notify {
        left: 10px;
        width: auto;
    }
}

.notify a {
    width: auto;
}

This is incorrect

/* Component - Notify
------------------------------*/
@media(max-width:767px) {
    .notify {
        left: 10px;
        width: auto;
    }
}

.notify {
    left: 10px;
    width: auto;
}

Instead of fluid responsive (which measures HTML by percent(%)), it is much easier to design snap responsive (which shrinks the styles to certain width milestones).

Snap Responsive

.wrapper {
    width: 900px;
}

@media(max-width: 900px) {
    .wrapper {
        width: 600px;
    }
}

@media(max-width: 600px) {
    .wrapper {
        width: 300px;
    }
}

This order of responsive does imply that we do not do mobile first. The main reason why desktop first is preferred is because it is much easier to remove elements than it is to un hide elements. Though, both ways provide the same results, mobile responsive is a forward compatible design concept while the latter is a backwards compatible design concept.

Mobile Responsive

.wrapper {
    width: 300px;
}

@media(min-width: 300px) {
    .wrapper {
        width: 600px;
    }
}

@media(min-width: 600px) {
    .wrapper {
        width: 900px;
    }
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment