css_guidelines.rst 4.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186
  1. CSS coding guidelines
  2. ===========================
  3. Our CSS is written in Sass, using the SCSS syntax.
  4. Compiling
  5. ~~~~~~~~~
  6. The SCSS source files are compiled to CSS using the
  7. `gulp <http://gulpjs.com/>`_ build system.
  8. This requires `Node.js <http://nodejs.org>`_ to run.
  9. To install the libraries required for compiling the SCSS,
  10. run the following from the Wagtail repository root:
  11. .. code-block:: console
  12. $ npm install --no-save
  13. To compile the assets, run:
  14. .. code-block:: console
  15. $ npm run build
  16. Alternatively, the SCSS files can be monitored,
  17. automatically recompiling when any changes are observed, by running:
  18. .. code-block:: console
  19. $ npm start
  20. Linting SCSS
  21. ~~~~~~~~~~~~
  22. Wagtail uses the `stylelint <https://stylelint.io/>`_ linter.
  23. You'll need Node.js and npm on your development machine.
  24. Ensure project dependencies are installed by running ``npm install --no-save``
  25. Run the linter from the wagtail project root:
  26. .. code-block:: console
  27. $ npm run lint:css
  28. The linter is configured to check your code for adherance to the guidelines
  29. below, plus a little more.
  30. If you want to autofix errors, you can run that command directly with:
  31. .. code-block:: console
  32. $ npm run lint:css -- --fix
  33. Spacing
  34. -------
  35. - Use soft-tabs with a four space indent. Spaces are the only way to
  36. guarantee code renders the same in any person's environment.
  37. - Put spaces after ``:`` in property declarations.
  38. - Put spaces before ``{`` in rule declarations.
  39. - Put line breaks between rulesets.
  40. - When grouping selectors, put each selector on its own line.
  41. - Place closing braces of declaration blocks on a new line.
  42. - Each declaration should appear on its own line for more accurate
  43. error reporting.
  44. - Add a newline at the end of your ``.scss`` files.
  45. - Strip trailing whitespace from your rules.
  46. - Add a space after the comma, in comma-delimited property values e.g ``rgba()``
  47. Formatting
  48. ----------
  49. - Use hex color codes ``#000`` unless using ``rgba()`` in raw CSS
  50. (SCSS' ``rgba()`` function is overloaded to accept hex colors as a
  51. param, e.g., ``rgba(#000, .5)``).
  52. - Use ``//`` for comment blocks (instead of ``/* */``).
  53. - Use single quotes for string values
  54. ``background: url('my/image.png')`` or ``content: 'moose'``
  55. - Avoid specifying units for zero values, e.g., ``margin: 0;`` instead
  56. of ``margin: 0px;``.
  57. - Strive to limit use of shorthand declarations to instances where you
  58. must explicitly set all the available values.
  59. Sass imports
  60. ------------
  61. Leave off underscores and file extensions in includes:
  62. .. code-block:: scss
  63. // Bad
  64. @import 'components/_widget.scss'
  65. // Better
  66. @import 'components/widget'
  67. Pixels vs. ems
  68. --------------
  69. Use ``rems`` for ``font-size``, because they offer
  70. absolute control over text. Additionally, unit-less ``line-height`` is
  71. preferred because it does not inherit a percentage value of its parent
  72. element, but instead is based on a multiplier of the ``font-size``.
  73. Specificity (classes vs. ids)
  74. -----------------------------
  75. Always use classes instead of IDs in CSS code. IDs are overly specific and lead
  76. to duplication of CSS.
  77. When styling a component, start with an element + class namespace,
  78. prefer direct descendant selectors by default, and use as little
  79. specificity as possible. Here is a good example:
  80. .. code-block:: html
  81. <ul class="category-list">
  82. <li class="item">Category 1</li>
  83. <li class="item">Category 2</li>
  84. <li class="item">Category 3</li>
  85. </ul>
  86. .. code-block:: scss
  87. .category-list { // element + class namespace
  88. // Direct descendant selector > for list items
  89. > li {
  90. list-style-type: disc;
  91. }
  92. // Minimal specificity for all links
  93. a {
  94. color: #f00;
  95. }
  96. }
  97. Class naming conventions
  98. ------------------------
  99. Never reference ``js-`` prefixed class names from CSS files. ``js-`` are
  100. used exclusively from JS files.
  101. Use the SMACSS ``is-`` `prefix <https://smacss.com/book/type-state>`__
  102. for state rules that are shared between CSS and JS.
  103. Misc
  104. ----
  105. As a rule of thumb, avoid unnecessary nesting in SCSS. At most, aim for
  106. three levels. If you cannot help it, step back and rethink your overall
  107. strategy (either the specificity needed, or the layout of the nesting).
  108. Examples
  109. --------
  110. Here are some good examples that apply the above guidelines:
  111. .. code-block:: scss
  112. // Example of good basic formatting practices
  113. .styleguide-format {
  114. color: #000;
  115. background-color: rgba(0, 0, 0, .5);
  116. border: 1px solid #0f0;
  117. }
  118. // Example of individual selectors getting their own lines (for error reporting)
  119. .multiple,
  120. .classes,
  121. .get-new-lines {
  122. display: block;
  123. }
  124. // Avoid unnecessary shorthand declarations
  125. .not-so-good {
  126. margin: 0 0 20px;
  127. }
  128. .good {
  129. margin-bottom: 20px;
  130. }