[CSS Best Practices with Guil Hernandez]

[Guil Hernandez] Hi everyone, I'm Guil, one of the front end

design teachers here at Treehouse.

In this workshop we'll be covering CSS best practices.

These are methods we can use to make our CSS

more efficient, maintainable, and scaleable.

As we will soon find out, there is a lot more to writing good CSS

than simply knowing all the latest and greatest features and techniques.

Today's web sites and applications are larger than ever

and a lot hinges on the CSS architecture,

so CSS that is poorly thought out can be a strain on development in the long run.

In this workshop we will be covering topics such as

CSS architecture, classes versus IDs.

We'll also get into specificity in selectors,

and we'll then cover some CSS reset methods

along with ways to format our CSS and using vendor prefix.

Finally, we will get into some helpful tools

to help us write CSS with these best practices in mind.

When writing CSS our main goal should be that our CSS is

predictable, reuseable, maintainable, and scaleable.

So let's review these in detail.

CSS rules that are predictable should behave as we expect them to.

If we need to update or add any new CSS rules

they shouldn't affect other parts of our site.

Reuseable CSS should be decoupled from the html.

So if we need to add any new components or features

we shouldn't need to recode any patterns or solve any problems

that we've already solved with existing CSS.

Now one of the most important ones is making our CSS maintainable.

This means that we should not have to refactor any of the CSS

if we need to add updates or new features and components.

The added features or updates we make should not break

any of those other components in the site.

Now at some point our site or application will need to scale, which will then require

more developers working on and maintaining our site and our code,

so we need to write our CSS so that it can be easily managed

by other developers who are looking at our code for the very first time,

and there should not be a learning curve for them.

This is when a lot of these best practices come in to help us with a lot of these goals.

For example, keeping our CSS "DRY."

DRY, or "Do Not Repeat Yourself," is a common best practice

in web development where the main idea is to avoid

repeating these same chunks of code or patterns.

If we have bits of code that are repeated multiple times throughout the site

it's a good idea to refactor the CSS set

so that there's only one instance of that code—or one occurrence of that code.

This way each property and value pair is only defined once in our style sheet.

The idea with DRY is to group these repeated CSS properties together

into one rule then add selectors to those groups if they share the same property.

That way our CSS is more maintainable and we would only have to change

one line of CSS, which results into a cleaner html file,

and we only rely on those specific selector groups in the CSS.

For example, we might have a CSS file with 3 rules.

Each of these share the same padding and border radius properties.

The button and field rules share the same display property,

and the float property is only declared in this common rule here.

To make this CSS a bit dryer we can simply separate those shared properties

into 1 rule that groups the selectors using those properties.

So now the button field and column selectors

share the padding and border radius declarations,

and below that the button and field selectors share the display property,

and the column rule now only has that float property declared.

Now this was a very simple example of grouping selectors together

that share the same properties, but what if we have to deal with hundreds of lines

of CSS or large scale sites that have tens or hundreds of pages?

Well, object-oriented CSS, or OOCSS, can be really useful for this.

OOCSS was introduced by Nicole Sullivan in 2009,

and the base principles are a lot like our previous example with DRY.

The object in OOCSS is a repeating visual pattern.

That visual pattern then gets abstracted into

these independent blocks of CSS or modules.

Those modules can then be reused anywhere in our site.

So with OOCSS we will need to think more in terms of style patterns

instead of just styling these individual elements.

We'll also need to think of our web site or app as these code-independent

components that can be rearranged without affecting surrounding components.

OOCSS has 2 main concepts.

The first one is the separation of structure from appearance

and the separation of containers and content.

When we separate the structure from appearance it means that

once we spot these repeating patterns in our CSS we'll need to abstract them

into these separate skins that are reuseable.

We'll then need to name those skins logically,

and, finally, we'll add those skin classes to our html elements that require those styles.

For example, here in our CSS we again have 3 separate rules.

Now they all share the border, border radius,

padding, and box shadow values as we can see here.

Using OOCSS we can actually abstract those into a separate rule or object

and make that our base skin style, which can be reused anywhere in our project.

Then the html can still have those classes for container, box, and button,

but we can then append those skin classes

in the class attribute to bring in those space styles.

Now if skin needs to be changed we only need to change it once in the CSS.

When we separate containers and content

the style components we create should be code or location independent.

So the elements should be reuseable no matter where they are on the page,

and the CSS should not be specifically tied to the html or a location in the document.

The module should actually be able to adapt

to different containers and be easily themed.

When we separate containers and content all elements with those given classes

will also look the same on the page no matter what.

For example, we might have a page with a header and footer

that span the full width of our browser, but then we would probably like to have

these inner containers that need to be centered on the page, as we can see here.

So our html might look something like this

where we have the main header, main content, and main footer elements

with these header inner and footer inner divs nested inside.

These will need to share the same structural styles like width, margin, and padding.

Our CSS could look something like this with these 3 selectors

grouped into 1 rule that shares those properties.

With the separate containers and content principle in mind, we can abstract

those structural styles into their own reuseable class called global width.

Then in our html we'll just need to add that global width class to the class attribute.

Some of the benefits to using OOCSS is that it results in smaller style sheets

that are easier to maintain and scale.

It also makes our CSS predictable, which is one of our main goals when writing CSS,

and we could very well build an entirely new html page

without having to touch the CSS at all.

Once we've defined all these modules in the style sheet

we can sort of plug them in where needed.

For more info on OOCSS you can check out github.com/stubbornella/oocss

or check out the link I added to the workshop notes.

A similar method called Scaleable and Modular Architecture for CSS

was created by Jonathan Snook as a style guide that helps organize our CSS.

SMACSS is very similar to object oriented CSS

in that it helps structure our code for projects on any scale.

It also combines repeating CSS patterns into these reuseable components

we can use anywhere in our sites.

The difference is that SMACSS separates our components

into 5 general categories and those categories are

the base rules, the layout rules, the module rules,

the state rules, and the theme rules.

Our base rules in SMACSS define all the default styles

and how they should look no matter where they are on the page.

Base rules are directly applied to element selectors, not classes or IDs.

Base rules can be used as a CSS reset. It's very good for that.

For example, here we have base rules with our box sizing for all elements,

one that removes margins and padding from the body,

sets the body font styles and so forth.

The SMACSS layout rules are what divide the page into the major components.

For example, the main header, the sidebar, the footer,

and these components can then contain 1 or more modules.

For example, here we have some layout rules for our main wrap container,

the main headers and footers, and some of the layout columns of the page.

Our module rules are the reuseable modular components or the minor components.

Each module we create should exist as a stand-alone component

so it can be easily moved throughout the layout without breaking anything.

When we write module rules we should avoid using IDs and element selectors.

We should stick with those class names since they're reuseable.

For example, here we have examples of the main nav component,

callout module, along with maybe a login or search-box component,

and these should all be reuseable throughout our project.

We should just be able to plug them in wherever

we need to without affecting anything else.

Now we can also subclass these module rules if we need to change the look

because we want to place it in other parts of our site.

To do that it's best to use a subclass

instead of creating a new conditional style based on the new location.

Here are some examples of the subclassed module.

We might have these mod and searchbox components

that maybe need to be modified to use in the footer or the sidebar sections.

Instead of creating descendant selectors for mod and searchbox

we can create those subclasses that contain those modified styles.

Then in our html we can, for example, keep those searchbox and mod classes and, to

bring in the modified styles, we simply append those subclasses in the class attribute.

In SMACSS the state rules are what define

how the modules look when in a particular state.

These are the collapsed or expanded states,

maybe a success or error state, or a hover inactive state in a link.

State rules augment or override other styles,

and we can apply them to layout and module styles.

State rules can also be used with pseudo-classes, media queries, or JavaScript.

Examples of state rules are, as we can see here,

the hover rule for mod, maybe an active state or a transparent state.

We also have these hidden states and maybe a JavaScript specific state

for expanding or collapsing elements.

Finally, the theme rules are what define the color scheme or the typography.

Theme rules are similar to state rules in that they define how the layout might look.

So they are what separate the themes into their own set of styles,

so that they are easier to modifry.

Theme rules are optional because we may not have a need for themes in our project.

So, as Jonathan Snook states, "We'll need to think about our interface

as not only modularly, but as a representation of those modules

in various states because it will make it easier to separate styles appropriately

and build sites that are easier to maintain."

There has been a lot of discussion lately about using classes versus IDs.

So let's talk a little bit about when it's best to use a class or an ID in a selector.

It's best to use IDs as JavaScript hooks or as fragment identifiers in our page.

For example, here we have 3 anchor elements that target sections of the page

if their IDs match the # in our URL or in the href attribute.

Here we have IDs being used as fragment identifiers,

but we can then bring those in as JavaScript hooks,

for example in our search field and the submit button functionalities.

IDs are very heavy on specificity and they cannot be reused.

That is why it's best to use classes because they are more flexible for styling,

and they can always be reused.

So then back in our html file we can add those to the elements for the presentation.

Now there are a few more things to consider, for example,

we should avoid using the same class or ID for styling and JavaScript.

Doing that will make our architecture a lot more fragile

because we're setting up a lot of dependencies

between the CSS, JavaScript, and the fragment identifier.

If we need to create JavaScript specific classes

it's best to prefix them with something like JS.

This way they're easily identifiable as JavaScript hooks

and it decouples the presentational classes from the functional classes

and, most importantly, it reduces the chances of affecting JavaScript behavior

when we need to make those thematic or structural changes in the CSS.

For example, here we have some JavaScript specific classes

for maybe collapsing an element, hiding it, fading it,

or sliding it on the page.

This leads usa into how specificity is calculated in a selector.

Specificity is what determines which CSS styles are applied by the browser.

Selectors with the most specificity always take precedence over others.

Let's talk a little bit about the calculations a browser will make

in order to determine that specificity in a selector.

It's important to understand this conceptbecause knowing how the browser

will interpret your code can come in really handy when debugging CSS,

and it will also save you a lot of time.

The browser uses 4 categories to define the specificity in a selector.

One of those is inline styles, which use that style attribute and elements.

The others are IDs, next.

It uses classes, attributes, selectors, and pseudo-classes, and, finally, elements.

The browser then assigns a specificity value to each one of these categories,

and we can sort of think of them as points.

Each zero here represents each of the categories, respectively.

So no selectors are zero points across the board,

and if the selector consists of any of these four categories

one point is added to its respective category.

For example, 1 point will be added for every inline element,

1 point for every ID, 1 for every class, and 1 for every element selector.

Let's take a look at an example of a selector here.

Here we have a selector that has 1 class.

The browser then adds 1 class point, which gives us a specificity value of 1,0 or 10.

Next, if the selector has 1 ID and a class in the selector

the browser will then add 1 class point and 1 ID point

which then gives us a specifricity value of 1, 1, 0 or 110.

In another example, if we qualify that class by adding the list item element selector

the browser will then add 1 point for the element and our specificity value is 1, 1, 1.

If we then add an unordered list element selector to that nav ID

the browser will then add 1 more element point, which gives us that value of 1, 1, 2,

and, finally, inline styles are very heavy on specificity.

As we can see, it gives inline the value of 1, which results in a specificity value of 1000.

So other things to keep in mind with specificity

is that we should not rely on parent or descendant selectors

because they lower the specificity of child elements.

A better approach is using name spaces as modifiers.

That way they are self-contained and modular.

The modifiers can then be used anywhere and they're

not entirely location based.

For example, we can prefix moidified selectors with the base class name.

So here we have an element with the class title in the second rule

that we might want a modifier for the sidebar.

Well, instead of relying on that sidebar descendant selector,

we can extend it by creating a new modifier class named sidebar title.

Here's another example where we might want to adjust something for the sidebar

when it's inside the main footer.

For that we can create the modifier class using the main footer

name space right in front of sidebar.

It's very similar to subclassing module rules

with that SMACSS approach we covered earlier.

It's also important that we do not rely on tag selectors

because tag selectors are not reuseable and they can be easily overridden,

which then makes our CSS architecture more fragile.

Finally, we'll need to avoid those important declarations in our CSS values.

We should not use important unless absolutely necessary

because it breaks the natural order of the CSS cascade.

It overrides all specificity, even ones in inline style.

It has also been referred to as the "Jedi mind trick" of CSS.

So, as you can see, it's a very powerful declaration that we need to be careful with.

So, as you can see, it's a very powerful declaration that we need to be careful with.

To sum up CSS specificity, inline styles will win over external style sheets,

IDs win over classes, and important wins over all.

Next up, it's always good to use some form of CSS reset in our architecture.

Most CSS resets provide a baseline for styling our pages.

By completely removing certain browser style inconsistencies

like margins, padding, line height, and some of the heading font sizes

we're making sure that our page looks pretty consistent on all browsers

before we begin writing our main styles, but it's also okay

to leave in some of those browser default styles as we'll find out shortly.

The method we should avoid for CSS resets is using the universal selector.

When using that universal selector we have no control

because we lose inheritance in CSS values from parent to child elements.

It trumps any form of inherited style.

Because of that we'll need to write a lot of extra CSS to define a property

for both the parent and the child element.

It also affects the browser—the page load time—because the browser

has to run througth every page element to apply the reset properties.

A common CSS reset method is Eric Meyer's reset CSS.

Reset CSS provides a really good starting point.

We can then edit or extend as we need.

It also includes all the necessary and new html5 tags

like header, footer, aside, section, and so forth.

The good thing with this method is that we shouldn't need to include the entire reset,

just those attributes that we're using and restyling.

One of the most common methods these days is normalize.css.

Some advantages to using Normalize over other CSS reset methods

is that Normalize preserves those useful default styles,

so we don't need to redeclare styles for some of those common typographioc elements

like headers, paragraphs—they all preserve those consistently across the browsers.

Also, the form elements are cross-browser consistent.

Different browsers do have different styles for form elements

so Normalize keeps those consistent right from the start.

We can then remove entire sections of the normalize.css file

because the file size is very small and modular with detailed documentation

and, most importantly, it has great browser support.

Now it's important to keep in mind that we should not

have to write new CSS to reset previous styles.

If you find yourself doing that often,

you'll need to stop, reassess, then refactor your CSS.

Next we'll talk about the best order for formatting CSS rules.

One of those methods is the single line method,

which is the most space and size efficient,

and it requires the least vertical and horizontal scrolling in your style sheet

for writing and editing CSS,

but it is difficult to browse through and immediately target

the specific parts of the CSS as we can see here.

CSS rules can get complex so because of that most developers like

to use that multi-line method, where each property

and value declaration is on a separate line.

We can take the multi-line method one step further

with the multi-line indent format where indented blocks indicate

that we're targeting child elements of the selector above.

For example, here we have main-nav indented beneath main-header,

the column rule is indented beneath the main-content rule and so forth.

We should be minifying and compressing our CSS files in production anyways,

so we should use a method that allows us to navigate CSS quickly

so it will need to maximize readability

even if it means writing each property on a separate line.

Next, what about the property and value declarations?

The best way is to arrange them functionally in our CSS

where the properties are divided into these groups

and aranged in the most logical order.

Doing that improves maintenance and readability.

As we can see here, this rule has the positioning properties; width, height,

border styles, and the background colors all defined in separate groups,

which then improves maintenance efficiency, as we just learned,

and there are a lot of tools that can actually help us with the declaration order,

one of them being CSS Comb, which is a free tool

for sorting CSS properties into specific orders.

It helps us sort and categorize our CSS to improve maintenance

It actually has an algorithm that sorts CSS in the order that is as close as possible

to the decisions web developers would make when writing CSS.

If we were to do something like this manually it would involve

copying and pasting a lot of lines of CSS,

and CSS Comb will do it with just one click.

A tool like CSS Comb will come in handy when working with a team of developers

because it helps maintain our coding style across the team,

which then helps us understand the CSS better

and it helps us find properties much faster, which prevents errors in the CSS.

The cool thing is that code editors like Sublime Text 2 and Coda

all have these CSS Comb plugins we can use right in the text editor.

Next, what about vendor prefix?

It's important to follow up on browser support for many of the latest CSS3 features

so we'll know which vendor prefixes we need to include in our style sheet.

A good resource for that is caniuse.com,

which gives us a comprehensive compatability table

for browser support of all the latest CSS3 features.

Another one is the Mozilla Developer Network,

which is a valuable reference that describes

pretty much every CSS property and the latest browser support.

When writing vendor prefixes it's important to always include

the unprefixed properties last in the rule,

as we can see here with the transition and the linear gradient properties.

There are tools that can help us write these vendor specific properties.

My favorite is Prefixr at prefixr.com,

because we only need to write the properties once.

It then converts our CSS to cross-browser compatible CSS,

and it does that by filtering through CSS3 properties

then dynamically updating them with the necessary prefixes.

Code editors like Sublime Text and Coda

also have prefixer plugins you can use right in the code editor.

Next, if it's necessary, we'll need to provide a fallback method

for some of these CSS3 features,

because first we'll need to always develop with progressive enhancement in mind.

With progressive enhancement we start from a basic working example as our

foundation so it's an experience that all browsers will be able to provide to our users.

We then add those enhancement layers one by one.

With progressive enhancement it's important that we start with

semantic, well-strutured markup, then add that CSS layer

followed by the JavaScript layer.

This minimizes dependencies on a lot of CSS3 features

because we don't sacrifice the accessability for convenience.

We can also use feature detection as a last resort.

Now a really useful tool for feature detection is Modernizr.

Modernizr is a powerful JavaScript-based library

that detects support for html5 and CSS3 features.

It then allows us to provide a fallback

for those browsers that do not support certain features.

Modernizr tests for over 40 features in a matter of milliseconds, so it's really fast,

but we shouldn't need to include the entire library.

We can actually create a custom build only for those features we need.

Finally, there are tools that can help us write CSS using a lot of these best practices.

One of those tools is CSS frameworks.

With CSS Frameworks all these best practices are already baked in.

A good one to use is Foundation by ZURB.

There's also Twitter Bootstrap and others.

It's important that we do not use a framework just because

you don't understand CSS best practices.

We should use a framework to speed up our work flow,

so to make us faster, not necessarily better at CSS.

Next, another helpful tool is CSS preprocessors.

Preprocessors save us a lot of time writing CSS,

and they make our CSS modular and easily scaleable.

A lot of the useful features in CSS preprocessors are

being able to create variables, nest selectors,

create mix ins, and do math functions, along with a lot more features.

Some of the most popular CSS preprocessors are Sass, Less, and Stylus.

Preprocessors do require a bit of a learning curve,

but just remember that it's CSS after all,

and they're not a new language, just a new syntax.

Okay, so that will do it for our workshop on CSS best practices.

As we've learned, it's important we continue using

those best practices throughout our development process.

To learn more about CSS check out our learning adventure

on becoming a web designer or developer and our Deep Dives on html and CSS.

I'm Guil Hernandez, thanks everyone.