Overview

Component friendly,
Utility ready,
Modules included,
Objects intruded...

.C.U.M.O is a child of huge refactored project. That's why it has it's own metodology, code style, pre built modules & objects.

First of all .C.U.M.O is for huge projects & for guys with strong eggs & passion in hearts, where you can really win because of power of utility classes and it's not ok, if you are going to use it to create a simple landing page. Each instrument has its own place.

Let's throw away all this words like immutability, composability, predictability about functional programming. All you need to know that that the goal behind all those fancy terms is to write code that’s easier to maintain and to scale. Let's try a small example:

<!-- example -->
<div class="u-px--one tablet:u-max-width--mobile desktop:u-max-width--mobile u-mx--auto u-mb--two u-group u-cursor--pointer u-pt--two">
   <div class="u-bgc--bg-opt group-hover:u-bgc--bg-alt u-transition--base u-radius--eight u-py--half u-relative u-shadow--base">
      <div class="u-height--base u-width--base u-radius--full u-relative">
         <svg class="o-ic o-ic--sprite u-absolute u-pos--centered u-fs--h-sm u-opt u-pt--px u-mt--px group-hover:u-base u-transition--alt">
            <use xlink:href="images/icons/ic-sprite.svg#heart"></use>
         </svg>
      </div>
      <div class="u-lh--base u-pl--five u-l u-absolute u-pos--centered-y">
         <div class="u-opt u-mb--px group-hover:u-base u-transition--alt">.C.U.M.O</div>
         <div class="u-fs--p-sm u-mt--px u-current group-hover:u-wh u-transition--alt">Define once,<br>use everywhere</div>
      </div>
   </div>
</div>
<!-- /example -->

Utility-first classes are like inline styles. They are defined and maintained separately. This allows code reuse, usage of pseudo-classes, pseudo-elements, pre-processors and browser caching. It's like a low level class API, that helps to create more difficult componentns.

Define once, use everywhere.
Or check more on showcase page.

While creating .C.U.M.O we always thought about few things:

• Long mantain.
• Maximum reusable code. Generate classes and states only you need.
• Component friendly. Utilities are cool, but they are only for building components.
• Modular. Use what you need. Leave the rest.
• Responsive. Everything should be 100% responsive. Your website should work on any screensize.
• Mobile-first or not. Use set of breakpoints as you like or need.
• Easy to Customize and extend. Don’t be afraid to change: class names, variables breakpoints in one JS file
• Automation. Automatically generated list of pages/classes/docs.

We encourage some combination of OOCSS and BEM because:

• It helps create clear, strict relationships between CSS and HTML
• It helps us create reusable, composable components
• It allows for less nesting and lower specificity
• It helps in building scalable stylesheets

<!-- block name -->
<div class="bl">
  <div class="bl-child" id='test'></div>
  <div class="bl-child js-bl-child"id='test_long'></div>
  <div class="bl-child bl-child--modifier bl-child--modifier-var"></div>
  <!-- You got it, right? -->
  <div class="l-layout"></div>
  <div class="c-component"></div>
  <div class="m-module"></div>
  <div class="o-object"></div>
  <div class="u-utilities"></div>
</div>
<!-- /block name -->

Typically, three are classes that are prepended with js. This means that we can have an element elsewhere which can carry with style of .btn {}, but without the behaviour of .js-btn.

You must combine js, njk, scss files in one folder sorting by component, modules, utilites and objects. It will help to maintain you project and won't broke in case core will be updated.

build
dev
--icons
----inline
----sprite
--img
--src
----components
------component_one
--------_name.js
--------_name.scss
--------_name.njk
----cumo
------components
------helpers
------layouts
------modules
------objects
------pages
------utilities
----layouts
------default.njk
------layout--two.njk
----modules
------your_module
--------_name.js
--------_name.scss
----objets
------_name.njk
------_name.scss
----utilities
------_your_modifications.scss
------_element_extend.scss
------_etc.scss
----pages
------_index.njk
cumo.js

What can we say after developing and working with .C.U.M.O

• It’s easier to visualize what something looks like just by reading the markup
• It’s easier for multiple people to work on the same site at once. Imagine you have a huge site grid. One naming, one methodology, one structure
• It’s easier to make style updates and create exceptions without worrying about any implications to other parts of the site. This will be particularly handy for long-term maintenance
• It’s easier for developer to take care of project if he doesn't have any design system or frontend architecture
• God bless group hover & responsive utilities!