Frontend - unders/mywiki GitHub Wiki

Links

Guidelines

  • The best approach that I’ve found is for the CSS to assume as little HTML structure as possible.
  • The CSS should define how a set of visual elements look and (in order to minimize coupling with the HTML) those elements should look as they’re defined regardless of where they appear in the HTML
  • If a certain component needs to look different in a different scenario, it should be called something different and it’s the HTML’s responsibility to call it that.
  • The CSS defines what your components look like, and the HTML assigns those looks to the elements on the page. The less the CSS needs to know about the HTML structure the better.
  • In general, components should define how they look, but not their layout or position. Be careful when you see properties like background, color, and font in the same rule as position, width, height, and margin.
  • Layout and position should be handled by either a separate layout class or a separate container element. (Remember that to effectively separate content from presentation it’s often essential to separate content from its container.)

Best practices

Be intentional

  • Applying classes directly to the elements you want to style is the best way to keep your CSS predictable

Separate your concerns

  • In general, components should define how they look, but not their layout or position.
  • Layout and position should be handled by either a separate layout class or a separate container element.

Namespace your classes

  • Namespacing your classes keeps your components self-contained and modular.

Extend components with modifier classes

  • When an existing component needs to look slightly different in a certain context, create a modifier class to extend it.

Organize Your CSS Into a Logical Structure

  • Base consists of reset rules and element defaults.
  • Layout is for positioning of site-wide elements as well as generic layout helpers like grid systems.
  • Components (often called modules) are reusable standalone visual elements.
  • Templates don’t stand on their own and rarely describe look and feel. Instead, they’re single, repeatable patterns that can be put together to form a component.
  • state refers to styling that can be toggled on or off via JavaScript.

Use Classes For Styling And Styling Only

  • My recommendation is to give all non-styled classes a prefix. I use .js- for JavaScript.
  • All classes without a prefix are for styling and styling only.

Name your classes with a logical structure

# Templates Rules (using Sass placeholders)
%template-name { }
%template-name--modifier-name { }
%template-name__sub-object { }
%template-name__sub-object--modifier-name { }

# Component Rules
.component-name { }
.component-name--modifier-name { }
.component-name__sub-object { }
.component-name__sub-object--modifier-name { }

# Layout Rules
.l-layout-method { }
.grid { }

# State Rules
.is-state-type { }

# Non-styled JavaScript Hooks
.js-action-name { }
```

Example

/* A component */ .button-group { }

/* A component modifier (modifying .button) */ .button--primary { }

/* A component sub-object (lives within .button) */ .button__icon { }

/* A layout class */ .l-header { }


### Preprocessors
* Never use a mixin if you’re not passing an argument. Mixins without arguments are much better used as templates which can be extended.
* Never use @extend on a selector that isn’t a single class. It doesn’t make sense from a design perspective and it bloats the compiled CSS.
* Never use @extend for UI components in component modifier rules because you lose the inheritance chain (more on this in a bit).
* As a general rule, I never extend UI components or anything that I might want to know the type of later. This is what templates are for and another way to help distinguish between templates and components. A template is something you wouldn’t ever need to target in your application logic, and therefore can be safely extended with a preprocessor.

.modal { @extend %dialog; @extend %drop-shadow; @extend %statically-centered; /* other modal styles */ }

.modal__close { @extend %dialog__close; /* other close button styles */ }

.modal__header { @extend %background-gradient; /* other modal header styles */ }


## Component vs template
To provide a concrete example, a component might be a modal dialog box. The modal might have the site’s signature background gradient in the header, it might have a drop shadow around it, it might have a close button in the top right corner, and it might be positioned fixed and centered vertically and horizontally. Each of these four patterns might be used again and again all over the site, so you wouldn’t want to have to recode those patterns each time. As such they’re all templates, and together they comprise the modal component.

I typically don’t use template classes in the HTML unless I have a good reason. Instead I use a preprocessor to include the template styles in the component definition.

### Books
* [frontendhandbook](http://www.frontendhandbook.com/)