Local styling with CSS Modules

Local styling with CSS Modules

CSS is well known for being aggressively global. This very behaviour makes it difficult to scale. Style isolation and dead code elimination are only two of the many problems encountered when working with CSS on large and long-lasting codebases.

That’s why a lot of clever people came up with a lot of clever ideas to make it easier to write locally-scoped, easy-to-test, composable and scalable CSS. Among these ideas, one seems to have gained a lot of traction lately: CSS Modules.

In this talk, we will see what are CSS Modules, what they intend to solve, and how to use them. I think you’ll be surprised how little difference there is between authoring CSS Modules, and preprocessor-powered stylesheets.

729edf889ced7863dedba95452272bca?s=128

Hugo Giraudel

May 20, 2016
Tweet

Transcript

  1. berlin amsterdam los angeles san francisco singapore edenspiekermann_ Local styling

    with CSS Modules @HugoGiraudel 20 May 2016
  2. @HugoGiraudel Front-end developer Edenspiekermann Berlin, Germany

  3. Another CSS in JS thing?

  4. Not about making CSS dependant on JS in the browser

  5. About crafting a CSS pipeline (in JavaScript)

  6. “CSS in JS” could as well be “CSS in Ruby”

  7. We had CSS in Ruby for years with Sass

  8. “CSS in JS” is reasonable

  9. CSS from JS in the browser would suck

  10. CSS Modules

  11. Glen Maddern Mark Dalgleish Tobias Koppers

  12. JS-powered CSS pipeline

  13. Webpack Browserify JSPM & moar…!

  14. Fixing (most) CSS flaws

  15. None
  16. “CSS isn’t broken”

  17. Hahaha. Haha. Ha.

  18. Global namespace

  19. Dependency management

  20. Dead code elimination

  21. Configuration sharing

  22. Well specified but incomplete

  23. Fine! What is it?

  24. A system where everything is local

  25. No more global namespace

  26. Not about syntax

  27. Consider a title

  28. None
  29. None
  30. No filename repetition

  31. None
  32. None
  33. None
  34. None
  35. None
  36. Not inline styles

  37. Still classes

  38. Configurable output

  39. css-loader ?modules &localIdentName=
 [name]__[local]

  40. None
  41. Composition

  42. Good ol’ button

  43. None
  44. Okay, Sass first

  45. None
  46. None
  47. None
  48. Now, CSS Modules

  49. None
  50. None
  51. None
  52. None
  53. None
  54. Not like @extend

  55. No selector merge

  56. Not like @mixin

  57. No style duplication

  58. Just class composition

  59. Dependency management

  60. Again, composes

  61. None
  62. None
  63. None
  64. None
  65. None
  66. Explicit dependencies

  67. Sharing styles

  68. COMPOSE ALL THE THINGS!

  69. None
  70. None
  71. Global classes?

  72. :global

  73. None
  74. None
  75. Shared values?

  76. @value

  77. None
  78. None
  79. Basically (local) variables

  80. Explicit dependencies

  81. Can be renamed

  82. None
  83. But, but, but…
 BEM?

  84. Helps with global namespace

  85. Brain power, consistency, strictness…

  86. None
  87. Not needed anymore!

  88. But, but, but…
 Webpack?

  89. postcss- modules

  90. Statically compiled

  91. None
  92. But, but, but…
 atomic CSS?

  93. Perfect candidate

  94. None
  95. Compose from the stylesheet

  96. None
  97. Have markup updated

  98. None
  99. But, but, but…
 Sass?

  100. Not mutually exclusive

  101. None
  102. Sass makes CSS easier to write

  103. CSS Modules make CSS easier to maintain

  104. Why not both?

  105. Let’s sum up

  106. JS-powered CSS pipeline

  107. Everything
 is local

  108. Global namespace no more

  109. Pluggable in any pipeline

  110. Pretty rad

  111. berlin amsterdam los angeles san francisco singapore edenspiekermann_ Thank you!

    @HugoGiraudel 20 May 2016