CSS architecture and methodology(ITCSS,OOCSS,dryCSS)

ITCSS – ‘Inverted Triangle CSS' is a new methodology. It involves visualising your entire CSS project as a layered, upside-down triangle.
The purpose of OOCSS is to encourage code reuse and, ultimately, faster and more efficient stylesheets that are easier to add to and maintain
The core recommendation of Dry Css is to group reusable properties, name them and then add all selectors to the group.

Transcript

1. CSS architecture and methodology Presentation by Lasha sumbadze
2. 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
3. • 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.
5. • 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
6. • @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”;
7. 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
8. • 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 { border: 1px solid #ccc; width: 70px; height: 20px ; border-radius: 5px; } button-1 { width: 50px; height: 50px; } .button-2 { width: 70px; height: 20px ; } .button-border { border: 1px solid #ccc; border-radius: 5px; }
9. 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">. The bad way The good way .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; }
10. 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!";
11. 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.
12. 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.
13. 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.
14. “Less” comes into play The extend directive allows us to easily share styles between selectors. The bad way The good way 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 { background: #3b5998; } .btn { &--twitter { &:extend(.button); &:extend(.twitter-background); &:extend(.button-skin); } &--facebook { &:extend(.button); &:extend(.facebook-background); &:extend(.button-skin); } }
15. 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 { background: #3b5998; } <!-- css way --> <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> <!-- dry oocss way with less --> <a href="#" class=“btn--facebook">Twitter</a> <a href="#" class=“btn--twitter">Facebook</a>
16. 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) ; }
17. 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 – (*)
18. 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.
19. 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; }
20. 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