Skip to content

Commit 70252bb

Browse files
committed
Docs: added comments
1 parent 5ac7094 commit 70252bb

File tree

1 file changed

+40
-10
lines changed

1 file changed

+40
-10
lines changed

css_architecture.md

+40-10
Original file line numberDiff line numberDiff line change
@@ -57,6 +57,7 @@ For example, don't:
5757
```
5858

5959
Instead, create classes that extend:
60+
6061
```css
6162
.widget {
6263
/* base rules */
@@ -91,6 +92,7 @@ In general, you should try to avoid tag selectors. Apply classes directly to the
9192
A *qualified selector* is one that includes the HTML element, for example, `div.error` is a *qualified selector*. In most cases it reduces reusability.
9293

9394
For example, instead of this:
95+
9496
```css
9597
.error {
9698
color: red;
@@ -115,12 +117,14 @@ Do this:
115117
In the event that you want to use a qualified selector to indicate the HTML element that the class is intended for, use the following convention.
116118

117119
Instead of:
120+
118121
```css
119122
ul.nav {}
120123
```
121124

122125
Do this:
123-
```css
126+
127+
```css
124128
/*ul*/.nav {}
125129
```
126130

@@ -135,6 +139,7 @@ In this example `.title` is too common a name. It may end up being used somewher
135139
```
136140

137141
Instead, do this:
142+
138143
```css
139144
.widget {}
140145
.widget__title {}
@@ -171,6 +176,7 @@ The *Single Responsibility Principle* is the idea that our CSS should be compose
171176
```
172177

173178
We can break these two classes out into four smaller, reusable responsibilities:
179+
174180
```css
175181
.box {
176182
display: block;
@@ -226,6 +232,7 @@ You would then write new, separate code to handle the content inside of that lay
226232

227233
</div>
228234
```
235+
229236
Code which adheres to the *separation of concerns* can be more confidently modified, edited, extended, and maintained because we know how far its responsibilities reach.
230237

231238

@@ -337,6 +344,7 @@ These suggestions use [BEM](http://getbem.com/naming/)-like conventions.
337344
```
338345

339346
For example:
347+
340348
```css
341349
.nav {
342350
/* rules */
@@ -396,6 +404,7 @@ In the event that you absolutely need to override something with `!important;`,
396404
There are a number of different approaches for categorizing your CSS.
397405

398406
[SMACSS](https://smacss.com/book/categorizing) example:
407+
399408
```css
400409
/* BASE */
401410
/* The defaults, mostly single element selectors */
@@ -414,6 +423,7 @@ There are a number of different approaches for categorizing your CSS.
414423
```
415424

416425
[MCSS](https://operatino.github.io/MCSS/en/) example:
426+
417427
```css
418428
/* FOUNDATION */
419429
/* resets */
@@ -432,11 +442,10 @@ Ultimately, you have to find a pattern that works for you and your team. The str
432442

433443
```css
434444
/* VARIABLES */
435-
/* DEFAULTS */
436-
/* TYPOGRAPHY */
437-
/* LINKS & BUTTONS */
445+
/* BASE */
438446
/* LAYOUT */
439-
/* COMPONENTS */
447+
/* COMPONENTS */
448+
/* LINKS & BUTTONS */
440449
/* COSMETIC */
441450
/* UTILITY */
442451
/* STATE */
@@ -486,11 +495,11 @@ Think about *dependency direction*. There are two ways you can write HTML/CSS:
486495

487496
### 1. CSS that depends on HTML
488497

489-
This is when you name your classes based on your HTML, for example `author-bio`, or `footer-links`. In this model, your HTML is re-stylable (think [CSS Zen Garden](http://www.csszengarden.com/)) but your **CSS is not reusable**.
498+
This is when you name your classes based on your HTML, for example `author-bio`, or `footer-links`. In this model, your HTML is restyleable (think [CSS Zen Garden](http://www.csszengarden.com/)) but your **CSS is not reusable**.
490499

491500
### 2. HTML that depends on CSS
492501

493-
This is when you name your classes in a content-agnostic way after repeating patterns in your UI, for example `media-card` or `sub-links`. In this model your CSS is reusable but your HTML is not as re-stylable.
502+
This is when you name your classes in a content-agnostic way after repeating patterns in your UI, for example `media-card` or `sub-links`. In this model your CSS is more reusable but your HTML is not as restyleable (as components marked with the same class are fixed to look the same).
494503

495504
Choosing reusability will result in more generic class names like:
496505
```css
@@ -505,23 +514,44 @@ The idea of breaking things up for reusability like this is a big part of [OOCSS
505514

506515
### Summary:
507516

517+
In the end neither approach is right or wrong. The question to ask is... for the project you're working on, what would be more valuable: restyleable HTML or reusable CSS?
518+
519+
Consider this:
520+
508521
- The primary purpose of a class name is to provide a hook for CSS or JavaScript.
509522
- Class names impart little or no semantic information to machines or human readers.
510523
- Semantics are already served by the HTML markup.
511524
- Class names should communicate useful information to developers. For example:
525+
512526
```html
513527
<div class="news">
514528
<h2>News </h2>
515529
<p>... </p>
516530
</div>
517531
```
532+
518533
Giving the class name `news` provides no useful information and ensures the style can't be used for anything other than news.
519534

520535
In short, pick a name that is sensible but somewhat ambiguous. **Aim for high reusability**.
521536

537+
Note however that the more a component does, or the more specific a component is, the harder it is to reuse. This is where we may want to *also* use some [Utility-first CSS](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/) to help reuse components. For example, utility classes for common visual tweaks like:
538+
539+
- Text sizes, colors, and weights
540+
- Border colors, widths, and positions
541+
- Background colors
542+
- Flexbox utilities
543+
- Padding and margin helpers
544+
545+
To take thinks further (as Tailwind's creator explains in the link above), these utility classes can also be used to remove component classes that will never actually get reused (e.g. main navigation bar), thus removing of a lot of bloat and complexity in stylesheets.
546+
547+
Keep in mind though, the cost od using too much utility-first CSS, is your code can become harder to read and maintain in the long-term. There’s also a deeper problem: because you are essentially recreating the CSS API with utility classes, you can end up with a huge file.
548+
522549
------
523550

524-
## Sources:
525-
[cssguidelin.es](https://cssguidelin.es/)
526-
[About HTML semantics and front-end architecture](http://nicolasgallagher.com/about-html-semantics-front-end-architecture/)
551+
## Sources:
552+
553+
[About HTML semantics and front-end architecture](http://nicolasgallagher.com/about-html-semantics-front-end-architecture/)
554+
[cssguidelin.es](https://cssguidelin.es/)
527555
[codeguide.co](http://codeguide.co/)
556+
[CSS Utility Classes and "Separation of Concerns"](https://adamwathan.me/css-utility-classes-and-separation-of-concerns/)
557+

0 commit comments

Comments
 (0)