The Cascade, Grids, Headings, and Selectors from an OOCSS Perspective, Ajax Experience 2009

OBJECT-ORIENTED CSS scale to millions of users or thousands of pages

NICOLE SULLIVAN “stubbornella” on the web

SLIDES http://www.slideshare.net/stubbornella

THE STATE OF CSS

THE “C” IN CSS understanding the cascade

BROWSER DEFAULT STYLES ❖ Browsers have internal default stylesheets ❖ They are all different ❖ Use reset.css from YUI to level the playing ﬁeld

CLASS ORDER Borken! The order of the classes makes no difference.

ORDER OF THE PROPERTY VALUE PAIRS .foo{color: red; color: blue;}

BROWSER IGNORES BITS IT DOESN’T UNDERSTAND .foo{color: red; colour: blue;}

ORDER OF THE RULESETS .foo{color: red;} .foo{color: blue;}

ORDER OF THE STYLESHEETS <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http:// www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html> <head> <link rel="stylesheet" type="text/css" href="styles.css" /> <link rel="stylesheet" type="text/css" href="moreStyles.css" /> </head> <body> My page </body> </html>

SPECIFICITY? Sort of like a game of poker

FROM THE SPEC: ❖ Count 1 if the declaration is from is a 'style' attribute rather than a rule with a selector, 0 otherwise (= a) (In HTML, values of an element's "style" attribute are style sheet rules. These rules have no selectors, so a=1, b=0, c=0, and d=0.) ❖ Count the number of ID attributes in the selector (= b) ❖ Count the number of other attributes and pseudo-classes in the selector (= c) ❖ Count the number of element names and pseudo-elements in the selector (= d)

IT GOES ON... ❖ The specificity is based only on the form of the selector. In particular, a selector of the form "[id=p33]" is counted as an attribute selector (a=0, b=0, c=1, d=0), even if the id attribute is defined as an "ID" in the source document's DTD. ❖ Concatenating the four numbers a-b-c-d (in a number system with a large base) gives the specificity.

ROUGHLY SPEAKING... We need to calculate speciﬁcity faster...

ID AND CLASS #nav p{color: red } .nav p{color: blue }

INLINE STYLES My page

!IMPORTANT p{color: red !important} My page

CSS INHERITANCE body{font-size: 18px;} <body> This text is 18px. </body> http://www.w3.org/TR/CSS2/propidx.html

AGGREGATION OF RULES Boo Boo Boo

POWERFUL misunderstanding of CSS has led to a mess...

CODE IS TOO FRAGILE. Even the cleanest code gets ruined by the ﬁrst non-expert to touch it.

REQUIRE EXPERT ABILITY JUST TO GET STARTED. this is not a sign of maturity.

CODE RE-USE IS ALMOST NONEXISTENT people don’t trust other developers’ code.

FILE SIZE JUST KEEPS GETTING BIGGER As the site evolves we continuously modify the CSS.

WHAT IS THE MOST IMPORTANT MISTAKE TALENTED CODERS ARE MAKING? Writing really clever modules.

THE SIZE OF THEIR CSS WILL INCREASE in a 1:1 relationship with the number of blocks, pages, and complexity of content.

WHAT IS OBJECT-ORIENTED CSS? A philosophy? A framework? A tool?

MORE LIKE AN EVOLUTION OF THE LANGUAGE it makes CSS more powerful

HOW IS IT DIFFERENT? ul{...} ul li{...} ul li a{...}

HOW IS IT DIFFERENT? ul{...} ul li{...} ul li a{...} Until now, we focused all our effort here

HOW IS IT DIFFERENT? ul{...} ul li{...} ul li a{...} But, the architecture lives here

TERMINOLOGY CAN BE CONFUSING so forget about a 1:1 mapping with either CSS or OOP

ALL OF THE CODE IS OPEN SOURCE: ON GITHUB http://wiki.github.com/stubbornella/oocss/

selector heading module grid

selector heading template grid

HEADINGS reusable Lego

Heading Level 1 Heading Level 2 HEADINGS Heading Level 3 Getting the look and feel you want with the semantics you Heading Level 4 need. Heading Level 5 Heading Level 6

REUSING ELEMENTS MAKES THEM performance “freebies”

COMPONENTS ARE LIKE LEGO Mix and match to create diverse and interesting pages.

AVOID DUPLICATION Wasting performance resources on components that can’t add value.

NEARLY IDENTICAL MODULES Headings 3 and 5 are too similar.

Rule of thumb: If two modules look too similar to include on the same page, they are too similar to include together in a site, choose one!

AVOID LOCATION- DEPENDENT STYLES Sandboxing is better than spaghetti, but leads to performance problems

AVOID WHAT?

FUNCTION AREA()

EVERY NOW AND THEN...

RETURNED DIAMETER

BROKEN.

IN CSS WE DO THIS ALL THE TIME

BROKEN.

A Heading should not become a Heading in another part of the page.

AVOID EXAMPLE #weatherModule h3{color:red;} #tabs h3{color:blue} ❖ Global color undeﬁned for h3, so it will be ‣ unstyled in new modules, ‣ developers forced to write more CSS for the same style

AVOID EXAMPLE h3{color:black;} #weatherModule h3{color:red;} #tabs h3{color:blue} ❖ Global color deﬁned (better!) ❖ Weather and tabs override default h3 ‣ three styles for h3 cannot co-exist in the same module ‣ default style cannot be used in weather and tabs without costly overrides ❖ Weather and tabs h3 can never be used outside of those modules

CONSISTENCY Writing more rules to overwrite the crazy rules from before. e.g. Heading should behave predictably in any module.

TRY THIS INSTEAD h1, .h1{...} h2, .h2{...} h3, .h3{...} h4, .h4{...} h5, .h5{...} h6, .h6{...} ❖ Global values deﬁned ❖ Semantics respected (while allowing visual ﬂexibility) <h3 class=”h6”>Heading</h3>

NEED MORE THAN 6 HEADINGS? Really? Any duplicates? Any too similar?

STILL NEED MORE HEADINGS? .category{...} .section{...} .product{...} .prediction{...} ❖ Extend the heading object via a class on the object itself ❖ Avoid using the cascade to change display of nested objects

TEMPLATE & GRIDS Be ﬂexible - extensible height and width

TEMPLATE • 807 bytes • 13 lines of code • easily extended to custom page and column width

GRIDS • 574 bytes • 14 lines of code • Percentage widths adapt to different page sizes • Includes halfs, thirds, fourths, and ﬁfths • No gutters • Inﬁnite nesting and stacking

Grids control the width

Content controls height

FIXED DIMENSIONS limit the ways in which a module can be reused

TAMING SELECTORS sanity for our stylesheets

SIZE OF THE CSS FILE AND IMPLIED HTTP REQUESTS are the biggest factor for CSS performance

REFLOWS AND RENDERING TIME are (much!) less important

DUPLICATION IS WORSE THAN STALE RULES because we have tools to deal with the latter

DEFINE DEFAULT VALUES Don’t repeat this code in every object

#weatherModule h3{color:red;} #tabs h3{color:blue} DEFINE DEFAULT VALUES Don’t repeat this code in every object

X #weatherModule h3{color:red;} #tabs h3{color:blue} DEFINE DEFAULT VALUES Don’t repeat this code in every object

X #weatherModule h3{color:red;} #tabs h3{color:blue} DEFINE DEFAULT VALUES Don’t repeat this code in every object h1, .h1{...} h2, .h2{...} h3, .h3{...} h4, .h4{...} h5, .h5{...} h6, .h6{...}

DEFINE STRUCTURE IN A SEPARATE CLASS Don’t repeat this code in every object block inner hd bd ft

div.error{...} STYLE CLASSES rather than elements

X div.error{...} STYLE CLASSES rather than elements .error{ most of the code goes here }

X div.error{...} STYLE CLASSES rather than elements .error{ most of the code goes here } div.error{ } p.error{ exceptions only } em.error{ }

div{...} ul{...} p{..} AVOID STYLING ELEMENTS unless deﬁning defaults

div{...} X ul{...} p{..} AVOID STYLING ELEMENTS unless deﬁning defaults .error{...} .section{...} .products{...}

html body .myModule div .hd{...} .myModule2 .hd {...} GIVE RULES THE SAME STRENGTH Use cascade order to overwrite previous rules

X html body .myModule div .hd{...} .myModule2 .hd {...} GIVE RULES THE SAME STRENGTH Use cascade order to overwrite previous rules .myModule .hd{...} .myModule2 .hd{...}

.mod .hd{...} .ie .mod .hd{...} .weatherMod .hd {...} USE HACKS SPARINGLY And don’t let them change your speciﬁcity

.mod .hd{...} X .ie .mod .hd{...} .weatherMod .hd {...} USE HACKS SPARINGLY And don’t let them change your speciﬁcity .mod .hd{color: red; _zoom:1;} .weatherMod .hd{...}

.sidebar ul{...} .header ul {...} AVOID SPECIFYING LOCATION Apply classes to the object you wish to change

X .sidebar ul{...} .header ul {...} AVOID SPECIFYING LOCATION Apply classes to the object you wish to change .mainNav{...} .subNav {...}

AVOID OVERLY SPECIFIC CLASSES they’re all semantic, but limiting

AVOID OVERLY SPECIFIC CLASSES they’re all semantic, but limiting .vehicle{...} .motorcycle{...} .ducati{...} .ducatiMonster620{...} .nicolesDucatiMonster620{...}

AVOID OVERLY SPECIFIC CLASSES they’re all semantic, but limiting .vehicle{...} .motorcycle{...} .ducati{...} X .ducatiMonster620{...} .nicolesDucatiMonster620{...}

#myUniqueIdentifier{...} #myUniqueIdentifier2{...} AVOID SINGLETONS ids can only be used once in any given page Source: Chris Griego

X #myUniqueIdentifier{...} #myUniqueIdentifier2{...} AVOID SINGLETONS ids can only be used once in any given page Source: Chris Griego

Media Subheading Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum. USE MIXINS to avoid repeating code Media Extended Subheading Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

.inner{...} .weatherMod .inner{...} .tr{...} .weatherMod .tr{...} .bl{...} .weatherMod .bl{...} ENCAPSULATION don’t access sub-nodes of an object directly inner

.inner{...} X .weatherMod .inner{...} .tr{...} .weatherMod .tr{...} .bl{...} .weatherMod .bl{...} ENCAPSULATION don’t access sub-nodes of an object directly inner

OOCSS: A REAL LIFE EXAMPLE Gonzalo Cordero Front-End Engineer @Yahoo! inc.

Who

TO SHARE

DESIGN CONSIDERATIONS

DESIGN CONSIDERATIONS ❖ Cross browser compatible

DESIGN CONSIDERATIONS ❖ Cross browser compatible ❖ Multi-language support

DESIGN CONSIDERATIONS ❖ Cross browser compatible ❖ Multi-language support ❖ Accessible

DESIGN CONSIDERATIONS ❖ Cross browser compatible ❖ Multi-language support ❖ Accessible ❖ Aggressive deadline to complete both layout and functionality

The Puzzle

RESULT

WEB COMPROMISES

WEB COMPROMISES ❖ Why does the “easy” turn so complicated?

WEB COMPROMISES ❖ Why does the “easy” turn so complicated? ❖ Why do we need to compromise?

WEB COMPROMISES ❖ Why does the “easy” turn so complicated? ❖ Why do we need to compromise? ❖ Why can’t we rely on a set of solid rules and structures? Like other platforms do?

OOCSS SAVES THE DAY

OOCSS SAVES THE DAY ❖ Single simple markup structure

OOCSS SAVES THE DAY ❖ Single simple markup structure ❖ Cross browser support (even IE 5.5!)

OOCSS SAVES THE DAY ❖ Single simple markup structure ❖ Cross browser support (even IE 5.5!) ❖ Very minimum CSS

OOCSS SAVES THE DAY ❖ Single simple markup structure ❖ Cross browser support (even IE 5.5!) ❖ Very minimum CSS ❖ Scalable, easy to apply to multiple designs

OCSS SAVES THE DAY

AFTER OOCSS

TO CONTRIBUTE

Why can’t the web have great tools to build and design interfaces?

What’s stopping us?

CSSBUILDR ❖ If we said we could reuse the same structure over and over again, what’s stopping us from doing so? ❖ Different modules and page grids can be easily built. ❖ Plug and Play, Mix and Match.

CSSBUILDR: TECH SPECS ❖ Create and modify module contours, backgrounds, font- colors, etc. ❖ In two to three clicks you get a plug-and-play ready module that works cross browser. ❖ Built on top YUI.

THANK YOU DEMO TIME ❖ ygonzalocordero@me.com ❖ Twitter: goonieiam

The Cascade, Grids, Headings, and Selectors from an OOCSS Perspective, Ajax Experience 2009

2 comments

Notes on slide 1

28 Favorites & 1 Event