Successfully reported this slideshow.

The Backside of the Class (CSS Day 2015)

7

Share

Upcoming SlideShare
High Performance Webdesign
High Performance Webdesign
Loading in …3
×
1 of 66
1 of 66

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

The Backside of the Class (CSS Day 2015)

  1. 1. The Back(side) of the Class aka The Inflammatory but Reasonably Politically Correct “It Depends” Talk Stephen Hay, CSS Day 2015
  2. 2. Warning: I’m going to make fun of your pet CSS methodology.
  3. 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. 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. 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. 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/
  7. 7. <font></font>
  8. 8. OOCSS
  9. 9. SMACSS
  10. 10. ITCSS
  11. 11. BEM
  12. 12. ACSS
  13. 13. Bem smacss itcss acss.
  14. 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. 15. Why are there so many frameworks and “methodologies”? Because different people are solving different problems.
  16. 16. OOCSS Yahoo, Facebook
  17. 17. SMACSS Yahoo, Shopify
  18. 18. BEM Yandex
  19. 19. These problems are not necessarily your problems.
  20. 20. There is another reason many of us appropriate other people’s solutions to their own problems…
  21. 21. We are obsessed with our tools.
  22. 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. 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. 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. 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. 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. 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 { . . . }
  28. 28. Less refactoring? It’s true. But HTML is now your closet.
  29. 29. Now you can do all that refactoring in your HTML. (But at least it’s not in your CSS!)
  30. 30. Some possible problems
  31. 31. We’re trying to approach CSS as if it were a programming language.
  32. 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
  33. 33. https://www.flickr.com/photos/epublicist/3546059144
  34. 34. Most of the problems class-based methods solve are problems that we caused in the first place.
  35. 35. Modules and inheritance
  36. 36. < 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 { . . . }
  37. 37. “Modularization encourages over-design.” — John Daggett
  38. 38. “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/
  39. 39. class-based “methodologies” will not solve your organisational problems.
  40. 40. We’re teaching people that these methods are the “correct” way to approach writing CSS.
  41. 41. Stackoverflow CSS question about Bootstrap
  42. 42. We “need” an increasing number of tools, frameworks, methods and dependencies to do our jobs.
  43. 43. I want to write some CSS CSS Sass/LESS/Flavor-of-the-month Susy Autoprefixer Minify Grunt Node.js/npm ?
  44. 44. We want a magical methodology that works for every project.
  45. 45. Large-scale, complex Enterprise From the companies that brought you waterfall processes and ridiculously complex charts and graphs.
  46. 46. All of us are right, respectively.
  47. 47. 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
  48. 48. 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.
  49. 49. Some thoughts
  50. 50. Inheritance is powerful. Are you sure you don’t want it?
  51. 51. Embrace the chaos. The Web is messy. Projects are messy. Development is messy. And that’s okay. What’s right for this project?
  52. 52. 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?
  53. 53. Respect the content, seek independence
  54. 54. . n a v { . . . } . n a v b a r _ _ n a v { . . . } < u l c l a s s = " n a v n a v b a r _ _ n a v " > < / u l >
  55. 55. https://vimeo.com/128473203
  56. 56. http://alistapart.com/article/axiomatic-css-and- lobotomized-owls
  57. 57. Refactoring is a good thing None of us write perfect code the very first time.
  58. 58. “Refactoring isn’t rework. It is revision, but it isn’t doing the work over.” — Ron Jeffries, http://www.ronjeffries.com/xprog/classics/refactoringisntrework/
  59. 59. 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.
  60. 60. Asciidoctor.org
  61. 61. 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.
  62. 62. Keep things simple. Respect the content. Think critically.
  63. 63. Thank you! @stephenhay the-haystack.com responsivedesignworkflow.com

×