Guide: Object-Oriented CSS (OOCSS): Quick Guide
Frontend development is fast and many new techniques are added every year. It can be a struggle for developers to keep up with everything. Between Sass and PostCSS you can easily get lost in the sea of development tools. A newer technique is Object-Oriented CSS, also called OOCSS for short. This is not a tool, but rather a CSS writing methodology that strives for it make CSS modular and object-based In this post, I want to add the basic principles of OOCSS, and how these ideas can be applied to frontend webworkThis technique may not appeal to every developer, but it’s worth understanding new concepts to decide whether your workflow can benefit.
What makes CSS object-oriented?
Object-oriented programming (OOP) is a programming paradigm that focuses on create reusable objects and enter into relationships between them, as opposed to procedural programming which organizes code into procedures (routines, subroutines, or functions). OOP is widely used in both JavaScript and backend languages in recent years, but organizing CSS according to its principles is still a new concept. The “object” in OOCSS refers to a HTML element or anything associated with it (such as CSS classes or JavaScript methods). For example, you can have a sidebar widget object that can be replicated for various purposes (newsletter sign-up, ad blocker, recent posts, etc.). CSS can focuses en masse on these objects which makes scales a breeze. To summarize OOCSS’s GitHub entry, a CSS object can consist of four things: In general, CSS is object oriented if it takes into account classes that are reusable and can be targeted to multiple page elements Many developers would say that OOCSS is easier to share with others and easier to choose up after months (or years) of inactive development. This is comparable to other modular methods such as SMACSS which has stricter rules for categorizing objects in CSS.
Separate structure of style
A big part of OOCSS is writing code that separates page structure (width, height, margins, padding) from appearance (fonts, colors, animations). This makes it possible custom skinning applicable to multiple page elements without affecting the structure This is also useful for designing components that can be used moved through the layout with ease. For example, a “Recent Posts” widget in the sidebar should be able to move to the footer or above the content, while preserving similar styles. Here’s an example of OOCSS for a “Recent Posts” widget which, in this case, is our CSS object: / * Structure * /. Side widget {width: 100%; padding: 10px 5px;} / * Skinning * /. Recent-posts {font-family: Helvetica, Arial, sans-serif; color: # 2b2b2b; font-size: 1.45em;} Note that the layout is managed with the .side widget class which can also be applied to multiple sidebar elements while the appearance is managed with the .recent posts class which can also be used to skin other widgets. For example, if the .recent posts widget has been moved to the footer, it may not have the same positioning, but it may have the same look and feel. Also check out this sidebar example from CodePen. It uses a clear separation of floats and text alignment classes so that replication does not require additional CSS code See the example of the pen’s OOCSS sidebar – completed by Julie Cameron (@jewlofthelotus) on CodePen.
Separate container of content
Separate content from the container element is another important principle of OOCSS. In simpler terms, this just means you should avoid using child selectors when possible. When customizing unique page elements such as anchor links, headers, block quotes, or unordered lists, you must provide them with unique classes instead of child selectors. Here’s a simple example: / * OOCSS * /. Sidebar {/ * sidebar content * /} h2.sidebar title {/ * special h2 element styles * /} / * Non-OOCSS * /. Sidebar {/ * same sidebar content * /} .sidebar h2 {/ * adds more specificity than necessary * /} While it’s not terrible to use the second code format, it is highly recommended to stick with the first format if you want to write clean OOCSS.
Development guidelines
It is difficult to establish exact specifications as developers are constantly debating the purpose of OOCSS. But here are some suggestions that can help you write cleaner OOCSS code
Work with classes instead of IDs for styling. Try refrain from multi-level descendancy specificity unless needed. Determine unique styles with repeatable classes (e.g. floats, clearfix, unique font stacks). Extend elements with targeted lessons instead of parent classes. Organize your stylesheet in sections, consider adding a table of contents.
Note that developers still need to use IDs for JavaScript targeting, but they are not required for CSS because they are too specificIf an object uses an ID for CSS formatting, it can never be replicated, as IDs are unique identifiers. If you then only use lessons for styling inheritance becomes much easier to predict Plus, classes can be chained together for extra money featuresMore than 10 classes can be associated with a single element. While 10+ classes on one element is not something I would personally recommend, developers can collect a library of reusable styles for an unlimited number of page elements. Class names within OOCSS are somewhat controversial and not set in stone. Many developers prefer to keep lessons short and to the point. Camel case, for example, is also popular .errorBox instead of .error boxIf you look at class naming in the OOCSS documentation, you will see that camel case is the “official” recommendation. There is nothing wrong with dashes, but as a rule it is best to follow the OOCSS guidelines.
OOCSS + Sass
Most web developers already love Sass, and it has quickly caught up with the frontend community. If you haven’t tried Sass yet, it’s worth giving it a try. It allows you to write code with variables, functions, nesting and compilation methods such as math functions. In capable hands, Sass and OOCSS could be a match made in heaven. You can find an excellent article about this on The Sass Way blog. For example, using the Sass @ extend statement, you can apply the properties of one class to another. The properties are not duplicated, but instead the two classes are combined with a comma selector. This way you can update CSS properties in one location. If you are constantly writing stylesheets this would save typing hours and help automate the OOCSS process IMAGE: Sean Amarasinghe Remember that too code maintenance is a big part of OOCSSUsing Sass makes your job easier with variables, mixins, and advanced linting tools associated with the workflow. An important feature of great OOCSS code is the possibility to share it with everyoneeven yourself at a later date, and be able to choose it up with ease.
Performance Considerations
OOCSS is intended to operate smoothly and without much confusion. Developers try hard not to repeat themselves every time, in fact that’s the premise behind DRY development. Over time, the OOCSS technique can lead to hundreds of CSS classes with individual properties that are applied dozens of times in a given document. Since OOCSS is still a new topic, it is difficult to discuss the topic of bloat. Many CSS files end up inflated with little structure, while OOCSS offers a stiff structure and (ideally) less bloating. The main performance issue would be in the HTML where some elements can gather a handful of different layout structure and design classes. You will find interesting discussions on this topic on sites like Stack Overflow and CSS-Tricks My recommendation is to try to build a sample project and see how it goes. Falling in love with OOCSS can revolutionize the way you code websites. Alternatively, if you hate it, you will still learn a new technique and think critically about how it works. Either way, it’s win-win.
Busy writing OOCSS
The best way to learn anything in web development is to practice. If you already understand the basics of CSS, you are well on your way! Since OOCSS does not require preprocessing, you can try with an online IDE such as CodePen. Simple projects are the best way to get started and improve your knowledge from there. Check out these resources to continue your research in the evolving field of OOCSS.
OOCSS official website Object Oriented CSS: What, How, and Why OOCSS + Sass = The best way to CSS An introduction to object-oriented CSS
Object-Oriented CSS (OOCSS): Quick Guide: benefits
Faq
Final note
I hope you like the guide Object-Oriented CSS (OOCSS): Quick Guide. In case if you have any query regards this article you may ask us. Also, please share your love by sharing this article with your friends. For our visitors: If you have any queries regards the Object-Oriented CSS (OOCSS): Quick Guide, then please ask us through the comment section below or directly contact us. Education: This guide or tutorial is just for educational purposes. Misinformation: If you want to correct any misinformation about the guide “Object-Oriented CSS (OOCSS): Quick Guide”, then kindly contact us. Want to add an alternate method: If anyone wants to add more methods to the guide Object-Oriented CSS (OOCSS): Quick Guide, then kindly contact us. Our Contact: Kindly use our contact page regards any help. You may also use our social and accounts by following us on Whatsapp, Facebook, and Twitter for your questions. We always love to help you. We answer your questions within 24-48 hours (Weekend off). Channel: If you want the latest software updates and discussion about any software in your pocket, then here is our Telegram channel.
