Movatterモバイル変換

oocss for javascript pirates with @jquerypgh rigging, full speed ahead! brian cavalier

ahoy! demo!http://bit.ly/css3-digital-clock fork it on github!

part I – oocss distilled aye! is it good fer drinkin’, matey?

what is oocss? term coined by nicole sullivan*. but what is it? css with a focus on objects plain-old css 2.1 and css 3 works with html4 or html5 works with all major browsers** * http://stubbornella.org **well… ie 6 needs some help, as usual

basics of oocss maximizes reuse of css rules

basics of oocss maximizes reuse of css rules creates maintainable, concise css

basics of oocss maximizes reuse of css rules creates maintainable, concise css relies on two core principles: separation of container from content separation of structure from skin

basics of oocss maximizes reuse of css rules creates maintainable, concise css relies on two core principles: separation of container from content separation of structure from skin and, for js pirates: identity vs. state

container vs. content content objects flow naturally container objects restrict where/how content objects flow containers don’t have to be only grids and columns!

container vs. content<section class=“my-oocss-container”>  <p class=“my-oocss-content” >…</p> <span>some other content</span></section>

container vs. content content can now be laid-out differently by changing the container object / container class the container and content objects don’t always have to be separate, but often they are!

structure vs. skin structure classes determine layout skin classes determine the look (aka “theme”, “styling”)

structure vs. skin<aside class=“structure skin”>…</aside>.structure { .skin { ﬂoat: left; color: #2faced; width: 8em; border: 1px; max-height: 20em; }}

structure v. skin if we want to reuse the skin class, the structure declarations don’t tag along if we want to reuse the structure class, we don’t have skin “stowaways”, either

aaaarrrrrhh!!not another “cssbest practices”!?! blimey!!this oocss stuff is already startin’ to make me trigger finger itch!

“learn to love grids”* use grid layouts to position content grid columns determine content width content height flows naturally *http://www.slideshare.net/stubbornella/object-oriented-css

aaaarrrrrhh!!i ain’t buildin’no cms system! shiver me timbers!*all this lollygagging with grids, columns, and content… i want dialogs! data-linking! templates! *translation: “wut the f___!”

oocss vs. architecture “Each layer in the web stack has its own architecture.”* – Nicole oocss objects don’t correlate with back-end components / views – they are completely independent* http://www.stubbornella.org/content/2010/06/12/visual-semantics-in-html-and-css/

aaaarrrrrhh!! this oocss concoction ain’t drinkable!there’s no way i’m going to rejigger every one of me mvc-based php templates so it can work the “oocss way”

it’s too bad, too… some of that oocss stuff seemed useful… hmmm…let’s take a look at oocss from the eye of a javascript pirate…

part II – oocss in the pirate’s eye in your good eye, anyway, Brendan! (aaarrrrrrhhh!!!)

oocss objects an oocss object consists of the following parts: 1) an html fragment / dom nodes 2)associated css rules and resources (fonts, images) 3)javascript (behavior, events, etc.)

oocss “construction” an oocss object is not actually constructed rather, its parts are associated via a css class name: 1)<tag class=“my-oocss-class”>…</tag> 2).my-oocss-class { /* … */ } 3)$(‘.my-oocss-class’) .click(function () { /*…*/ });

oocss inheritance oocss objects inherit from other oocss objects (sound familiar? it should to a js pirate!)

oocss inheritance base specializations / mixins { - <tag class=“class1 class2 class3”>…</tag> inheritance is defined in html and css this isn’t broken, but isn’t ideal**sass and less.css attempt to “fix” this (and do a good job of it)

oocss inheritance order doesn’t matter {<tag class=“class1 class2 class3”>…</tag>.class1 { } overrides matters! order.class2 { }.class3 { }

oocss inheritance classical oo: classes inherit attributes + behavior

oocss inheritance classical oo: classes inherit attributes + behavior pure prototypal: objects inherit attributes + behavior

oocss inheritance classical oo: classes inherit attributes + behavior pure prototypal: objects inherit attributes + behavior oocss: objects inherit attributes + run-time state inheritance is defined two different ways

oocss inheritance type 1<section class=“base special”>…</section>.base { .special { ﬂoat: left; margin-right: -0.5em; width: 8em; width: 8.5em;} }

oocss inheritance type 2 span inherits from button - <button class=“simple-action with-icon”> <span>content / data</span> </button>.with-icon { color: #bada55; }.with-icon span { /* inherits with-icon! */ margin-left: 32px;}

oocss state inheritance identity state { {<tag class=“base special state1 state2”/>.base { }.special { /* inherits .base */ }.state1 { /* run-time overrides */ }.state2 { /* more overrides */ }

oocss state inheritance<div class=“base-view my-view unbound”> <h4>some title</h4> <span>raw content / data</span></div>.base-view.unbound { color: #abacab; }.base-view.unbound span { visibility: hidden; }

part III – fringe benefits fortune and glory! (aaarrrrrhhhh!!!!)

loose coupling message passing == loose coupling state classes are messages! change html/css without changing js API == add/remove/toggleClassbad: $(‘.my-widget ul’).css(‘display’, ‘none’); $(‘.my-widget’).addClass(‘no-list’);good: .no-list ul { display: none; }

separation of concerns styling / layout separated from behavior css/html and js dev work independently bad: good:$(‘.my-view’) $(‘.my-view’) .find(‘li’) .addClass(‘filtered’); .css(‘color’, ‘red’) –––––––––––––––– .filter(‘.obsolete’) .filtered li { color: red; } .css(‘color’, ‘gray’); .filtered li.obsolete { color: gray; }

organized css css is organized into object “classes” just like all of your other code.progress-bar { }.progress-bar .cancel-button { }.progress-bar .spinner { }.progress-bar .progress-frame div span { }.progress-bar.progress-complete { }.progress-bar.progress-error { }

part IV – step by step aaacckkk! too much rope!show me how not to get meself hanged!

identify objects #1 rule: ignore the HTML! scan the wireframes for oocss objects: can it be reused? does it have it’s own behavior? For each: “What is it?” -> Identity list run-time states

identify objectsprogress bar object states content containers

Identity + state classes Identity (“is a”): progress-bar specialization: progress-upload states progress-initializing progress-uploading progress-ﬁnalizing progress-complete progress-canceled progress-error

html template<div class="progress-bar progress-upload"> <h2>progress title</h2> <div class="progress-frame"> <div><span></span></div> </div> <a href="#" class="cancel-action">x</a> <p>transaction status</p></div>

css classes.progress-bar { }.progress-bar.progress-canceled h2 { }.progress-bar.progress-complete h2 { }.progress-bar.progress-error h2 { }....progress-frame { }.progress-frame div { }.progress-frame div span { }.progress-display .cancel-action { }....progress-upload { }

javascript controller$(‘.progress-bar’).each(function () { var progressBar = $(this); progressBar.ﬁnd(‘.cancel-action’) .click(function () { progressBar.addClass(‘progress-canceled’) .ﬁnd(‘h2’).text(‘Canceled’); /* coordinate actual cancel work here */ return false; });});

part V – demo!yo ho ho and a hogshead of rum!

part VI – pitfalls + antipatterns follow this sage advice or ye’ll end up in a gibbet!!

.css() is EVIL css does not belong in your javascript!* (*except when it does)

.css() is EVIL css does not belong in your javascript!* (*except when it does) animations, too! fadeIn(), fadeOut(), animate(), hide(), show()

.css() is EVIL css does not belong in your javascript!* (*except when it does) animations, too! fadeIn(), fadeOut(), animate(), hide(), show() css3 + progressive enhancement or

.css() is EVIL css does not belong in your javascript!* (*except when it does) animations, too! fadeIn(), fadeOut(), animate(), hide(), show() css3 + progressive enhancement or regressive enhancement: jquery css transitions, cujo.js

avoid IDs and elements bad: div.my-class {} #myNode.my-class {} these create unnecessary specificity ids lure you into creating non-reusable rules

oocss vs. ie6 gotcha: .base.state { /* ie6 ignores .base */ } solutions: name-spaced (unambiguous) states e.g.: .base.base-state selectivizr, cujo.js

belay that HTML, mate In any reasonably complex system, writing HTML and CSS first is an antipattern Start with wireframes, identify objects and their states, then write HTML

discrete vs. continuous Trying to model continuous values with OOCSS state be askin’ fer a flogging..progress-0 .progress-frame div span { width: 0% }.progress-1 .progress-frame div span { width: 1% }....progress-99 .progress-frame div span { width: 99% }.progress-100 .progress-frame div span { width: 100%}

horizontal class explosion <section class=“intro colorful-intro orange has- callout has-second-callout exclusive front- page”> Use the cascade: “colorful-intro” is probably a specialization of “intro” Consolidate non-states: e.g. “orange” may be a characteristic of “colorful-intro” Consider SASS/SCSS or Less.css

vertical class explosion<div class="progress-bar progress-upload"> <h2 class="progress-canceled">progress title</h2> <div class="progress-frame progress-canceled"> <div><span class="progress-canceled"></span></div> </div> <a href="#" class="cancel-action progress-canceled">x</a> <p class="progress-canceled">canceled!</p></div>

vertical class explosion Place state classes as high up in the component’s HTML as possible Use OOCSS inheritance. Remember that descendant nodes can inherit run-time state!<div class="progress-bar progress-upload progress-canceled"> <h2>progress title</h2> ...</div>

Keelhauled HTML Having sections of permanently hidden HTML is a bad code smell analog clock: nearly half the HTML elements are permanently hidden Review your objects and wireframes Probably time to refactor HTML & CSS

part VII - what be next?weigh anchor and hoist the jib, me hearties, we be all in the wind!

oocss design patterns! codifying oocss design patterns 3 so far: Initial State Pattern Revealing Specialization Pattern Inherited Specialization Pattern more on the way!

thanks! john hann brian cavalier @unscriptable @briancavalier life image, inc. hovercraft studioshttp://lifeimage.com http://hovercraftstudios.com

questions?ye must phrase all queries like a true seadog! landlubbers will be keel-hauled(or tarred-and-feathered – choose yer poison)

Go Steelers!You didn’t think it’d be all Pirates, did you?

imagesjolly roger: http://flickr.com/photos/earlgpirates: “Don’t mess with pirates - Declan Hann” http://www.flickr.com/photos/slipstreamblue/2716444681/ http://www.flickr.com/photos/brothermagneto/3476288029/ http://www.flickr.com/photos/jsconf/4587502948/ http://www.flickr.com/photos/fenchurch/237726110/moon shine still: http://flickr.com/photos/seanlloyd/gold coins: http://www.flickr.com/photos/myklroventine/3400039523/dead pirate: http://www.flickr.com/photos/jeffreykeefer/540423620/corsair: http://www.flickr.com/photos/portofsandiego/4952170821/ducks: http://www.flickr.com/photos/tiefpunkt/2571937817/piece of eight: http://flickr.com/photos/woodysworld1778/pirate daleks!: http://flickr.com/photos/54459164@N00/5003883529/

Movatterモバイル変換

Change Language

OOCSS for Javascript pirates at jQueryPgh meetup

Embed presentation

Recommended

More Related Content

What's hot

Similar to OOCSS for Javascript pirates at jQueryPgh meetup

Recently uploaded

OOCSS for Javascript pirates at jQueryPgh meetup

Editor's Notes