front-end methodologies

front-end methodologies

by @ArashManteghi

#coderconf

“There are only two hard things in Computer Science: cache invalidation and naming things.” ~ Phil Karlton

http://arashm.net

http://arashm.net

@arashmanteghi#coderconf

Introduction Common Solutions Necessity

MaintainableCSS SMACSS ITCSS

OOCSS BEM CSS Modules

Conclusion


Introduction

Problems

There are several things that bother us in CSS

The most common annoyances we have are:• repeating common code• browser prefixes• lack of comments• over qualified selectors• poor class names

Goal: readable, reusable and maintainable code

Introduction

Common Solutions

Split a large stylesheet into multiple smaller pieces

/stylesheetstyle.css

/stylesheetsreset.cssscaffolding.csslayout.csstypography.css/componentsnav-bar.csssearch-bar.csssignup-form.css


Introduction

Common Solutions

Better variable organization

!/* Background Colors !*/ $background: $header-background: $content-background:

!/* Colors !*/ $heading-color: $link-color:

!/* Sizes !*/ $header-height: $footer-height:

!/* use variable !*/ a {color: $link-color}

!/* Background Colors !*/ $color-bg: $color-bg-header: $color-bg-content:

!/* Colors !*/ $color-heading: $color-link:

!/* Sizes !*/ $height-header: $height-footer:

!/* use variable !*/ a {color: $color-link}

!/* Colors !*/ $colors = ( bg: value, bg-header: value, bg-content: value, heading: value, link: value );

!/* use variable !*/ a {color: map-get($colors,link)}


Introduction

Common Solutions

Order your CSS properties

39%

45%

2%

14%


Random

Grouped by type

By line length

Alphabetical

0 12.5 25 37.5 50

39%

45%

2%

14%

Necessity

Should I use it?

typeface

colors

images/icons

composition

“We’re not designing pages, we’re designing systems of components” ~ Stephen Hay


MaintanableCSS

Semantics

%%% <div class=“red pull-left”> <div class=“grid row”> <div class=“col-xs-4”>

Name something based on what it is, not how it looks or behaves

%%% <div class=“header”> <div class=“basket”> <div class=“product”> <div class=“searchResults”>

It’s not clear at all what this HTML represents.

Here I know exactly what I am looking

at. I know the intention of what this HTML represents.

So why else should we use semantic class names?

Because it’s easier to understand.

We are building responsive websites.Semantic class names are easier to find.

The standards recommend it.

ReuseMaintanableCSS

Don’t try and reuse styles

Submit Delete!

.SubmitButton { !/* common styles !*/ }

.SubmitButton-normal { !/* blue colors !*/ }

.SubmitButton-danger { !/* red colors !*/ }

<button class=“SubmitButton SubmitButton-normal”> Submit )</button> <button class=“SubmitButton SubmitButton-danger”> Delete! )</button>


ReuseMaintanableCSS

Submit Delete!




<button class=“SubmitButton-normal"> Submit )</button> <button class=“SubmitButton-danger”> Delete! )</button>

Submit Delete!

.button { !/* common styles !*/ }



<button class=“SubmitButton-normal”> Submit )</button> <button class=“SubmitButton-danger”> Delete! )</button>


ReuseMaintanableCSS

Submit Delete!


.SubmitButton-normal { @extend .SubmitButton; !/* blue colors !*/ }

.SubmitButton-danger { @extend .SubmitButton; !/* red colors !*/ }

<button class=“SubmitButton-normal”> Submit )</button> <button class=“SubmitButton-danger”> Delete! )</button>

Reuse causes bloat. Reuse breaks semantics. But using preprocessors can help us.

.SubmitButton, .SubmitButton-normal, .SubmitButton-danger { !/* common styles !*/ } .SubmitButton-normal { !/* blue colors !*/ } .SubmitButton-danger { !/* red colors !*/ }

What about Mixins? They can be useful too, but should be designed with caution.


ConventionsMaintanableCSS

Conventions can be a bone of contention amongst engineers, but what matters most is readability and consistency.

!/* Square brackets denote optional parts !*/ .<moduleName>[—<componentName>]—[<state>] { }

!/* module container/root !*/ .searchResults {}

!/* components of a module !*/ .searchResults-heading {} .searchResults-item {}

!/* state: such as AJAX loading !*/ .searchResults-isLoading {}


Modifiers are similar to states in that they can change or override the style of a module.

SMACSS

What is SMACCS


SMACSS is more style guide than rigid framework

Every project needs some organization. There are five types of categories:

• Base• Layout• Module• State• Theme

Each category has certain guidelines that apply to it.

ITCSS

Manage Large CSS Projects


Settings

Tools

Generic

Elements

Objects

Components

Trumps

Each layer contains a series of partials. Recommend naming convention is: _<layer>.<partial>.scss

For example: _settings.colors.scss , _elements.headings.scss , _components.tabs.scss

ITCSS

Final Result


@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 “trumps.clearfix”; @import “trumps.utilities”; @import “trumps.ie8”;

OOCSS

The Principles of OOCSS


An approach for writing CSS that’s reusable, maintainable, and standards-based.

Separate structure and skin Separate container and content

Separate Structure and Skin


OOCSS

!/* A simple, design-free button object. Extend this object with a `.btn+--*` skin class. !*/ .btn { display: inline-block; padding: 1em 2em; vertical-align: middle; }

!/* Positive buttons skin. Extends `.btn`. !*/ .btn+--positive { background: green; color: white; }

!/* Negative buttons skin. Extends `.btn`. !*/ .btn+--negative { background: red; color: white; }

<button class="btn btn+--positive">OK)</button>

BEM

Block, Element, Modifier


A popular naming convention for classes in HTML and CSS

• Block is a top-level abstraction of a new component, for example a button.

• Elements, can be placed inside and these are denoted by two underscores following

the name of the block

• Modifiers can manipulate the block and Elements.

.dog { !/* some styles… !*/}

.dog__tail { !/* some styles… !*/ }

.dog+--small { !/* some styles… !*/ }


BEM

Block, Element, Modifier

!/* Block component !*/ .btn {}

!/* Element that depends upon the block !*/ .btn__price {}

!/* Modifier that changes the style of the block !*/ .btn+--success {} .btn+--info {}

!/* Block component !*/ .btn {

!/* Element that depends upon the block !*/ &__price {}

!/* Modifier that changes the style of the block !*/ &+--success {} &+--info {} }

CSS Modules

What are CSS Modules


CSS files in which all class names and animation names are scoped locally by default.

import styles from “./styles.css”;

element.innerHTML = ‘<h1 class=“{styles.title}”> An example heading )</h1>’;

._styles__title_309571057 { background-color: red; }

<h1 class=“_styles__title_309571057”> An example heading )</h1>

On the other hand, it is still possible to define global classes (with :global()) such as helpers

How It Works


CSS Modules

{ test: /\.css/, loader: ExtractTextPlugin.extract(‘css?modules &importLoaders=1&localIdentName=[name]__[local]___[hash:base64:5]’) }

with the help of Webpack or Browserify

var browserify = require('browserify')();

browserify.add('./main.js'); browserify.plugin(require('css-modulesify'), { rootDir: __dirname, output: './path/to/my.css' });

browserify.bundle();

bit.ly/css--modules

http://bit.ly/css--modules


React + CSS ModulesCSS Modules

import React from 'react'; import styles from './table.css';

export default class Table extends React.Component { render () { return ( <div className=“{styles.table}”> <div className=“{styles.row}”> <div className=“{styles.cell}”> A0 )</div> <div className=“{styles.cell}”> B0 )</div> )</div> )</div> ); } }

We want to create DOM easily

<div class=“table__table___32osj”> <div class=“table__row___2w27N”> <div class=“table__cell___2w27N”>A0)</div> <div class=“table__cell___1oVw5”>B0)</div> )</div> )</div>

Extend Problem


Submit Delete!




<button class=“SubmitButton SubmitButton-normal”> Submit )</button> <button class=“SubmitButton SubmitButton-danger”> Delete! )</button>

.SubmitButton, .SubmitButton-normal, .SubmitButton-danger { !/* common styles !*/ } .SubmitButton-normal { !/* blue colors !*/ } .SubmitButton-danger { !/* red colors !*/ }

CSS Modules

Extend Problem





.SubmitButton-v { @extend .SubmitButton; !/* other styles !*/ }

.SubmitButton-w { @extend .SubmitButton; !/* other styles !*/ }

.SubmitButton-x { @extend .SubmitButton; !/* other styles !*/ }

.SubmitButton-y { @extend .SubmitButton; !/* other styles !*/ }

.SubmitButton-z { @extend .SubmitButton; !/* other styles !*/ }

.SubmitButton, .SubmitButton-normal, .SubmitButton-danger, .SubmitButton-v, .SubmitButton-w. .SubmitButton-x, .SubmitButton-y, .SubmitButton-z, { !/* common styles !*/ }



.‌‌.‌.

.‌‌.‌.‌

CSS Modules

The Composes Keyword


.base { !/* common styles !*/ }

.normal { composes: base; color: hsl(210, 61%, 31%); background: hsla(210,61%,51%,0.1); }

.danger { composes: base; color: hsla(0, 61%, 51%, 0.5); background: white; }

<button className=“{styles.danger}”>Delete!)</button>

<button class=“base_81f12d56 danger_b7d2ad6f”>Delete!)</button>

CSS Modules



!/* colors.css !*/ .blue { color: hsl(210, 61%, 31%); }

.light-blue-bg { background: hsla(210,61%,51%,0.1); }

.base { !/* common styles !*/ }

.normal { composes: base; composes: blue light-blue-bg from “./colors.css”; }

<button className=“{style.normal}”>Delete!)</button>

CSS Modules



.blue_c22950a8 { color: hsl(210, 61%, 31%); }

.light-blue-bg_ea7f0091 { background: hsla(210,61%,51%,0.1); }

.base_81f12d56 { !/* common styles !*/ }

.normal_f34f7fa0 {}

<button class=“base_81f12d56 blue_c22950a8 light-blue-bg_ea7f0091 normal_f34f7fa0”> Submit )</button>

CSS Modules

Conclusion


Ask ten experts, and you’ll receive ten different answers, but there are many more.

Which one is the best?

Thanks :)


Any Questions?

front-end methodologies

Software