What is this?

This is a custom SCSS framework made by and for idiaz.roncero.

It sets sensible defaults, exposes a highly configurable _config.scss file and makes use of the following libraries and techniques:

• Ritmo for vertical rhythm.
• Breakpoint for a leaner @media-query syntax.
• Family for syntactic sugar around nth-* selectors
• Palx for creating a palette based on a single color and its shades.

Huesos is (somewhat) opinionated

Huesos is not as opinionated as tools like Bootstrap or Foundation, but there are some common rules that are imposed on the whole project (and thus not exposed on the _config.scss file)

• Margins are always applied as margin-bottom.
  This means that the main block-level elements that compose a page (<p>, <header>, <article>, <div> and the like) only have its margin-bottom set, thus ensuring consistent vertical spacing and avoiding margin overlap and gotchas.

• Always use SVG
  No icon fonts, no images. SVG FTW.

• Vertical rhythm is important, but not mandatory
  We use ritmo.scss and its own functions and mixins (mainly ritmo($unit)) to keep a constant vertical rhythm. You can use $show-grid to test it.
  Still, vertical rhythm is not mandatory, it could and even should be avoided on specific ocasions (like smaller line-heights on bigger type sizes). Vertical rhythm is to be used as a tool rather than a constraint.

• Mobile-First
  We use the mobile-first approach to @media queries and responsive web design. This results, amongst other things, on all of our @media queries being open-ended (they don’t set a max-width).
  Breakpoint helper classes always follow this principle and work by larger breakpoints overriding smaller ones.

• All separator borders are solid.
  Borders that indicate boundaries are always set to solid and are not configurable. This is because 1) we find solid borders to be the most “solid” choice and 2) exposing that level of detail on our config file would kill this projects’s purpose.
  If you need decorator borders to be set to other value, write them on your own css. If you don’t agree with this or don’t need separator borders, you can set $separators to false.

• Utility classes have their uses
  Utility classes are the subject of a heated debate. Some frameworks are based exclusively on utility classes. Some people say they’re unmaintanable, bloated and meaningless while others praise the quick prototyping and development you can achieve with them.

  Huesitos is our (optional and small) library of utility classes. We don’t favor design by using utility classes, we do embrace BEM and semantical naming but we have found that a small subset of utility classes on top of BEM is really useful on two cases:

  1. For overrides so small they won’t justify a modifier class (i.e: deleting/adding margins).
  2. For items so small they won’t justify a new set of BEM classes.

Javascript

Some nasty native HTML shortcomings (like the infamous <select>) need to be tamed. We use a little (and optional) JS for this.

Javascript libraries that are bundled follow this requirements:

• Zero overweight. Small, concise, single-purpose libraries
• Vanilla javascript. jQuery shouldn’t be a dependency.

Apart from custom solutions, Huesos make use of the following JS third-pary libraries:

• Selectr for vanilla-JS, Chosen-like <select> fields.