The front-end god and the code farmer are different: you are underestimating CSS, but I have already understood CSS

css. This is a web designer's fence. With so many colors, type settings, layout options, and responsiveness possibilities, it's easy to turn a stylesheet into a million-line nightmare. However, with a few simple actions, you can clean up the mess so that the css works with you, not against you. Front-end developers have given me some wisdom, but I still can't shake it off. Now I share it all with you!

Your css can be messed up because...

It's just natural. Entanglement happened.

cascade. It is a blessing and a curse. Often, when you change the style of one element, other elements get restyled unintentionally. misuse! Important to make the cascade come to a screeching halt and take your inconsistencies from one element style to the next. As the site gets bigger, or more developers start working on the codebase, the css grows too. Without a plan, it becomes the Wild West (Wild West. Smith is not going to get you out of this.

Your css is tightly coupled with the html structure.

Another common mistake is writing CSS in the order in which the elements appear on the page. This might make sense when you are cross-referencing its styles on one page, but it breaks down once you consider multiple pages using the same css. If you have multiple style sheets, 1 style sheet per page, you are in the same predicament. Likewise, overly specific css selectors tend to mirror html too. This leads to duplication and bloat...leading to poor performance. None of these are scalable or maintainable.

you are not using modular css

If the way you write css is to carefully style each element, you'll miss the forest of trees. Imagine staring in a forest and noticing all the maple trees. Instead of writing a repeating style for each tree, you could write a class to style all maple trees. This is how you abstract your design into reusable blocks.

Now, imagine building a landing page without writing a single css. When your CSS is all wrapped into reusable blocks, you get a whole treasure trove of pre-styled snippets. But that's just one of the perks. Julie highlights all the joys of working with modular CSS:

• Modularity - You can get to the point of building a page without writing a single line of css.

• Predictable - no matter where you put your component, it will behave and look the same. Writing code is easy. You have a system for naming it. It's more intuitive to write.

• Maintainability - this is fast and easy to handle. It doesn't break other things on the site.

• Retractable - hard to break and easy to build.

• Dry - it removes the need to copy and paste copy in css.

• Organised - here's a place to choose from.

What is Modular CSS?

There are several modular solutions, but Julie mainly focuses on one called OOCSS (Object Oriented CSS). It is a scalable, maintainable, semantic and predictable way of writing CSS. Nicole Sullivan created it while working for facebook. She set out to improve a clunky 10,000-line style sheet. She started seeing patterns in the sculpt, which led her to create a reusable module called a "media" object. By doing so, she proved that she can save hundreds of lines of code. A media object is a block of content that contains fixed-size media elements (images or videos) as well as other variable-size content (text). Considering this is the most dominant form of content on facebook, the performance and maintainability improvements are huge!

OOCSS - Principles

The two major principles in this are: separation from skin structure to separation from container, separation from content.

Skin structure separation means defining repeating patterns as reusable structures. For example, what makes a button look like a button? You might say: "Rounded corners, padding, and borders." Then you might repeat the visual pattern, which acts as a repeating skin. For example, you might have some blue buttons and red buttons. These are two separate skins as they each have a different background color.

Separation of container from content means that objects should look the same no matter where you put them. In other words, avoid position-dependent styles. For example, if you are designing h2 like this...

.categoryList h2 { styles }.footer h2 { copied styles }

. The way you are repeating the css, it's hard to scale.

Here's a better way to style headers. You can reuse this style, which is irreregardless of where the header is placed:

.sectionHeader { reusable styles }

OOCSS-Object

The foundation of .NET is the object, which is part of your design and can be reused on your site. The object contains html, css, components like background images, and javascript (any behavior, listener or method associated with the object). Objects can be contained in modules, which may contain base components with variations. For example, a base button can have .btnclasses that also provide these variants: .btn-primary,  .btn-inverse,  .btn-warningetc. Here's how it looks in context. Module components are structured in layers:

• object or module or component

  .media

• Modifiers (css design variants)

  .media--inline, .media__img--right

• Country (css or js design tweaks)

  .media--collapsed, .media.is-active

• Child Object (Relationship)

  .media__img .media__body

OOCSS - Best Practices

Julie points out these best practices when you're thinking about which objects to build.

1. Objects should have a single responsibility; they should do one thing well, one thing.

2. They should be completely encapsulated; objects should be able to stand in their place and be the same everywhere.

3. Use classes for objects, modifiers, and states. This allows you the flexibility to mix and match these without the risk of being too specific.

4. Pick a naming system and be consistent. There are different naming formats, so form a team as a plan. Like, CamelCase or no CamelCase? How do you identify children, states, modifiers... BEM method ( .block__element--modifier)?

5. Decide to use semantic and/or expressive naming. It's a hot topic, but it pays to help your team.

Semantic parameters

• Does the class have actual semantic value?

• For whom, what are class semantics?

• Should classes be semantic rather than representational?

• Is it better to have one semantic class or multiple mixins?

• Example: .section-heading, .item-content

representational argument

• Classes have no meaning to browsers. It's just used as a matching mechanism.

• Classes are semantic to developers.

• Representation classes are reusable and not associated with content.

• Content describes itself; classes do not need to.

• Example: .padding-top-large, .no-margin

what do you want?

• dry html (semantic) or dry css (presentation)

• Do you have any constraints like not being able to access css? Did you design a third party tool to spit out the html?

• You can mix and match. Using semantic module classes and presentation utility classes may work best for your team.

How can I get started with modular css?

Not sure where to start? Here's Julie's tip on what to do next. This is a great discussion point to develop your team as you will want to develop a plan to work best for your situation. Then take small steps from there to start reaping the benefits of a modular system.

1. Use a css preprocessor such as Sass. Use pagination, nesting and child elements. These help make repetitions better.

2. Create a convention. Choose a naming system, a classification system, define code formatting standards and document everything.

3. Start iteratively abstracting your site. Start with basic styles - html, body, p, a, h1-h6etc and then build block objects - lists, nav, buttons, media. After that, work on the composite object - headers, footers, masonry cards, sidebars.

4. Keep isolating code until you find a comfortable level of granularity.

5. Stop using css selectors for non-css (eg javascript, feature specs, etc).

6. An architect is a styleguide. Build the component in the style wizard (to help ensure encapsulation) before building it in the app. Tests are also a good testbed if a class is going to break something elsewhere.

7. "Organize, optimize, repeat until you feel no pain" - Julie Cameron

8. Remember: everyone does it differently. Lots of thoughts and opinions. Play around and find out what works best for you.