the backside of the class (css day 2015)

The Back(side) of the Classaka The Inflammatory but Reasonably Politically Correct“It Depends” TalkStephen Hay, CSS Day 2015

Warning: I’m going to makefun of your pet CSSmethodology.

< d i v c l a s s = " l - h e a d e r " > < d i v c l a s s = " l - c o n s t r a i n e d " > < d i v c l a s s = " l o g o " > < h 2 c l a s s = " h d " > < a h r e f = " / " > < s p a n c l a s s = " h d - l i n e h d - l i n e 1 " < h 3 > A f l e x i b l e g u i d e t o d e v e l o p i n g s i t e s s m a l l a n d l a r g e . < / d i v > < / d i v >< / d i v >

view-source:https://smacss.com/

< d i v c l a s s = " u n i t s i z e 1 o f 3 " > < d i v c l a s s = " m o d " > < d i v c l a s s = " i n n e r " > < d i v c l a s s = " h d " > < h 3 > m o d < / h 3 > < / d i v > < d i v c l a s s = " b d " > . . . < / d i v > < / d i v > < / d i v >< / d i v >

view-source:http://oocss.org/module.html

< d i v i d = " m e n u " c l a s s = " n a v b a r _ _ c o l l a p s e c o l l a p s e " > < l i c l a s s = " n a v _ _ i t e m n a v _ _ i t e m _ a c t i v e " > < a h r e f = " / i n t r o d u c t i o n / " < l i c l a s s = " n a v _ _ i t e m " > < a h r e f = " / n a m i n g / " c l a s s = " n a v _ _ l i n k " > N a m i n g < l i c l a s s = " n a v _ _ i t e m " > < a h r e f = " / f a q / " c l a s s = " n a v _ _ l i n k " > F A Q < / a > < / l i > < / d i v >

view-source:http://getbem.com/introduction/

< d i v c l a s s = " R o w " > < d i v c l a s s = " F l ( s t a r t ) W ( 1 / 2 ) B g c ( # 0 2 8 0 a e . 5 ) H ( 9 0 p x ) " > < / d i v > < d i v c l a s s = " F l ( s t a r t ) W ( 1 / 2 ) B g c ( # 0 2 8 0 a e ) H ( 9 0 p x ) " > < / d i v >< / d i v >< d i v c l a s s = " D ( t b ) W ( 1 0 0 % ) " r o l e = " p r e s e n t a t i o n " > < d i v c l a s s = " D ( t b c ) B g c ( # 0 2 8 0 a e ) H ( 9 0 p x ) " > < / d i v > < d i v c l a s s = " D ( t b c ) B g c ( # 0 2 8 0 a e . 5 ) H ( 9 0 p x ) " > < / d i v >< / d i v > < d i v c l a s s = " I b B o x W ( 5 0 % ) B g c ( # 0 2 8 0 a e . 5 ) H ( 9 0 p x ) " > < / d i v > < ! - -- - > < d i v c l a s s = " I b B o x W ( 5 0 % ) B g c ( # 0 2 8 0 a e ) H ( 9 0 p x ) " > < / d i v >< d i v c l a s s = " D ( f ) " > < d i v c l a s s = " F l x g ( 1 ) B g c ( # 0 2 8 0 a e ) H ( 9 0 p x ) " > < / d i v > < d i v c l a s s = " F l x g ( 1 ) B g c ( # 0 2 8 0 a e . 5 ) H ( 9 0 p x ) " > < / d i v >< / d i v >

http://acss.io/

SMACSS

Bem smacss itcss acss.

Please don’t be offendedIt’s good to think critically about the tools and methods weuse, and how we use them. This says nothing about theirvalue when applied to specific problems.

Why are there so manyframeworks and“methodologies”?Because different people are solving different problems.

OOCSSYahoo, Facebook

SMACSSYahoo, Shopify

BEMYandex

These problems are not necessarily your problems.

There is another reason many of us appropriate otherpeople’s solutions to their own problems…

We are obsessed with our tools.

“Tools don’t solve problems any more, they have become theproblem.”

— PPK, http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html

Some hefty claims are madeabout these methodologies

Faster parsing / PerformanceCSS is not as “tightly coupled” to the markupMore maintainable, less refactoring

PerformanceSteve Souders on “complex” selectors:

“For most web sites, the possible performance gains fromoptimizing CSS selectors will be small, and are not worth thecosts.”

“It only becomes a factor if you have a large number of DOMelements and complex CSS selectors: If you have 20K DOMelements and 200 complex selectors, it could be bad. If youhave 2K DOM elements and 2K complex selectors, it could bebad. But most pages have 900 DOM elements and ~50complex selectors (based on anecdotal data). Optimizingthose 50 complex selectors will not produce a noticeableimprovement in performance.”

“Tight coupling”< n a v > < l i > < a h r e f = " / i n t r o d u c t i o n / " > I n t r o d u c t i o n < / a > < / l i > < l i > < a h r e f = " / n a m i n g / " > N a m i n g < / a > < / l i > < l i > < a h r e f = " / f a q / " > F A Q < / a > < / l i > < / n a v >

n a v l i { . . .}

Not coupled? < l i c l a s s = " n a v _ _ i t e m n a v _ _ i t e m _ a c t i v e " > < a h r e f = " / i n t r o d u c t i o n / " c l a s s = < l i c l a s s = " n a v _ _ i t e m " > < a h r e f = " / n a m i n g / " c l a s s = " n a v _ _ l i n k " > N a m i n g < l i c l a s s = " n a v _ _ i t e m " > < a h r e f = " / f a q / " c l a s s = " n a v _ _ l i n k " > F A Q < / a > < / l i >

. n a v _ _ i t e m { . . .}

Less refactoring?It’s true. But HTML is now your closet.

Now you can do all that refactoring in your HTML. (But atleast it’s not in your CSS!)

Some possible problems

We’re trying to approach CSS as if itwere a programming language.

50 Lies Programmers Believe, no. 20

CSS can be “object-oriented” or “functional” rather than adeclarative rules language with a moderately complexinheritance model.

— Tom Morris, https://tommorris.org/posts/9317

https://www.flickr.com/photos/epublicist/3546059144

Most of the problems class-basedmethods solve are problems that wecaused in the first place.

Modules and inheritance

< d i v c l a s s = " c o n t a c t p e r s o o n t e a s e r " > . . .< / d i v >

. c o n t a c t p e r s o o n { . . .}

. c o n t a c t p e r s o o n . t e a s e r { . . .}

. c o n t a c t p e r s o o n . o v e r v i e w { . . .}

“Modularization encourages over-design.”

— John Daggett

“However, when it comes to larger, more complex projects,how you organize your code is a key to efficiency. Not only inhow much time it takes, but also in how much code you write,and how much a browser has to load. This is especiallyimportant when you’re working with a team of themers, andwhen performance is important.”

— http://getbem.com/introduction/

class-based “methodologies” willnot solve your organisationalproblems.

We’re teaching people that thesemethods are the “correct” way toapproach writing CSS.

Stackoverflow CSS question about Bootstrap

We “need” an increasing number oftools, frameworks, methods anddependencies to do our jobs.

I want to write some CSSCSSSass/LESS/Flavor-of-the-monthSusyAutoprefixerMinifyGruntNode.js/npm?

We want a magical methodology thatworks for every project.

Large-scale, complexEnterprise

From the companies that brought you waterfall processesand ridiculously complex charts and graphs.

All of us are right, respectively.

My name is Stephen, and I added theseto a project to meet a client’s needs.

. w h o l e. h a l f. t h i r d s. f i r s t. l a s t. h i g h l i g h t

These problems we’re having are real problems, and toolsand methodologies do help solve some of them. It’s our jobto think critically about which problems we’re trying tosolve, and which tools and methods are necessary to thatspecific purpose.

In other words, there are no best practices.

Some thoughts

Inheritance is powerful. Are you sureyou don’t want it?

Embrace the chaos.The Web is messy. Projects are messy. Development ismessy.

And that’s okay. What’s right for this project?

Start simplyWhat if we started our projects with nothing but plain CSS,and only added tools and methodologies when absolutelynecessary and not as a default?

Respect the content, seekindependence

. n a v { . . .}

. n a v b a r _ _ n a v { . . .}

https://vimeo.com/128473203

http://alistapart.com/article/axiomatic-css-and-lobotomized-owls

Refactoring is a good thingNone of us write perfect code the very first time.

“Refactoring isn’t rework. It is revision, but it isn’t doing thework over.”

— Ron Jeffries, http://www.ronjeffries.com/xprog/classics/refactoringisntrework/

DocumentationNamespaces are not enough. Code comments are notenough. If you want people to understand the logic behindyour approach to a given project’s CSS, you need to writedocumentation for people.

Asciidoctor.org

Stop teaching people that this is howyou write CSSThere is no particular “right” way to write CSS.

HTML and CSS are often difficult enough without all thelayers of abstraction and complexity that we add with ourpet frameworks.

Keep things simple.

Respect the content.

Think critically.

Thank you!@stephenhay

the-haystack.com

responsivedesignworkflow.com

the backside of the class (css day 2015)

Software

i n e d d

o p i n g s i t e s

i n e h d

d e r d

p s e c o

o d b c

t i o n d

u n i t s i z e