Save 10% off ANY FITC event with discount code 'slideshare'
See our upcoming events at www.fitc.ca
If you’re working on a large project with a lot of hands in the CSS pot, then your CSS may be doomed to code bloat failure. Scalable and modular CSS architectures and approaches are the new hotness and rightfully so. They provide sanity, predictably and scalability in a potentially crazy coding world. This session will give an overview of some the most popular approaches, including OOCSS, SMACSS, CSS for Grownups, and DRY CSS as well as discussing some general principles for keeping your CSS clean, optimized, and easy to maintain.
1. Scalable and Modular CSS
FTW!
The Legend of the Birth of MetaCoax
/ * Denise R. Jacobs
Future. Innovation. Technology. Creativity.
Amsterdam, Netherlands
18 February 2013 */
2. Tweeting tall tales
I am:
@denisejacobs
This fine event is:
@fitc #FITCAms
And I’m telling the tale of:
#metacoax
5. The Legend of the Birth of
MetaCoax
chapter 1
Problems in Poësia
chapter 2
The Teachings of the Masters
chapter 3
Insights and Epiphanies
chapter 4
Ousting Selector Evil
chapter 5
Triumph!
35. DRY CSS: Thinking
When looking at making a style declaration for a
selector, always have an answer to the question
"Why isn’t this part of a group?”
Then figure out how to make it one.
36. DRY CSS: Approach
Groups define shared properties.
Group selectors with shared properties, rather
than defining them separately.
While the groups have many selectors, each
property/value pair is defined only once.
37. DRY CSS: How
• Name the groups based on their role in the
design
• Use the name as an ID at the top of the list
and a class at the bottom
• Group selectors that share properties above
the properties they share
43. Outcome
CSS bytes/page HTML bytes/page
19% 44%
decrease decrease
44. OOCSS: Signs you need it
• Large number of floats = bad grid
• Large number of margins = you need a reset
css
• Large number of font-size & !important =
cascade is not being leveraged
45. OOCSS: The Gist
• Employ DRY
• Separate structure and presentation
• Modularize
46. OOCSS: Do’s
• Use CSS grids
• Keep selector chains as short as possible
• Give rules the same weight/strength
• Use <hr> as a page section delimiter
• Style classes rather than elements
47. OOCSS: Don’ts
• Avoid attaching classes to elements
• Avoid using IDs as styling hooks, use them for JS
hooks and page anchors
• Avoid the descendent selector
• Don’t over-semanticize class names
• Avoid classnames that are related to the
appearance of the style
48. OOCSS: The process
1. Determine the site-wide “legos” (ie, reusable
pieces)
2. Separate
– Container and Content
– Structure and Skin
– Contour and Background
– Objects and Mix-ins
3. Mix and match container and content objects
to achieve high performance design.
4. Skin for visual difference
49. OOCSS: The Media Module
http://www.stubbornella.org/content/2010/06/25/the-media-object-saves-hundreds-of-lines-of-code/
50. OOCSS: The Media Module
<!-- media -->
<div class="media">
<img class="fixedMedia" src="myImg.png" />
<div class="text">
...
</div>
</div>
51. OOCSS: The Media Module
/* ====== media ====== */
.media {margin:10px;}
.media, .bd {overflow:hidden; _overflow:visible;
zoom:1;}
.media .img {float:left; margin-right: 10px;}
.media .img img{display:block;}
.media .imgExt{float:right; margin-left: 10px;}
52. The Lumberjack
http://www.flickr.com/photos/stikeymo/308546507/
58. SMACSS: Shallow selectors 101
• Avoid tag selectors for common elements
unless completely predictable.
• Use class names as the right-most (key)
selector
• Use the child selector
59. SMACSS: On “classitis”
You’re better off adding classes to the elements
in question and repeating the class in the HTML
than having overly-specific styles.
Instead of being classitis, using multiple classes
clarifies intent and increases the semantics of
elements in question.
62. SMACSS: What’s in a name?
an example module:
.example
a callout module:
.callout
a callout module with a collapsed state:
.callout.is-collapsed
63. SMACSS: Words of Wisdom
“Constrain, but don’t choke.
Consider selector performance, but don’t waste
too much time on it.”
64. The Brit
http://www.flickr.com/photos/31363949@N02/6958447097/
65. CSS For Grown Ups
https://speakerdeck.com/u/andyhume/p/css-for-
grown-ups-maturing-best-practises
http://schedule.sxsw.com/2012/events/event_IA
P9410 (audio)
66. He lived his own nightmare
http://www.flickr.com/photos/djrue/4835062638/
67. CSS For Grown Ups
Don’t style pages, style modules.
Have a style module library that you can reuse.
68. CSS For Grown Ups
Think of your styles as being in layers:
• document – from HTML code, element
selectors
• base styles
• module styles
• layout styles
69. CSS For Grown Ups
Easy determination:
A tag as part of the selector = a document style
If you create a class for it, you release it from
the tag and make it a module style.
70. CSS For Grown Ups: Don’t
…make modules variations based on IDs, base
them on classes instead
#sidebar .promo-box = bad
.promo-box { ... } = okay
.promo-box-light { ... } = better!
71. CSS For Grown Ups: Modules
.promo-box
Related/sub-styles: module’s name extended
with two dashes
.promo-box--eco
javascript class prefixed with js:
.js-login
72. CSS For Grown Ups: Typography
.h-headline
.h-subheadline
.h-byline
.h-promo
73. CSS For Grown Ups: Helpers
“Surgical layout helpers” which are things like
paddings, margins, and gutters as separate
classes.
.margin-top {margin-top: 1em;}
79. Structure and Inform
• Utilize a naming convention to establish
structure and meaning
• Categorize styles in the document or into
multiple documents
• Employ grids for consistent page structure
81. Reduce
• Eliminate inline styles
• Write the shortest chain of elements possible
in selectors
• Drop elements: as qualifiers and selectors
• Choose classes over ids
83. Recycle & Reuse
• Leverage the cascade better to cut down on
redundant style declarations
• Modularize page components to reuse
throughout site
• Extend modules through subclassing
84. They figured out the key!
http://www.flickr.com/photos/karent/3673326282/
85. What do you do when you build?
http://www.flickr.com/photos/mdave/2878687949/
95. Eliminate qualifier selectors
Selectors like
div#widget-nav div#widget-nav-slider ul li
div.name span
Could easily be simplified into
#widget-nav-slider .name span
with the exact same outcome.
96. Eliminate the middleman
If you must use a descendent selector, then
eliminate all unnecessary elements in it:
.widget li a
would become
.widget a
97. Have the shortest chain possible
For example, instead of
#toc > LI > A
it’s better to create a class, such as
.toc-anchor
98. Reduce the Redundant
• Leverage the cascade by relying on
inheritance [oocss]
• Review, revise and reduce !important
[oocss, smacss]
99. Leverage the cascade with
inheritance
color
font-family
font-size
font-style
font-variant
font-weight
font
line-height
list-style-image
list-style-position
list-style-type
list-style
text-align
text-indent
text-transform
visibility
white-space
word-spacing
104. (2) Intermediate phase
• Clear the cruft
• Create preliminary portable styles [cfgu]
• Begin instituting modules based on design
patterns [oocss, smacss, cfgu]
• Institute a Grid [oocss]
105. Clear the cruft
• Eliminate inline styles & decrease use of
<span>
• Eliminate styles that rely on qualifiers high in
the DOM [oocss]
• Use classnames as key selector [smacss]
• Create preliminary portable styles [cfgu]
106. Eliminate styles that rely on qualifiers
high in the DOM
body.video div#lowercontent
div.children.videoitem.hover a.title {
background: #bc5b29;
color: #fff !important;
text-decoration: none;
}
127. Use an icon element
Instead of this:
<li class="favorite">
<span class="icon favorite"></span>
<span id="favorite-poem-insert-point"
class="favorite"></span>
</li>
128. Use an icon element
Do this:
<p><i class="icon icon-comment"></i>23
comments</p>
...
.icon {background-image: url( sprites.png ); }
.icon-comments {background-position: 0 -30px; }
130. Just revamping the code isn’t
enough…
“Even the cleanest code gets ruined by the first
non-expert to touch it.”
- Nicole Sullivan,
The Cascade, Grids, Headings, and Selectors
from an OOCSS Perspective
132. Styleguide Creation Process
1. Determine the unique elements and components
that will be in the styleguide. Also notate the
main colors for text, header, links, and buttons.
2. Start styling the core elements of the pages:
headings, links, tables, blockquotes, unordered
and ordered lists, and forms.
3. Style the components that override the base
styles, such as search boxes, breadcrumb
navigation, themed buttons, and variations in
modules. Include interaction styles:
hover, focus, active states.
133. Styleguide creation process
4. Add layout last and put the components into
place. Each layout could be presented as a
separate document.
5. Document your coding process: naming
conventions and the thinking behind
decisions of grouping, classifying
components, etc.
134. So everyone can access the
treasures
http://www.flickr.com/photos/lecercle/514344657/
141. The Marcot
…is Ethan Marcotte, the creator and author
of Responsive Web Design (RWD)
http://ethanmarcotte.com/
twitter.com/beep
http://www.flickr.com/photos/localcelebrity/7907876246/
142. The Dry Wind
…is Jeremy Clarke, the developer of DRY
CSS.
http://simianuprising.com/
twitter.com/jeremyclarke
143. The Ninja
…is Nicole Sullivan, the creatrice of Object
Oriented CSS (OOCSS)
http://www.stubbornella.org/
twitter.com/stubbornella
http://www.flickr.com/photos/localcelebrity/6025912453/
144. The Lumberjack
…is Jonathan Snook, the creator and
author of Scalable and Modular CSS
(SMACSS)
http://snook.ca/ & http://smacss.com
twitter.com/snookca
http://www.flickr.com/photos/splat/3742596419/
145. The Brit
…is Andy Hume, the creator of CSS for
Grown Ups (I like to shorten this to CFGU).
http://andyhume.net
twitter.com/
http://www.flickr.com/photos/angryamoeba/4674320039/
146. Djinn
…is Jennifer Dixon, front-end developer
extraordinaire
http://jdcoding.com
twitter.com/jenniration
148. My books
The CSS Detective Smashing Books #3 InterAct With
Guide & Web Standards:
#3 1/3
CSSDetectiveGuide.co InterActWithWebStandards.co
m m
twitter.com/cssdetective SmashingBook.com twitter.com/waspinteract
My chapter:
“Storytelling in Webdesign”
On the surface, the kingdom looked as if it should with all of the necessary elements in place,
While some of the builders believed in their craft/were concerned with the mastery of their craft and were committed to building structures that could scale and stand the test of time…
Others were a rag-tag bunch…
who would hastily build with whatever was handy,
ending up with each new structures of selectors shabbily tacked on to the last.New builders came and went, so that ones being added to build the kingdom had no way of know the intentions of the builders before them.
The structures of the selectors they created didn’t start off evil…
But over time, they became more established and caused problems based on their position in the hierarchy.
New selectors that came after them had to try to establish themselves by any means possible. So, no matter how ridiculous they looked, they would try to fit in by being long and unwieldy…
Or fight by making themselves !importantHe’d heard tell that there were wise masters whose teachings could guide and provide structure to the work of the architects and builders, but half-crazed and feverish with the single-minded goal of seeing the kingdom to completion as they originally planned it, his hired design and building experts poo-pooed his suggestions and dismissed the legends relegating them to mere fantasy.
Eric did not become ruler of his kingdom merely because of his impressive stature, regal bearing, and fine form. Being born of the stuff of myth himself, he knew that there had to be some verity in the legends. He sent out two of his most trusted aides Haliec and Vidad (whom he affectionately referred to at Scully and Mulder, because they were always actively seeking the truth) into the world to bring back a champion who could use this deep knowledge to bring order to the chaos within the kingdom.
He spoke to them of a new responsive world, a world where a kingdom, if built correctly, could be accessed by all peoples through all ways and methods. No seeker of information would be turned away from the treasures that a kingdom contained. Even though this wasn’t the work of the masters that they initially sought, their eyes and hearts glowed at the possibility of taking their beloved kingdom to the next level by responding to the needs of their visitors. The wisdom of the Marcot renewed their lagging hope and passion to find a person who would banish the evil selectors from their kingdom once and for all, establish order, and prepare for a future of responsive greatness.
The prophet Marcot saw the fire in their eyes and knew their hearts were pure and that they were true seekers. “There is one could help you,” he said. “Her name is Djiejh. I hear that she spreads the knowledge of the work of the masters. She may have answers for you.”
They went south to the land of the sun and sea (Mijhami), They went south to the land of the sun and sea (Mijhami), where they found Djiejh and conveyed their king’s angst, frustration, and growing concern around the large and still growing ranks of evil selectors and their renegade rules that were behind the shiny façade of their kingdom. Djiejh heard them out, [and felt honor-bound to help them] and then spoke to them of the teachings of the Ninja. “We’ve heard of the Ninja!” they exclaimed! “She’s real? She’s not just a legend?”
Djiejh spoke of the masters: The Ninja in the Area of the Bay, The Lumberjack, who hailed from the Great White North, and The Brit in the land of Londia. And finally, Djiejh related that calling upon the elemental The Dry Wind could help with the process and maintain order.
The Ninja is one of my disciples and has taken my practices to another level. Seek her in the Area of the Bay.
Large number of font-size = cascade is not being leveraged, also over-fussiness: few font sizes are readable - and small differences are not easily detectable.
Employ DRY: endeavor to create and apply as many reusable pieces of code as possible.Separate structure and presentation: avoid coupling the CSS too tightly to presentation/displayModularize: find common elements and presentation and abstract these into reusable code (aka modules)
Keep selector chains as short as possible: the browser can parse the CSS faster and it avoids specificity warsGive rules the same weight/strength so that you and mix and match them to extend an object through subclassingUse <hr> as a page section delimiter (instead of having top or bottom borders be part of an element)Style classes rather than elements
Avoid the descendent selector (i.e. don’t use .sidebar h3)Avoid IDs as styling hooksAvoid attaching classes to elements in your stylesheet (i.e. don’t do div.header or h1.title)Don’t over-semanticize class names: overly semantic names prevent reuse, and classnames should convey useful information to developers.Avoid classnames that are related to the appearance of the styleAvoid using IDs for CSS styling, use them for JS hooks and page anchors predominantly
Determine the site-wide “legos” (ie, reusable pieces), such as:Headings Lists (e.g. action list, external link list, product list, or feature list) Module headers and footers Grids Buttons Rounded corner boxes Tabs, Carousel, toggle blocks Objects and Mix-ins Skin for visual differenceSkins/themes are the module’s presentation – how it looks. The goal is very predictable skins, values that can be easily calculated or measured.
Like OOCSS, SMACSS is about identifying patterns in your design and codifying them, and has a great structure for naming classes in a meaningful and useful way
Base - defaults: single element selectorsLayout – divides the page into sectionsModule – reusable, modular part of the design: callouts, sidebar sections, product lists, etc.State – ways to describe how the module or layout looks in a particular stateTheme – describe how modules or layouts might lookIn small projects, can all be in the same file. In larger projects, multiple files are recommended.
Using a class is preferable, even if you think the element is going to stay predictable.
You’re better off adding classes to the elements in question and repeating the class in the HTML (and potentially committing “classitis”) than having overly-specific styles. Instead of being classitis, using multiple classes clarifies intent and increases the semantics of elements in question.
Some further methodologies with modules include avoiding conditional styling based on the module’s location on the page or on the website with sub-class module components, tying media-queries to the module or layout component instead of grouping them separately, which allows for the module to be kept together and for isolated testing of the module; and only using !important on state styles if necessary, but none others.
In the naming convention for modules, include the name of the module itself.
In Londia
Worked at Clearleft and The Guardianwe’ve become obsessed with web standards to the degree that we strive to keep content and session separate to ridiculous lengths. In addition to web standards, managing complexity is an important factor to consider. We need to optimize code for change, and let go of the idea that we will write HTML which we will never touch again, and do then just manage all of the presentation on the CSS side. In truth, we will always have to revamp the HTML along with the CSS.
The goal is this: when creating selectors, be aware of whether they are document, base or module, and make an effort to keep them all modular level.
But one WITH ids!
The names of the modules again should be descriptive/semantic and not tied to location or appearance:
Instead of styling headings by the elements, typographic classes are suggested, which can then be applied to h1-h6, p, dd, and any other tags, but the visual presentation will be the same:
To handle presentation issues, it’s recommended to use helpersThe above style would be the style that you could add to whatever element needed it on the page, instead of wrapping that style into a component.
Providing good information and organizing it is critical for clarity and understanding.
Distilling even further, Djieh and Djinn discovered the essence – the key!
Buoyed by their discoveries and new knowledge, they went to Poesia to implement their MetaCoax approach to taming the selectors that were running amok in the kingdom.
The goal is to make the stylesheet a little more lightweight and easier to maintain and update with the minimum amount of time and effort investment. The focus is on giving structure and organization to the stylesheet, reducing redundancy and better reuse of styles, And optimizing the selectors
Adopt a “3 or less” rule
Reduces location dependencyIncrease portabilityReduces chances of selector breakageDecreases specificity/Avoids specificity warsPrevents over-use of !importantCan make code more forgiving
Normalize.css “normalizes” the code to a common baseline rather than reseting the base styling for elements across all browsers.
the Kellum method (http://www.zeldman.com/2012/03/01/replacing-the-9999px-hack-new-image-replacement/).Instead of hiding the text offscreen using the -9999px; hack (and creating a huge invisible box in the process), this new technique hides the text while leaving it accessible to screen readers.
“
From 7500 lines to 2200 linesBetter in IE6 & IE7
…a better place for everyone – both visitors and builders alike.