This document summarizes Stephen Hay's talk "The Back(side) of the Class", in which he discusses different CSS methodologies like OOCSS, SMACSS, BEM, etc. and provides a critical perspective on some of their common claims. Some of his main points are that performance gains from these methods are typically small; they don't truly decouple CSS from HTML; and trying to apply object-oriented patterns to CSS can introduce unnecessary complexity. Overall he advocates for a simpler, more pragmatic approach tailored to individual projects rather than following rigid methodologies.
3. < 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/
4. < 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 " >
< b c l a s s = " t o p " > < b c l a s s = " t l " > < / b > < b c l a s s = " t r " > < / b > < / b >
< 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 " >
< p > < / p >
< u l c l a s s = " s i m p l e L i s t " >
. . .
< / u l >
< / d i v >
< / d i v >
< b c l a s s = " b o t t o m " > < b c l a s s = " b l " > < / b > < b c l a s s = " b r " > < / b > < / b >
< / d i v >
< / d i v >
view-source:http://oocss.org/module.html
5. < 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 " >
< u l c l a s s = " n a v n a v b a r _ _ n a v " >
< 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 >
< / u l >
< / d i v >
view-source:http://getbem.com/introduction/
6. < 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/
14. Please don’t be offended
It’s good to think critically about the tools and methods we
use, and how we use them. This says nothing about their
value when applied to specific problems.
15. Why are there so many
frameworks and
“methodologies”?
Because different people are solving different problems.
22. “Tools don’t solve problems any more, they have become the
problem.”
— PPK, http://www.quirksmode.org/blog/archives/2015/05/tools_dont_solv.html
23. Some hefty claims are made
about these methodologies
Faster parsing / Performance
CSS is not as “tightly coupled” to the markup
More maintainable, less refactoring
24. Performance
Steve Souders on “complex” selectors:
“For most web sites, the possible performance gains from
optimizing CSS selectors will be small, and are not worth the
costs.”
25. “It only becomes a factor if you have a large number of DOM
elements and complex CSS selectors: If you have 20K DOM
elements and 200 complex selectors, it could be bad. If you
have 2K DOM elements and 2K complex selectors, it could be
bad. But most pages have 900 DOM elements and ~50
complex selectors (based on anecdotal data). Optimizing
those 50 complex selectors will not produce a noticeable
improvement in performance.”
26. “Tight coupling”
< n a v >
< u l >
< 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 >
< / u l >
< / n a v >
n a v l i {
. . .
}
27. Not coupled?
< u l c l a s s = " n a v n a v b a r _ _ n a v " >
< 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 >
< / u l >
. n a v _ _ i t e m {
. . .
}
31. We’re trying to approach CSS as if it
were a programming language.
32. 50 Lies Programmers Believe, no. 20
CSS can be “object-oriented” or “functional” rather than a
declarative rules language with a moderately complex
inheritance model.
— Tom Morris, https://tommorris.org/posts/9317
37. < 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 {
. . .
}
39. “However, when it comes to larger, more complex projects,
how you organize your code is a key to efficiency. Not only in
how much time it takes, but also in how much code you write,
and how much a browser has to load. This is especially
important when you’re working with a team of themers, and
when performance is important.”
— http://getbem.com/introduction/
48. My name is Stephen, and I added these
to 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
49. These problems we’re having are real problems, and tools
and methodologies do help solve some of them. It’s our job
to think critically about which problems we’re trying to
solve, and which tools and methods are necessary to that
specific purpose.
In other words, there are no best practices.
52. Embrace the chaos.
The Web is messy. Projects are messy. Development is
messy.
And that’s okay. What’s right for this project?
53. Start simply
What if we started our projects with nothing but plain CSS,
and only added tools and methodologies when absolutely
necessary and not as a default?
59. Refactoring is a good thing
None of us write perfect code the very first time.
60. “Refactoring isn’t rework. It is revision, but it isn’t doing the
work over.”
— Ron Jeffries, http://www.ronjeffries.com/xprog/classics/refactoringisntrework/
61. Documentation
Namespaces are not enough. Code comments are not
enough. If you want people to understand the logic behind
your approach to a given project’s CSS, you need to write
documentation for people.
64. Stop teaching people that this is how
you write CSS
There is no particular “right” way to write CSS.
HTML and CSS are often difficult enough without all the
layers of abstraction and complexity that we add with our
pet frameworks.