Css methods architecture

CSS architecture and methodology
Presentation by Lasha sumbadze

itCSS
• ITCSS – ‘Inverted Triangle CSS' is a new methodology. It involves visualising your entire CSS
project as a layered, upside-down triangle. This hierarchical shape represents a model that will help
you order your CSS in the most effective, least wasteful way.
• gives us far better scalability and maintainability

• Generic to explicit
We start out with the most generic, low-level, catch-all, unremarkable styles, and eventually progress to more
explicit and specific rules as we move through the project. We might start with our reset, then progress to slightly
more scoped rules like h1–6 {} , right through to extremely explicit rules such as .text-center {} .
Read more at http://technotif.com/manage-large-css-projects-with-itcss/#qKXhAprDAHwLVGpw.99
• Low specificity to high specificity
The lowest-specificity selectors appear towards the beginning, with specificity steadily increasing as we progress
through the project. We want to ensure that we avoid as much of the Specificity Wars as we can, so we try and
refrain from writing higher-specificity selectors before lower-specificity ones. We’re always adding specificity in
the same direction, thus avoiding conflicts.
• Far-reaching to localised
Selectors towards the beginning of the project affect a lot of the DOM, with that reach being progressively
lessened as we go through the codebase. We want to make ‘passes’ over the DOM by writing rules that affect
progressively less and less of it. We might start by wiping the margins and paddings off everything, then we might
style every type of element, then narrow that down to every type of element with a certain class applied to it, and
so on. It is this gradual narrowing of reach that gives us the triangle shape. Ordering our projects according to
these key metrics has several benefits. We can begin to share global and far-reaching styles much more effectively
and efficiently, we vastly reduce the likelihood of specificity issues, and we write CSS in a logical and progressive
order. This means greater extensibility and less redundancy, which in turn means less waste and much smaller file
sizes.

• Settings
If you are using a preprocessor, start here. This holds any global settings for your project. Settings like $heading-size-1 should
be defined all variables that holds values that uses
• Tools
mixins and functions. Any mixin or function that does not need accessing globally should belong in the partial to which it
relates.Examples of global tools might be gradient mixins, font-sizing mixins and so on.
• Generic
high-level, far reaching styles. This layer is seldom modified,It contains things like Normalize. css, global box-sizing rules,
CSS resets and so on.
• Elements
Elements layer binds onto bare HTML element (or ‘type’) selectors only. It is slightly more explicit than the previous layer in
that we are now saying ‘make every h1 this big’ , or ‘make every a be a certain colour’.
• Objects
Users of OOCSS will be familiar with the concept of objects. This is the first layer in which we find class-based selectors.
These are concerned with styling non-cosmetic design patterns, or ‘objects’. Objects can range from something as simple as
a .wrapper element, to layout systems
• Components
The Components layer is where we begin to style recognisable pieces of UI. We’re still binding onto classes here, so our
specificity hasn’t yet increased. However, this layer is more explicit than the last one in that we are now styling explicit,
designed pieces of the DOM.
• Trumps
This layer beats – or ‘trumps’ – all other layers, and has the power to override anything at all that has gone before it. It is
inelegant and heavyhanded, and contains utility and helper classes, hacks and overrides. A lot of the declarations in this layer
will carry !important (e.g. .text-center { text-align: centre !important; } ). This is the highest specificity layer

• @import “settings.global”;
@import “settings.colors”;
• @import “tools.functions”;
@import “tools.mixins”;
• @import “generic.box-sizing”;
@import “generic.normalize”;
• @import “elements.headings”;
@import “elements.links”;
• @import “objects.wrappers”;
@import “objects.grid”;
• @import “components.site-nav”;
@import “components.buttons”;
@import “components.carousel”;
• @import “trumps.clearfix”;
@import “trumps.utilities”;
@import “trumps.ie8”;

Object oriented css
• Object-oriented CSS, at its core, is simply writing cleaner, DRYer CSS.
It’s just a paradigm shift. The purpose of OOCSS is to encourage code reuse and, ultimately, faster and
more efficient stylesheets that are easier to add to and maintain

• OOCSS is based on two main principles:
The first is to separate the structure from the skin :
Layout and design styling are separate .In other words separation Colors, borders and other visual characteristics
from styling background, color, animation ,border, etc. this means not to mix structure/positioning properties with
skin/styling properties on the same class.
The bad way The good way
.button-1 {
border: 1px solid #ccc;
width: 50px;
height: 50px;
border-radius: 5px;
}
.button-2 {
width: 70px;
height: 20px ;
border-radius: 5px;
}
button-1 {
width: 50px;
height: 50px;
}
.button-2 {
width: 70px;
height: 20px ;
}
.button-border {
border-radius: 5px;
}

The second is to separate the container from the content:
Break the dependency between the container module and the content objects it contains separating container from
content,A styled element should never be dependent on where it’s at in a page
Essentially, this means “rarely use location-dependent styles”.
<input> with .call_info form .left_call_info input <input> , like <input class=“input_pos input_skin">.
.call_info form .left_call_info input {
border: none;
width: 400px;
height: 30px;
background-color: #e9e9e9;
color: #122c49;
padding-left: 5px;
font-size: 10px;
}
.input_pos {
width: 400px;
height: 30px;
padding-left: 5px;
}
.input_skin {
background-color: #e9e9e9;
color: #122c49;
font-size: 10px;
}

What about semantic css?
• You shouldn't care about being non-semantic
The only way to make objects in plain CSS is to define non-semantic classes. However, this comes with
some problems:
• DOM will be overloaded.
<a href="#" id=“click_it” class="btn border box-shadow btn-small btn-blue nice clickable">Click me!</a>
• There's not a safe way to access some of the DOM elements. there is no best way so you have to
choose what is good for particular case .
document.getElementsByClassName(“clickable ”);
x[0].innerHTML = "Hello World!";
Or
document.getElementById(“click_it”);
x.innerHTML = "Hello World!";
Or
document.querySelectorAll(“.clickable ”);
x[0].innerHTML = "Hello World!";

Reusable CSS
• OOCSSS encourage to avoid location dependent styles , you create smaller modules on the page
and extend them with subclasses as necessary
• Reusability is also improved because of the OOCSS encourages abstracting CSS structural styles
and skin level styles.

OOCSS & CSS Preprocessors
• OOCSS and CSS preprocessors solve different problems
• Object oriented CSS is an approach and methodology to achieve the goal while a
preprocessor is a tool to support and enlarge the system.

DRY CSS
• OOCSS focused specifically on abstracting snippets of code, Dry Css focuses primarily on not
repeating yourself..
• The core recommendation of Dry Css is to group reusable properties, name them and then add all
selectors to the group..
• Avoid specificity by harnessing the cascade
• Compared with the OOCSS framework, DRY CSS argues that semantic HTML should be HTML
that reflects the content.
• If the HTML is out of your control, it is obviously valuable, on the other hand it doesn’t
necessarily encourage thoughtful HTML structuring.

“Less” comes into play
The extend directive allows us to easily share styles between selectors.
a.twitter {
min-width: 100px;
padding: 1em;
border-radius: 1em;
background: #55acee color: #fff;
}
span.facebook {
min-width: 100px;
padding: 1em;
border-radius: 1em;
background: #3b5998;
color: #fff;
}
.button {
min-width: 100px;
padding: 1em;
}
.button-skin {
border-radius: 1em;
color: #fff;
}
.twitter-background {
background: #55acee;
}
.facebook-background {
}
.btn {
&--twitter {
&:extend(.button);
&:extend(.twitter-background);
&:extend(.button-skin);
}
&--facebook {
&:extend(.button);
&:extend(.facebook-background);
&:extend(.button-skin);
}
}

Classes
• According to most OOCSS methodologies, subclassing is always handled at the HTML level. It’s better to
avoid attaching not more than 3-4 classes to a single element. When attaching a new class we have to
increase semantic value as well as it necessary or it’s better to mix oocss with dry css.
Compiled css Html Comparison
.button,
.btn--twitter,
.btn--facebook {
min-width: 100px;
padding: 1em;
}
.button-skin,
.btn--twitter,
.btn--facebook {
border-radius: 1em;
color: #fff;
}
.twitter-background,
.btn--twitter {
background: #55acee;
}
.facebook-background,
.btn--facebook {
}

<a href="#" class="twitter">Twitter</a>
<a href="#" class="facebook">Facebook</a>
<!– pure oocss way -->
<a href="#" class="button-skin button btn--twitter
">Twitter</a>
<a href="#" class="button-skin button btn--facebook
">Facebook</a>

<a href="#" class=“btn--facebook">Twitter</a>
<a href="#" class=“btn--twitter">Facebook</a>

Mixins and OOCSS
• With preprocessors, we can define so-called "mixins", which have some similarities to functions in
programming languages. In
I suggest you to don’t include mixin when you don’t give it arguments , you can just use extend and
take dry css as we mentioned in past slides or you can just attach it in your html because dry
preprocessor code does not mean dry css code when we compile our code to css we will end up with
repetitions of various properties.
.round(@radius: 5px) {
/* Safari 3-4, iOS 1-3.2, Android 1.6- */
-webkit-border-radius: @radius;
/* Firefox 1-3.6 */
-moz-border-radius: @radius;
/* Opera 10.5, IE 9, Safari 5, Chrome, Firefox 4, iOS 4, Android 2.1+ */
border-radius: @radius;
}
.form-info {
background-color: #ccc;
border: 2px solid rgba(0,0,0,0.7);
.round( 15px) ;
}

Some suggestions to avoid specificity
• Avoid to use IDs in CSS, (anything you can do with an ID, you can do with a class), ID or just selecte it with just
attribute selector [id = “some_id”]
• Do not nest selectors unnecessarily.
• Do not qualify selectors unless you have a compelling reason to do so. If.nav {} will work, do not use ul.nav {};
to do so would not only limit the places you can use the .
• Make heavy use of classes because they are the ideal selector: low specifity great portability, and high reusability.
• Safely increasing specificity .btn.btn { } …will select based on only one class (.btn) but with double the
specificity. We can take this as far as we need to:.btn.btn.btn.btn { }it just asks the same question n times.
• Never use !importantant !important declarations should not be used unless they are absolutely
necessary after all other avenues have been exhausted. It ruins the order
• Descending order of specificity
1. Inline styles
2. ID selectors – (#big)
3. Pseudo Classes (:hover), (:visited) etc.
4. Attributes Selectors – ([href=“”] , [target=“”]);
5. Class Selectors – (.clases)
6. Type Selectors (em, h1, p, ul, li)
7. Universal selectors – (*)

Choose wisely from the toolkit: mixins, extends, a new module or
subclass
Mixins, extends and classes are tools that allow the reduction of repetition in the the act of writing
CSS. Each of these however results in a very different outcome in the final compiled CSS and each
comes with a potential pitfall. Overuse of mixins results in highly repetetive and bloated CSS,
overuse of classes will start to feel like classitis, and an overuse of extends can result in too many
selectors attatched to the same CSS rule.
It’s important to find a good balance and have a process for deciding which solution to use.

Avoid deep-nested selectors and selectors tightly coupled to HTML
• At first , when I started to use preprocessors I was very impressed about that I could write nested
css styles and it was repeating the structure of the DOM , but my impression died when first I’ve
compiled
• So then I realized that to much nesting styles gives you unnecessary specificity and css
downloading time is growing as the size of it, so then I found that there is some kind of
theoretical border for nesting levels : “Note that objects should have at most 4 levels. Most of the
time you'll stay around the 2-3 level range, and the fourth would be the interaction state.”
http://thesassway.com/beginner/the-inception-rule
• I prefer to use not more then 2 levels but there is always some cases when I really need but I am
trying to keep in mind “don’t nested more then 4 levels”
preprocessor code compiled
.container {
.menu-list {
ul {
list-style: none;
li {
padding-left: 10px;
span {
background-image: url() 0 0 no-repeat;
}
}
}
}
}
.container .menu-list ul {
list-style: none;
}
.container .menu-list ul li {
padding-left: 10px;
}
.container .menu-list ul li span {
background-image: url() 0 0 no-repeat;
}

Conclusion• Ultimately, the key to successfully using OOCSS and preprocessors together is understanding the problems that
OOCSS and preprocessors solve as well as the way the final CSS will compile. While CSS preprocessors offer a
number of conveniences to front-end developers, they don’t guarantee efficient, maintainable and scalable code.
By creating a clear folder/file structure, maintaining consistent naming conventions, avoiding deep-nested
selectors or CSS/HTML coupling, and choosing wisely from the toolkit, it is possible to benefit from both OOCSS
and preprocessors.
• OOCSS sources:
• https://github.com/stubbornella/oocss
• http://www.slideshare.net/stubbornella/object-oriented-css?qid=311faf43-46d6-4441-88b0-
b07dc8e3d8ab&v=qf1&b=&from_search=1
• http://appendto.com/2014/04/oocss/
• http://www.smashingmagazine.com/2011/12/an-introduction-to-object-oriented-css-oocss/
• http://cwebbdesign.tumblr.com/post/23666803241/scalable-and-maintainable-css-approaches
• OCSS and preprocessor sources:
• http://thesassway.com/intermediate/using-object-oriented-css-with-sass
• http://ianstormtaylor.com/oocss-plus-sass-is-the-best-way-to-css/
• https://css-tricks.com/the-extend-concept/
• http://thesassway.com/intermediate/avoid-nested-selectors-for-more-modular-css
• http://thesassway.com/beginner/the-inception-rule
• http://alancrissey.com/articles/more-object-oriented-css-with-less/
• http://blog.mediumequalsmessage.com/guidelines-using-oocss-and-css-preprocessors

Css methods architecture

Recommended

More Related Content

What's hot (9)

Viewers also liked (18)

Similar to Css methods architecture (20)

Recently uploaded (20)

Css methods architecture