CSS pattern libraries

maxdesign 83,890 views 117 slides Jul 15, 2014
Slide 1
Slide 1 of 135
Slide 1
1
Slide 2
2
Slide 3
3
Slide 4
4
Slide 5
5
Slide 6
6
Slide 7
7
Slide 8
8
Slide 9
9
Slide 10
10
Slide 11
11
Slide 12
12
Slide 13
13
Slide 14
14
Slide 15
15
Slide 16
16
Slide 17
17
Slide 18
18
Slide 19
19
Slide 20
20
Slide 21
21
Slide 22
22
Slide 23
23
Slide 24
24
Slide 25
25
Slide 26
26
Slide 27
27
Slide 28
28
Slide 29
29
Slide 30
30
Slide 31
31
Slide 32
32
Slide 33
33
Slide 34
34
Slide 35
35
Slide 36
36
Slide 37
37
Slide 38
38
Slide 39
39
Slide 40
40
Slide 41
41
Slide 42
42
Slide 43
43
Slide 44
44
Slide 45
45
Slide 46
46
Slide 47
47
Slide 48
48
Slide 49
49
Slide 50
50
Slide 51
51
Slide 52
52
Slide 53
53
Slide 54
54
Slide 55
55
Slide 56
56
Slide 57
57
Slide 58
58
Slide 59
59
Slide 60
60
Slide 61
61
Slide 62
62
Slide 63
63
Slide 64
64
Slide 65
65
Slide 66
66
Slide 67
67
Slide 68
68
Slide 69
69
Slide 70
70
Slide 71
71
Slide 72
72
Slide 73
73
Slide 74
74
Slide 75
75
Slide 76
76
Slide 77
77
Slide 78
78
Slide 79
79
Slide 80
80
Slide 81
81
Slide 82
82
Slide 83
83
Slide 84
84
Slide 85
85
Slide 86
86
Slide 87
87
Slide 88
88
Slide 89
89
Slide 90
90
Slide 91
91
Slide 92
92
Slide 93
93
Slide 94
94
Slide 95
95
Slide 96
96
Slide 97
97
Slide 98
98
Slide 99
99
Slide 100
100
Slide 101
101
Slide 102
102
Slide 103
103
Slide 104
104
Slide 105
105
Slide 106
106
Slide 107
107
Slide 108
108
Slide 109
109
Slide 110
110
Slide 111
111
Slide 112
112
Slide 113
113
Slide 114
114
Slide 115
115
Slide 116
116
Slide 117
117
Slide 118
118
Slide 119
119
Slide 120
120
Slide 121
121
Slide 122
122
Slide 123
123
Slide 124
124
Slide 125
125
Slide 126
126
Slide 127
127
Slide 128
128
Slide 129
129
Slide 130
130
Slide 131
131
Slide 132
132
Slide 133
133
Slide 134
134
Slide 135
135

About This Presentation

CSS pattern libraries, and important tool for any front end web developer


Slide Content

PATTERN
LIBRARIES
CSS
PATTERN
LIBRARIES

Who
is this guy?

Began in the web in 1995
Full CSS sites in 2002
Skills: UX, front-end dev, training
Recently: CSS pattern libraries

I have helped develop HTML/
CSS pattern libraries for very
large sites (media and university
sites) and complex applications
(banking applications).

In some cases, there are literally
hundreds of CSS, SCSS or
LESS files to review and
optimise as part of the process.

pages
Moving away from

A few years ago, many front end
developers approached
websites and web applications
as a series of “pages”.

Pages were often designed and
built as complete entities. This
meant that page components
were often closely tied to their
relevant pages.

More recently, the focus has
shifted from full page layouts to
re-usable components.

A re-usable component could
be a layout grid structure, a
button, an input, a drop-down, a
menu, a heading, a table, or
even a pullquote.

pattern libraries
HTML/CSS

HTML/CSS pattern libraries are
used to resolve commonly used
interface components. These
components are created as
HTML and CSS code and
documented, so that they can
be easily re-used as needed.

The terms “style guide” and
“pattern library” are often used
interchangeably.

A style guide is a set of
standards for implementing the
overall design, and can include
corporate branding, color
schemes, layout and more.

Style guides are used to ensure
uniformity of the design or
“brand” across all aspects of
the website or application.

On the other hand, HTML/CSS
pattern libraries generally
document code components
for all aspects of the website or
application.

On larger web projects, style
guides and HTML/CSS pattern
libraries are generally separate
entities.

For smaller web projects, style
guides and pattern libraries are
often combined into one
overall entity.

cons?
Pros and

Why use a pattern library at all?
!
Easier to build sites
Easier to maintain sites
Easier to hand over
Better workflow
Shared vocabulary
Promotes consistency

What are the downsides?
!
Time-consuming to write
Often done post-project
Serve current need only

Pre-existing
pattern libraries

There are a wide range of
pre-existing pattern libraries
available today.

Some of these pattern libraries
have a simple purpose - such as
responsive grid systems.

Grid-based CSS libraries
1140 CSS Grid
Mueller Grid System
Responsive Grid System
Responsive Grid System
Less Framework
960 Grid System
Susy
320 and up
http://cssgrid.net/
http://www.muellergridsystem.com/
http://www.responsivegridsystem.com/
http://responsive.gs/
http://lessframework.com/
http://960.gs/
http://susy.oddbird.net/
https://github.com/malarkey/320andup

Others are considered full
“frameworks” that offer a wide
range of components.

These can include:
!
Reset styles
Grid systems
Typography styles
Browser fixes
Common user-interface
component styles

Complex CSS libraries
Bootstrap
Foundation
Skeleton
YAML
Inuit
Kraken
GumbyFramework
http://twitter.github.com/bootstrap/
http://foundation.zurb.com/
http://www.getskeleton.com/
http://www.yaml.de/
https://github.com/csswizardry/inuit.css/
https://github.com/cferdinandi/kraken
http://gumbyframework.com/

There are some great benefits to
using an existing framework:
!
ready-to-use solution
can pick & choose components
easy implementation
quick prototyping
great for teams

There may also be some
downsides:
!
may not suit your project
no need for a complex library
someone else’s conventions
generic look

Bootstrap

Bootstrap vs. mid-range website

Bootstrap vs. University data site

Bootstrap vs. Banking application

Should you use a pre-existing
framework? It depends on the
needs of the site and your
team. There is no one answer.

Assuming you want to create
your own CSS pattern library,
how do you go about it?

abstraction
Understanding

Abstraction is essential to any
CSS pattern library.

The process involves:
!
looking for components that may
be repeated within the layout
defining their characteristics
creating HTML/CSS patterns
for them1.
!
2.
3.

An example:
coloured boxes

These boxes look like they have
similar characteristics. If they
were resolved into a pattern,
this would make our HTML and
CSS more efficient.

What are the key things to keep
in mind when creating any
pattern?

Avoid using IDs

All patterns needs to be class-
based so they can appear as
many times as needed within an
HTML document.

/* avoid */!
#signup-box { }!

Avoid naming
based on content

We should avoid naming
patterns based on the content,
as we want to reuse these
patterns often within the layout.

/* avoid */!
.signup { }!
.member { }!
.member-news { }!
.wiki { }!
.support { }!
.database { }!
!
/* preferred */!
.box { }

Avoid location-
based styles

All patterns should work
regardless of where they’re
placed within the layout.

/* avoid */!
.sidebar .box { }!
.main .box { }!
!
/* preferred */!
.box { }

Avoid widths

Ideally, patterns should avoid
defining widths. Patterns should
be allowed to spread to the
width of any parent container.

/* avoid */!
.box-wide { width: 500px; }!
.box-medium { width: 240px; } !
.box-small { width: 120px; } !
!
/* preferred */!
.box { /* no width defined */ }

Keep patterns as
simple as possible

Patterns should be defined as
simply as possible. Otherwise
they can become restrictive.

.box!
{!
!border-bottom: 5px solid #C8C8C8;!
!background-color: #e6e6e6;!
!/* may not be suitable */!
!margin-bottom: 1em;!
}

Don’t undo

Patterns should not be written
to undo other rules. For
example, the <h3> element:

We could be tempted to style
the <h3> element with a
coloured background - as it
looks like this is the “default”
appearance for all <h3>
elements.

/* default style */!
h3!
{!
!padding: 1em;!
!color: white;!
!background-color: red ;!
}

But what happens if we needed
to use an <h3> element later,
and it doesn’t have a
background-color? We might
have to write a rule to undo our
previous one.

/* default style */!
h3!
{!
!padding: 1em; !
!color: white; !
!background-color: red ;!
}!
!
/* undoing default style */!
.no-background !
{!
!padding: 0; !
!color: #000; !
!background-color : none;!
}!

It is best to avoid over-styling
elements or patterns so that
they do not have to be undone
later.

/* default style */!
h3!
{!
}!
!
/* only when background needed */!
.class-name!
{!
!padding: 1em; !
!color: white; !
!background-color : red;!
}!

Avoid dependency
on HTML structure

Patterns should not rely on the
HTML structure. What happens
if the structure changes in some
instances - like a different
heading level being used?

<div class="box">!
!<h3></h3>!
<div>!
!
<div class="box">!
!<h4></h4>!
<div>!
!
!
/* avoid if possible */!
.box h3, .box h4!
{!
!padding: 10px; !
!background-color: orange; !
}!
!

It is always better to create a
class-based pattern for any
specific styling needs.

<div class="box">!
!<h3 class="box-heading"></h3>!
<div>!
!
<div class="box">!
!<h4 class="box-heading"></h4>!
<div>!
!
!
/* preferred */!
.box-heading!
{!
!padding: 10px; !
!background-color: orange; !
}!

Modules,
modifiers & descendants

How can we let developers
know that our new class called
“box-heading” relates to the
“box” class?

<div class="box">!
!<h3 class= "box-heading"></h3>!
<div>!

We could use a naming
convention that was originally
defined as part of BEM:
!
http://bem.info/

And then extended by Nicolas
Gallagher:
!
http://nicolasgallagher.com/about-html-semantics-
front-end-architecture/

And then modified slightly
again by Harry Roberts:
!
http://csswizardry.com/2013/01/mindbemding-
getting-your-head-round-bem-syntax/

This naming convention is based
on the idea that page layouts
can be broken down into a
series of re-usable “modules”.

If a module needs to be modified
or extended, a “module
modifier” would be used.

If a module has child elements
that need to be styled, a
“module descendant” could be
used.

These different types of class
names need to be relatable and
recognisable.

/* Module */!
.module-name {}!
!
/* Module modifier*/!
.module-name--modifier-name {}!
!
/* Module descendant*/!
.module-name__descendant-name {}!
!
/* Module descendant modifier */!
.module-name__descendant--modifier {}!

<!-- Module -->!
<div class="box"></div>!
!
<!-- Module modifier -->!
<div class="box box--alt"></div>!
!
<!-- Module descendant -->!
<div class="box">!
!<h3 class=" box__heading"></h3>!
</div>!
!
<!-- Module descendant modifier -->!
<div class="box">!
!<h3 class="box__content
box__content--alt"></h3>!
</div>!

Module
descendants

With this naming convention, we
can now add two “module
descendants” to our HTML
markup:

<!-- Module -->!
<div class="box">!
!
!<!-- Module descendant -->!
!<h3 class=" box__heading"></h3>!
!
!<!-- Module descendant -->!
!<div class=" box__content"></div>!
</div>!

.box!
{!
!margin-bottom: 1em;!
!border-bottom: 5px solid #C8C8C8;!
!background-color: #e6e6e6;!
}!
!
.box__heading!
{!
!margin: 0;!
!padding: 10px 15px;!
!text-transform: uppercase;!
}!
!
.box__content { margin: 15px; }!

Module modifiers

But what about the boxes that
are very similar, but have some
unique characteristics - like the
decorative cog image?

If we needed to modify or extend
the original module, we would
create a modifier class name.

<!-- Module modifier -->!
<div class="box box--alt">!
!<h3 class="box__heading"></h3>!
!<div class="box__content"></div>!
</div>!

However, in this case, we need
to modify the “box__content”
class. We need to create a
“module descendant
modifier”.

<!-- Module modifier -->!
<div class="box">!
!<h3 class="box__heading"></h3>!
!<div class="box__content box__content
—cog"></div>!
</div>!

.box__content--cog!
{!
!padding-right: 100px;!
!background-image: url(cog.png);!
!background-repeat: no-repeat;!
!background-position: 100% 0;!
}!

Helper
classes

In one of the boxes, there is a
piece of text that is aligned to
the right. How do we solve this?

We could make it another
module descendant - and
apply this to the link.

.box__link {}!
!
!
!
<div class="box">!
!<h3 class="box__heading"></h3>!
!<div class="box__content"> !
!!<p class=" box__link"></p>!
!</div> !
</div>!
!

Or we could use a different type
of class, called a “helper” or
“utility” class.

Nicolas Gallagher’s SUIT CSS
includes a set of classes called
“utilities”.
!
https://github.com/suitcss/suit

/* Utility classes */!
.u-utilityName {}!
!
!
<!-- example markup --> !
<article class="Tweet">!
!<a class=" u-floatRight"></a>!
!<div class=" u-sizeFill">!
!!<a class=" u-linkComplex"></a>!
!</div>!
</article>!

Bootstrap also uses these types
of classes, but calls them
“helper” classes.
!
http://getbootstrap.com/css/#helper-classes

/* Utility classes */ !
.text-muted { color: #777; } !
.text-primary { color: #428bca; }!
.text-success { color: #3c763d; } !
!
!
<!-- example markup --> !
<p class="text-muted">...</p>!
<p class="text-primary">...</p>!
<p class="text-success">...</p>

These types of classes are
designed to be added to
elements where needed,
without having to resort to
styling elements individually.

/* Helper classes */!
.h-text-right { text-align: right; } !
!
!
!
!
<!-- example markup --> !
<p class="h-text-right">!
!<a href="#">More</a>!
</p>!

For front-end developers who
grew up in the “keep your
markup clean” era, these
classes could be considered
the work of Satan.

I’ve found them to be invaluable
- when you need to add a single
function to an element without
having to create a specific class.

Theme classes

In 2011, Jonathan Snook
introduced SMACSS. One of the
key principles is to categorise
CSS rules into five different
categories.
!
https://smacss.com/

Base - HTML elements
Layout - grids
Module - reusable components
State - states of modules etc
Theme - theming modules etc

These categories are a great way
to break up huge chunks of
CSS rules into manageable
sections.

We could use one of these
categories - theme styles - to
define the background-colors
on our headings.

<h3 class="box__heading bgcolor-red"></h3>!
<h3 class="box__heading bgcolor-blue"></h3>!
<h3 class="box__heading bgcolor-orange"></h3>!
<h4 class="box__heading bgcolor-grey"></h4>!

.bgcolor-red, .bgcolor-blue, .bgcolor-
orange, .bgcolor-grey { color: #fff; }!
!
.bgcolor-red !
{ background-color: #B21F24; }!
!
.bgcolor-blue !
{ background-color: #1D5980; }!
!
.bgcolor-orange !
{ background-color: #C56F00; }!
!
.bgcolor-grey !
{ background-color: #444445; }

Tips
Pattern library

Here are some tips on the
overall approach to CSS pattern
libraries.

Smallest to largest

In mid 2013, Brad Frost
introduced Atomic Design - a
methodology for creating design
systems with five distinct levels
in atomic design.
!
http://bradfrostweb.com/blog/post/atomic-web-
design/

Atoms - HTML elements
Molecules - groups of atoms
Organisms - groups of molecules
Templates - groups of organisms
Pages - instances of templates

Atomic design defines the
process as starting from
smallest components and
building to largest.

Ideally, large components should
not need to be defined in a
pattern library as they should
be build up, like lego, from
smaller components.

Class names

Establish a class naming
convention as early as possible
in the process. Then document
this convention and enforce it!

Intuitive class
names

Make sure any class naming
convention is easy for others to
follow. I have worked on
projects where teams are
constantly changing, so quick
take-up is critical.

Keep it simple

I’ve worked on projects where
the LESS architecture needs to
be mapped out in spreadsheets
in order for teams to understand.
In almost all cases, this was
unnecessary. Keep it as simple
as possible.

Final
thoughts?

Bottom line:
HTML/CSS pattern libraries are
an important tool for anyone
doing CSS today no matter how
large or small your website. Get
out there and get busy!!

Russ Weakley
Max Design
!
Site: maxdesign.com.au
Twitter: twitter.com/russmaxdesign
Slideshare: slideshare.net/maxdesign
Linkedin: linkedin.com/in/russweakley