Manage your CSS
with prefixes.

          <div class="ly_header">...</div>  <!-- layout -->
          <div class="ly_main">
              <div class="bl_sectBlock">  <!-- block module -->
                  <h2 class="bl_sectBlock_ttl">PRECSS</h2>
                  <p class="bl_sectBlock_txt hp_mb20">CSS with prefixes.</p>  <!-- helper -->
              </div>
          </div>
          <div class="ly_side">
              <a href="#" class="el_btn">Try PRECSS</a>  <!-- element module -->
              <a href="#" class="el_btn el_btn__blue">Back</a>  <!-- modifier -->
          </div>
          <div class="ly_footer">...</div>
        

Powerful modular design that has taken over the splendor of OOCSS, SMACSS, and BEM skillfully and has evolved further. That is PRECSS.


Add prefix to everything
All classes managed by PRECSS are prefixed according to their type. By doing this, you can grasp all the roles, scopes and dependencies by looking at the prefix at a glance.
Please do not bother with the size of the module anymore.

Optimized naming convention
All class names consist of a mixture of snake case and camel case, and there are clear rules for using them properly.
As it also shows guidelines on abbreviations, as I have been worried about as I have ever been, there is no need to give very long names.

Friendly design
PRECSS is not a completely new design philosophy. It is based on OOCSS, SMACSS, BEM etc. such a wonderful thought to be praised so far.
The more you are a modern developer, the more PRECSS will feel familiar.

Coexistence with other tribes
With clear, proprietary notation, you will be able to clearly distinguish between the classes you wrote and the classes output by the CMS or CSS framework.
PRECSS does not have to comply with all the rules of PRECSS, but flexibility to accept other people is also in PRECSS.

Extensible
If you need a valid class only for smartphones, you may want to create a group with the prefix ".sp_**".
PRECSS basically consists of 6 groups each with its own prefix, but it can also be expanded as necessary.

Basics

Notation

For CSS description method itself, we recommend that you basically follow the Google HTML/CSS Style Guide , Principles of writing consistent, idiomatic CSS .

Naming convention

PRECSS adds 2 letter prefixes according to the type to all classes intentionally described. All prefixes and words are joined in a snake case based on the structure, and if there are multiple words in one structure, use only the part of the camel case. Basically, we do not use the ID attribute for the style, it all comes with the class attribute.

Not recommended
      
            <div class="bl_img_block">
              <div class="bl_img_block_header">
                ...
              </div>
              <div class="bl_img_block_body">
                ...
              </div>
            </div>
    
Recommended
      
            <div class="bl_imgBlock">
              <div class="bl_imgBlock_header">
                ...
              </div>
              <div class="bl_imgBlock_body">
                ...
              </div>
            </div>
    
Generic usable name
  • _wrapper
  • _inner
  • _header
  • _body
  • _footer

These can be used for general purpose as necessary in any of the 5 groups described later. Especially in _wrapper and _inner, it is clear as structure, redundancy increases on the contrary, so it is not necessary to let its child elements inherit the name.

Not recommended
      
            <div class="bl_imgBlock_wrapper">
              <div class="bl_imgBlock_wrapper_inner">
                <div class="bl_imgBlock_wrapper_inner_header">
                  ...
                </div>
              </div>
            </div>
    
Recommended
      
            <div class="bl_imgBlock_wrapper">
              <div class="bl_imgBlock">
                <div class="bl_imgBlock_inner">
                  <div class="bl_imgBlock_header">
                    ...
                  </div>
                </div>
              </div>
            </div>
    

When omitting a word

Module design in CSS is a very wonderful idea, but it is inevitable that naming becomes redundant. Although PRECSS does not set any particular rules, we recommend that you follow the Google HTML/CSS Style Guide if you omit words. Also, it is also recommended to express only one capitalized word group with two or more words with uppercase letters of each initial letter. However, it is preferable that there are patterns that are somewhat general or continuous.

In addition, we present words that are commonly used as reference.

Common examples
・mainVisual→MV
Examples of consecutive patterns
・northEurope→NE
・northAmerica→NA
・centralSouthAmerica→CSA
Commonly used abbreviations
Sections cat - category col/cl - colomn cont/conts - content(s) lv - level sect - section
Simples btn - button cf - clearfix img - image lnk - link num - number
txt - text ttl - title      
Modifiers lrg - large l - left rev - reverse r - right sml - small

When forming a series

We recommend that you manage serial numbers for items that are similar. However, the first one will not be numbered consecutively, regardless of whether it forms a series or not.

Not recommended
      
            <div class="bl_imgBlock1">...</div>
            <div class="bl_imgBlock2">...</div>
            <div class="bl_imgBlock3">...</div>
    
Recommended
      
            <div class="bl_imgBlock">...</div>
            <div class="bl_imgBlock2">...</div>
            <div class="bl_imgBlock3">...</div>
    

Documentation

Basic Design

PRECSS consists of the following six groups.
※ The source code contains only the descriptions necessary for explanation at a minimum.

  1. Base
  2. Layout
  3. Module
    1. Block Module
    2. Element Module
  4. Helper
  5. Unique
  6. Program
  7. (Original)

1.Base

Prefix: None

We treat bases the same way as SMACSS. In addition to making bases with reset.css and normalize.css, specify the styles related to the whole site directly to the element selector. PRECSS also allows the application of limited base styles within specific scopes. For example, we use a limited base style when "I want all the links in the header to be white, but the inside of the footer should be blue." (However, please be careful as it is an act of increasing detail level)

CSS
      
            .ly_header a {
              color: #fff;
            }
            .ly_footer a {
              color: blue;
            }
    

2.Layout

Prefix: ly_

ly stands for layout. It is used for elements that form large layouts such as headers, body areas, main areas, side areas, and footers.

HTML
      
            <header class="ly_header">
              ...
            </header>
            <div class="ly_body">
              <div class="ly_main">
                ...
              </div>
              <div class="ly_side">
                ...
              </div>
            </div>
            <footer class="ly_footer">
              ...
            </footer>
    
CSS
      
            .ly_header {
              background-color: #f4d9d9;
            }
            .ly_body {
              width: 100%
              max-width: 960px;
              margin: 0 auto;
              background-color: #f9ebd1;
            }
            .ly_main {
              float: left;
              width: 68%;
              background-color: #d7f5e0;
            }
            .ly_side {
              float: right;
              width: 30%;
              background-color: #ecefc9;
            }
            .ly_footer {
              background-color: #dbd9e5;
            }
    

3.Module

PRECSS manages highly portable code as a module.

3-1.Block module

Prefix: bl_

bl stands for block. A module group that contains multiple child elements peculiar to the block module and an element module to be described later and that can be carried as one chunk is formed. Child elements of the block module basically inherit the parent 's name, and clarify the structure by joining by an underscore as it becomes a child.

HTML
      
              <div class="bl_sectBlock">
                <h2 class="bl_sectBlock_ttl">.bl_sectBlock</h2>
                <p class="bl_sectBlock_txt">
                  <img class="bl_sectBlock_txt_img" src="">
                  Lorem ipsum...
                </p>
              </div>

              <div class="bl_imgBlock">
                <h3 class="bl_imgBlock_ttl">.bl_imgBlock</h3>
                <p class="bl_imgBlock_img"><img src=""></p>
                <p class="bl_imgBlock_txt">
                  Lorem ipsum...
                </p>
              </div>
    
CSS
      
              .bl_sectBlock {
                padding: 1%;
                margin: 0 0 20px 0;
                border: 1px solid #ccc;
              }
              .bl_sectBlock_ttl {...}
              .bl_sectBlock_txt {...}
              .bl_sectBlock_txt_img {...}

              .bl_imgBlock {
                padding: 1%;
                margin: 0 0 20px 0;
                border: 1px solid #ccc;
                text-align: center;
              }
              .bl_imgBlock_ttl {...}
              .bl_imgBlock_img {
                > img {...}
              }
              .bl_imgBlock_txt {...}
    

As with SMACSS, PRECSS allows you to directly specify a style for tags of child elements. In that case, however, it is recommended that you specify it with a child selector as much as possible, and add unique classes for non semantic elements such as div and span. Also, if too much hierarchy becomes too deep, there is a risk that influence may be exerted on code outlook and detail level management, so nesting is limited to about 3 levels, and if it is likely to be more than that, add classes as appropriate We recommend.

HTML
      
                <ul class="bl_circleList">
                  <li>list 1</li>
                  <li>list 2</li>
                </ul>
    
CSS
      
                .bl_circleList {
                  padding-left: 1em;
                  margin: 0 0 20px 0;
                }
                .bl_circleList > li {
                  list-style-type: circle;
                }
    
Styles applicable to block modules

As a precaution, only block styles that do not affect other elements are applied to the block module ( margin-top / bottom is directly applicable as an exception). Styles affecting other styles, that is, those related to layouts such as float and width , apply styles in a nested manner from further parents. That is, it is desirable that the initial value of the width of the block module is 100% as much as possible , which realizes high scalability and portability. This behavior is easier to understand by considering a block module with columns as an example.

One column example

In this example, this is the smallest block module, so you can use it alone by not specifying layout, and you can port it anywhere.

HTML
      
                  <div class="bl_imgBlock">
                    <h3 class="bl_imgBlock_ttl">bl_imgBlock</h3>
                    <p class="bl_imgBlock_img"><img src="//goo.gl/7lQK1g"></p>
                    <p class="bl_imgBlock_txt">
                      Lorem ipsum...
                    </p>
                  </div>
    
CSS
      
                  .bl_imgBlock {
                    margin: 0 0 20px 0;
                    border: 1px solid #ccc;
                    text-align: center;
                  }
                  .bl_imgBlock_ttl {
                    font-weight: bold;
                    font-size: 1em;
                  }
                  .bl_imgBlock_img {
                    > img {
                      width: 100%;
                      max-width: 100px;
                    }
                  }
                  .bl_imgBlock_txt {
                    line-height: 1.2;
                  }
    
Example of multiple columns

By wrapping it with an element called bl_imgUnit, you can reuse it without compromising the above block module (in this case, if you also need to change margin-top / bottom , overwrite it as well). Since bl_imgUnit itself has become a high-order block module, bl_imgUnit can be ported to others in the future as well . Also, by controlling the width from the modifier according to the number of columns, we realize high scalability.

HTML
      
                  <div class="bl_imgUnit bl_imgUnit__col2">
                    <h2 class="el_blName">.bl_imgUnit__col2</h2>
                    <div class="bl_imgBlock">
                      ...
                    </div>
                    <div class="bl_imgBlock">
                      ...
                    </div>
                  </div>

                  <div class="bl_imgUnit bl_imgUnit__col3">
                    <h2 class="el_blName">.bl_imgUnit__col3</h2>
                    <div class="bl_imgBlock">
                      ...
                    </div>
                    <div class="bl_imgBlock">
                      ...
                    </div>
                    <div class="bl_imgBlock">
                      ...
                    </div>
                  </div>
    
CSS
      
                  .bl_imgUnit {
                    margin: 0 0 20px 0;
                    border: 1px solid #ccc;
                    text-align: center;
                    > .bl_imgBlock {
                      display: inline-block;
                      margin: 0 2% 0 0;
                      &:last-child {
                        margin-right: 0;
                      }
                    }
                  }
                  .bl_imgUnit__col2 {
                    > .bl_imgBlock {
                      width: 47%;
                    }
                  }
                  .bl_imgUnit__col3 {
                    > .bl_imgBlock {
                      width: 30%;
                    }
                  }
    

An extreme example is as follows when porting these to each of the main area and side area.

As mentioned above, the block module is extremely flexible and can run around in the powerfully. However, in order to maintain its high portability, it is necessary to have a slight special technique called nesting from higher order, and you will have trouble out of it unfamiliar. For porting more complicated block modules, we summarized as Advance Case at the bottom, so please refer to that.

We also provide guidelines for granularity to help you name block modules below. Block modules play a very important role in PRECSS, so we do not recommend omitting these words. We do not necessarily have to include these names, but referring to these will help you strongly to manipulate the block module freely (as a matter of fact, it's a size larger than Unit There is not much to use).

The granularity of concept and naming in block modules
  • Block - the basic unit of a block module. Includes multiple child elements specific to the module and element modules
  • Unit - Block gathering
  • Box - Unit gatherings
  • Container - Box meeting

3-2.Element Module

Prefix: el_

el stands for element. It is a module of the smallest unit such as buttons, labels, headlines, etc. It is possible to carry by itself. We recommend naming as versatile as possible . This is a measure to keep the name and content from deviating regardless of what kind of content it enters as content.
※However, if the style and the naming match semantically within the site, that does not mean that (for example, if the label of the product or brand and the theme color are attached).

If there are multiple element modules of similar style, use the concept of structure and skin in OOCSS. Individual skins are implemented with a modifier to be described later.

Not recommended(HTML)
      
              <!-- names are not universal -->
              <div class="bl_sectBlock">
                <h2 class="bl_sectBlock_ttl">.bl_sectBlock
                  <span class="el_label el_label__news">News</span>
                  <span class="el_label el_label__blog">Blog</span>
                </h2>
                ...
              </div>

              <p class="hp_tac">
                <a href="" class="el_btn el_btn__cancel">Cancel</a>
                <a href="" class="el_btn el_btn__submit">Submit</a>
              </p>
    
Recommended(HTML)
      
              <div class="bl_sectBlock">
                <h2 class="bl_sectBlock_ttl">.bl_sectBlock
                  <span class="el_label el_label__red">News</span>
                  <span class="el_label el_label__blue">Blog</span>
                </h2>
                ...
              </div>

              <p class="hp_tac">
                <a href="" class="el_btn el_btn__blue">Cancel</a>
                <a href="" class="el_btn el_btn__orange">Submit</a>
              </p>
    
Recommended(CSS)
      
              .el_label {
                display: inline-block;
                padding: .2em .5em;
                color: #fff;
                &.el_label__red {
                  background-color: #de5b5b;
                }
                &.el_label__blue {
                  background-color: #308EDE;
                }
              }

              .el_btn {
                display: inline-block;
                max-width: 200px;
                padding: .5em 1em;
                margin-bottom: 20px;
                border-radius: 5px;
                color: #fff;
                text-align: center;
                &.el_btn__orange {
                  background-color: #E18700;
                  box-shadow: 0 3px 0 #B85F29;
                }
                &.el_btn__blue {
                  background-color: #308EDE;
                  box-shadow: 0 3px 0 #2572B1;
                }
              }

              .hp_tac {
                text-align: center !important;
              }
    
About the layout

To maintain portability, em.el_caution like block modules. Ideally it is nested from the destination module, or some parent element like .hp_tac above. ( .hp_ is explained in the next helper section) However, as there are often variations in the element module compared to the block module, it is permissible to directly specify the width and create a size pattern with the modifier. However, fixing ___w250(px) and a fixed number will make it the first step toward failure if inconsistency occurs between the modifier number and the actual size when adopting responsive web design and becoming SP view Please keep in mind. Depending on the situation, if possible use inline-block to make the size variable, it will be useful. Of course it is also possible to adjust the width each time at nesting from the transplant, since the numerical value does not enter the name, the risk of collapse is also reduced.

Recommended(HTML)
      
                <header class="ly_header cf">
                  <!-- nest from the transplant -->
                  <a href="" class="el_btn el_btn__orange">.el_btn__orange<br>(nested)</a>
                </header>

                <div class="ly_main">
                  <!-- modifier -->
                  <a href="" class="el_btn el_btn__w100p el_btn__orange">.el_btn__w100p</a>
                </div>
    
Recommended(CSS)
      
                .el_btn {
                  //nest from the transplant
                  .ly_header > & {
                    float: right;
                    margin: 0 20px 0 0;
                  }
                  //modifier
                  &.el_btn__w100p {
                    width: 100%;
                    max-width: 100%;
                  }
                }
    

3-3.Modifier

Naming convention: [base class name]__[modifier name]
Although I mention it several times already,

  • It looks different
  • Changes in size (mainly element modules, child elements of block modules)
  • Style changes according to certain rules (column etc)

In case PRECSS overwrites with modifier, we denote the modifier name with two underscores. Many are used in module groups, but of course it is also possible to use them for layout groups etc. depending on the situation. As a precaution, when overwriting a style with a modifier, basically it is overwritten with multiple classes to increase the level of detail. "Overwriting a style" is an intentional action, and if it is, it is not preferable that the style changes in CSS reading order.

Element module example
Not recommended
      
                  .el_btn__orange {
                    background-color: orange;
                  }
                  .el_btn {
                    background-color: white;
                  }
                  //applicable color: white
                  //The modifier does not work when the load order of styles has changed for some reason
    
Recommended
      
                  .el_btn {
                    background-color: white;
                  }
                  .el_btn.el_btn__orange {
                    background-color: orange;
                  }
    
Block module example

When applying modifier changes to child elements in a block module,

  • Apply a modifier only to a specific child element and overwrite the style
  • Apply a modifier to the block module itself and override the child element style with nesting from the modifier

There are two ways of you. In the former case, by designating multiple classes as theory, in the latter case, specifying the child element by nesting from the modifier increases the detail level.

HTML
      
                <div class="bl_sectBlock">
                  <h2 class="bl_sectBlock_ttl">.bl_sectBlock</h2>

                  <p class="bl_sectBlock_txt cf">
                    <!-- The original module -->
                    <img class="bl_sectBlock_txt_img">
                    Lorem ipsum...
                  </p>

                  <p class="bl_sectBlock_txt cf">
                    <!-- Examples in which the behavior of only a part changes -->
                    <img class="bl_sectBlock_txt_img bl_sectBlock_txt_img__rev">
                    Lorem ipsum...
                  </p>
                </div>

                <!-- Example of overwriting styles for multiple child elements -->
                <div class="bl_sectBlock bl_sectBlock__sml">
                  <h3 class="bl_sectBlock_ttl">.bl_sectBlock__sml</h3>
                  <p class="bl_sectBlock_txt cf">
                    <img class="bl_sectBlock_txt_img">
                    Lorem ipsum...
                  </p>
                </div>
    
CSS
      
                //The original module
                .bl_sectBlock_txt_img {
                  float: left;
                  margin: 0 10px 10px 0;
                  //Examples in which the behavior of only a part changes
                  &.bl_sectBlock_txt_img__rev {
                    float: right;
                    margin: 0 0 10px 10px;
                  }
                }

                //Example of overwriting styles for multiple child elements
                .bl_sectBlock {
                  &.bl_sectBlock__sml {
                    > .bl_sectBlock_ttl {
                      font-size: .8em;
                    }
                    > .bl_sectBlock_txt {
                      font-size: .5em;
                    }
                    .bl_sectBlock_txt_img {
                      width: 5%;
                    }
                  }
                }
    

Again, it is not recommended to add a modifier to the size change of the block module itself. Because it is dependent on the size of the transplant destination (in other words, the context), and the block module tends to be indefinite in variation as compared with the element module is. The block module is often used in large size, so the risk of failure at the time of responsiveness is naturally higher than that of the element module. If block modules are nested in other modules, we recommend overwriting styles with nesting from the porting module, not the modifier. (Details are explained in Advance Case )

4.Helper

Prefix: hp_

hp stands for helper. Basically it's only one style, so add !Important for intentional overwriting. Regarding the naming convention, we recommend that it conform to Emmet's cheat sheet , and as other rules

  • In the case of units other than px, it is expressed in easy-to-understand initials
  • Represent the decimal point with an underscore
  • Negative values ​​express shorthand in capital letters
  • If a character string follows a short hand, express it with a camel case

(These rules are also generally effective for naming modifiers.) However, if you use too much helper for one element, it will be no different from using the style attribute, so if you have more than three helpers you should consider modularization.

Basically only one style, allow outputStyle: compact . It is also possible to process with more than one style with a helper, only if the behavior is limited and clear.

CSS
      
              .hp_db { display: block !important; }
              .hp_tac { text-align: center !important; }
              .hp_w400 { width: 400px !important; }
              .hp_w50p { width: 50% !important; }
              .hp_lh1_5 { line-height: 1.5 !important; }
              .hp_MT1e { margin-top: -1em !important; }
              .hp_bgcWhite { background-color: #fff !important; }

              //Example of one or more styles
              .hp_centering {
                display: block !important;
                margin-left: auto !important;
                margin-right: auto !important;
              }
    
About clearfix

In PRECSS, clearfix is ​​recommended for releasing float. This is to avoid challenging to describe styles unrelated to the original purpose only for float release. In particular, overflow is sometimes used for its original purpose, and it is not preferable that when you see only the CSS code, you do not know whether it is for float release or for original purpose. If you apply to PRECSS rules, you can also define clearfix as a helper, but clearfix itself is sufficiently general so you do not need to prefix it.

5.Unique

Prefix: un_

It is a group that clarifies that it is used only for one page. Since it is only used on that page, it becomes a landmark to edit the style without worrying about the influence range in repair or operation. The size of the module is also free. It can be small or large.

For example, it is good to use it on a special page such as PRECSS's front page , and it is also good to use it in places that are out of module design even in normal pages. In other words, unique groups are a versatile workaround for every irregular. If you get confused, please use a unique group for the time being. Anytime, any time, it is a good landmark to rework. However, remember that it is a measure for irregularities to the last because it is not expandable if you abuse it too much.

It would also be better to leave a comment on CSS for which page you are using.

HTML
      
              <div class="un_siteRoot_wrapper">
                <section class="un_siteRoot">
                  <p class="un_siteRoot_logo"><img src="images/icon.svg" alt="PRECSS logo"></p>
                  <h1 class="un_siteRoot_ttl">PRECSS</h1>
                  <p class="un_siteRoot_link"><span class="is_deactive">English</span> / <a href="/ja/">日本語</a></p>
                </section>
              </div>
    
Recommended(CSS)
      
              //toppage
              .un_siteRoot_wrapper {
                position: relative;
                top: 33vh;
                text-align: center;
              }
              .un_siteRoot {
                display: inline-block;
              }...
    

6.Progoram

In PRECSS, when touching elements with a program such as JavaScript, we recommend adding a special class as much as possible and separating it from the class for CSS.

Prefix: js_

It is a class for getting elements in JavaScript.

Prefix: is_

Class for managing state of element. Overwriting is done in multiple classes as well as in the case of modifiers, as it is always a style that must be applied, we can also use !Important . State naming can be described simply as is_active , but it is necessary to apply styles with multiple classes so that it does not affect other parts as well. * Depending on compatible browsers and circumstances, it is also recommended to add custom data attributes instead of JavaScript classes.

HTML
      
              <div class="bl_sectBlock js_accordion">
                <h3 class="bl_sectBlock_ttl js_accordion_head">Title Here</h3>
                <p class="bl_sectBlock_txt js_accordion_body is_active">
                  Lorem ipsum...
                </p>
              </div>
    
Not recommended(CSS)
      
              .js_accordion_body {
                display: none;
              }
              //There is a possibility that it may affect other parts
              .is_active {
                display: block;
              }
    
Recommended(CSS)
      
              .js_accordion_body {
                display: none;
              }
              .js_accordion_body.is_active {
                display: block;
              }
    

7.Original

In addition, it is a feature of PRECSS that you can flexibly add a prefix according to the construction philosophy of the site. For example, when building the original grid layout, you can add a prefix such as .gr_4 , .gr_6 or .cl_4 , .cl_6 as abbreviation for grid. For smartphones only valid classes should be .sp_** , tablet only valid classes should be .tb_** . As long as it complies with certain rules, PRECSS accepts whatever you do.

Advance Case

When modules are nested in other modules

In PRECSS, other block modules or element modules may be nested within one block module. This is the behavior under the idea that the module is "portable." We will show some guidelines mainly concerning layout problems, which we face in that case. Let's assume that the module that is currently being built is A, has already been built elsewhere, and B is the module you want to port to A. There are only two basic principles below.

  • he layout of B is controlled by nesting from A
    (Child selector specification is preferable, but descendant selectors are allowed depending on circumstances)
  • Child elements in B should not be controlled by nesting from A
HTML
      
          <div class="ly_side">
            <!-- B module -->
            <div class="bl_imgBlock">
              <h3 class="bl_imgBlock_ttl">.bl_imgBlock</h3>
              <p class="bl_imgBlock_img"><img src="//goo.gl/15naui"></p>
              <p class="bl_imgBlock_txt">
                Lorem ipsum...
              </p>
            </div>
          </div>

          <div class="ly_main">
            <!-- A module -->
            <div class="bl_sectBlock cf">
              <h2 class="bl_sectBlock_ttl">.bl_sectBlock</h2>
              <!-- Porting B module -->
              <div class="bl_imgBlock">
                ...
              </div>
              <p class="bl_sectBlock_txt">
                Lorem ipsum...
              </p>
            </div>
          </div>
    
CSS
      
          //B module
          .bl_imgBlock{
            margin: 0 0 20px 0;
          }

          //Port B module to A module
          .bl_sectBlock{
            > .bl_imgBlock{
              width: 25%;
              float: left;
              margin: 0 10px 10px 0;
            }
          }
    

I will explain in detail about the second "child elements in B should not be controlled by nesting from A".

Do not overwrite the style in the form of A > B > child element if you need something to change the child element of B when porting B to A. This is because the module block itself is an idea of ​​a single chunk that is completed by itself. It is possible to change the behavior of the chunk itself by the context of the porting module, but it is not preferable that even the child elements are influenced by the context. Without being afraid of misunderstanding, the B module itself can be controlled from the A module, but the sense that it should be hidden inside the B module. Changes within the block module are to be completed within the block module, so the inside of the block module is a sanctuary which is not subject to change from other than the block module .

As a matter of fact, if it is necessary to change in the B module at the time of incorporation into the A module, it is processed by adding a modifier to the B module. Here, we show an example where the content becomes small overall when the B module is ported to the A module.

HTML
      
          <div class="ly_main">
            <!-- A module -->
            <div class="bl_sectBlock cf">
              <h2 class="bl_sectBlock_ttl">.bl_sectBlock</h2>
              <!-- Porting of B module, addition of bl_imgBlock__sml modifier -->
              <div class="bl_imgBlock bl_imgBlock__sml">
                ...
              </div>
              <p class="bl_sectBlock_txt">
                Lorem ipsum...
              </p>
            </div>
          </div>
    
CSS
      
          //Addition of bl_imgBlock__sml modifier to B module
          .bl_imgBlock{
            &.bl_imgBlock__sml{
              > .bl_imgBlock_ttl{
                margin: 0 0 5px 0;
                font-size: .8em;
              }
              > .bl_imgBlock_img{
                margin: 0 0 5px 0;
                > img{
                  max-width: 80px;
                }
              }
              .bl_imgBlock_txt{
                margin: 0 0 10px 0;
                font-size: .8em;
              }
            }
          }
    

By describing like this, it protects the sanctuary of the block module and not only maintains a clear code of the maintenance scope, it becomes a versatile module that can reproduce the same state regardless of the context when porting to another place I will.

Changes in child elements of module A

When B module is ported to A module, in some cases, there may be changes to the child elements of module A. I will illustrate three possible patterns as an approach in that case.

  • Modify the style by adding a modifier directly to the corresponding child element module of A
  • Modifier is added to A module and style is changed by nest designation
  • Create an A2 module that is similar to the A module, separated from the original A module

Depending on how far you are looking for extensibility, the first thing to recommend a conclusion earlier is to create a third "similar A2 module" . For example , let's explain the pattern where bl_imgBlock and bl_sectBlock_txt are displayed horizontally almost equally side by side.

Modify the style by adding a modifier directly to the corresponding child element module of A

HTML
      
            <div class="bl_sectBlock cf">
              <h2 class="bl_sectBlock_ttl">.bl_sectBlock</h2>
              <div class="bl_imgBlock">
                ...
              </div>
              <!-- Adding a modifier to the child element module -->
              <p class="bl_sectBlock_txt bl_sectBlock_txt__r49p">
                ...
              </p>
            </div>
    
CSS
      
              .bl_sectBlock{
                > .bl_imgBlock{
                  width: 49%;
                  float: left;
                }
              }
              .bl_sectBlock_txt{
                &.bl_sectBlock_txt__r49p{
                  float: right;
                  width: 49%;
                }
              }
    

This pattern is the fastest, but if you can only adjust the corresponding module with the modifier, and you need to adjust other modules as well, you will have to add modifiers every time, so it's somewhat extensible I lack it.

Modifier is added to A module and style is changed by nest designation

HTML
      
            <!-- Adding a modifier to A module -->
            <div class="bl_sectBlock bl_sectBlock__hasImgBlock cf">
              <h2 class="bl_sectBlock_ttl">.bl_sectBlock</h2>
              <div class="bl_imgBlock">
                ...
              </div>
              <p class="bl_sectBlock_txt">
                ...
              </p>
            </div>
    
CSS
      
            .bl_sectBlock.bl_sectBlock__hasImgBlock{
              > .bl_imgBlock{
                width: 49%;
                float: left;
              }
              > .bl_sectBlock_txt{
                float: right;
                width: 49%;
              }
            }
    

Compared to the above, this pattern only adjusts CSS even if it is necessary to adjust other child elements as well. For modifier names, it is a good idea to set bl_sectBlock__hasImgBlock , whose name is not influenced by the state of child elements, considering extensibility. However, this time it is enough because there is only one nested block module, but if there are more modules to be nested in the A module, for example, in addition to B a C module is also incorporated in the A module, the modifier name is redundant It is expected to become.

In addition, if you make it a modifier name of **__has** , it is more administrative to make the style specification for B module nested from the modifier as in the case of the above CSS example, but if it is assumed to be an example at the beginning When coexisting with "nest of B module not affecting the child elements of A", "both contain B module, but **__has** modifier is added only to one side" , and again It will cause a lot of collapse logically.

Create an A2 module that is similar to the A module, separated from the original A module

HTML
      
              <div class="bl_sectBlock2 cf">
                <h2 class="bl_sectBlock2_ttl">.bl_sectBlock2</h2>
                <div class="bl_imgBlock">
                  ...
                </div>
                <p class="bl_sectBlock2_txt">
                  ...
                </p>
              </div>
    
CSS
      
              //Bulk specification of overlapping style
              .bl_sectBlock,
              .bl_sectBlock2 {...}
              .bl_sectBlock_ttl,
              .bl_sectBlock2_ttl {...}
              .bl_sectBlock_txt_img,
              .bl_sectBlock2_txt_img {...}

              //bl_sectBlock unique specification
              .bl_sectBlock_txt {...}

              //bl_sectBlock2 unique specification
              .bl_sectBlock2_txt {
                width: 49%;
                float: right;
              }
              .bl_sectBlock2 > .bl_imgBlock {
                float: left;
                width: 49%;
              }
    

It adds serial numbers and creates another module as a variant of the original module. Applying the same style again for parts that do not change is a bit of a hassle, but manageability and extensibility are quite high because it can be separated from the original A module. In this example, selectors are separated by commas, but of course it is also possible to manage using CSS preprocessor extend and mixin. If you want to centrally manage common parts such as the title part in the same class by all means, there is a way to make it into an element module.