Huesos includes programatically generated classes generated by looping over maps that loop over maps that loop over maps.

This is a potentially dangerous weapon. Any lack of awareness, misuse or bad configuration can result on huge, bloated CSS files filled with tons of selectors that you will never use.

Ask these questions and act accordingly to avoid sending extra KBs to your end-users. You, your boss and your Lighthouse score will be grateful:

Can I skip some @imports?

When you add Huesos to your proyect you usually @importthe whole _huesos.scss file.

For a fine-tuning, you can also copy & paste _huesos.scss (you’ll need to adapt the paths to your structure) and get rid of the @imports you don’t need.

For example, it makes no sense to @import selectr if you’re not using JS enhancements. Or you might rid of the show-grid debug scss, or all the components if you only want Huesos as a global reset, etc…

Do I need all the button states?

By default, a $button-states map is populated with the following values:

$button-states : (
    primary: get-color(base, primary),
    secondary: get-color(base, secondary),
    success: get-color(state, success),
    warning: get-color(state, warning),
    error: get-color(state, error), 
);

This will generate helper classes for quick styling, like .button--warning.

We consider these five states to be common, but if you can get rid of any of them, do it. Your code will be smaller.

Do I have any unused button or link strategy?

$button-alternative-strategies and $link-alternative-strategies are powerful weapons.

They will generate utility classes for alternative stylings. This is a blessing when your site needs to have a great diversity of buttons and links.

For example, if you define a “split” button strategy and you have the five default button states (primary, secondary, error, warning, success), you will end up with the following classes:

• .button as the base.
• .button–primary, .button–secondary, .button–error, .button–warning and .button–success as modifiers for the default.
• .button–split–primary, .button–split–secondary, .button–split–error, .button–split–warning and .button–split–success as alternative styles.

Consider what might happen if you added 3/4 more states and 3/4 more alternative strategies. A jungle of CSS, an untameable beast.

If you don’t (which might be the common case) consider setting $button-alternative-strategies and/or $link-alternative-strategies to false.

Is my grid fine-tuned?

$max-grid-cols will generate classes for handling every possible number of columns on every defined breakpoint. That’s a lot of css. By default, is set to a sensible number of six.

Check how many columns will you need and update this variable accordingly.

You might want to roll out your own solution, or prescind of the grid. Set $max-grid-cols: false to avoid outputting any CSS.

Am I abusing background-contrast($include-typography: true) mixin?

Each time you invoke this sorcery with $include-typography: true, you get a bunch of overrides for headings, which means a bunch of CSS.

By default, $include-typography is set to false. It you don’t need to override your links and headings, be sure to use the default value!

Do I need Huesitos?

Huesitos is the utility part of Huesos.

Utility classes take care of tiny, single-purpose and abstract style tweaks. For example, .mb will set a margin-bottom of $gutter; while .left will align text to the left and .br will output a border on the right using the default color and width.

Utility classes are the subject of a heated debate. Some frameworks are based exclusively on utility classes. Some people say they’re unmaintanable and bloated. Others praise the quick prototyping and development achieved.

You might not want the utility classes at all. Set $huesitos:false to avoid it.

I want Huesitos but… ¿do i need all the color classes?

As a part of Huesitos, there are some color helpers that will apply background-contrast to every item on your $colors palette. As we said before, background-contrast is evil.

You will end up with a library of helper classes like .bg-state-warning that will check the text color against your background-color and apply any needed overrides. See the following example:

<section>
    <div class="grid grid--gutterless grid--small--2col grid--medium--3col">
        <div class="grid-item p bg-base-primary">base:primary</div>
        <div class="grid-item p bg-base-secondary" >base:secondary</div>
        <div class="grid-item p bg-base-separator" >base:separator</div>
        <div class="grid-item p bg-state-warning" >state:warning</div>
        <div class="grid-item p bg-text-mark" >text:mark</div>
    </div>
</section>

Consider that every class needs to include an override for links and headings inside of it. The outcome can become huge it your palette grows in size.

If you don’t plan on using this feature (or will use it so sparingly that it will kill its purpose), you can set $huesitos: true and $generate-color-classes: false to avoid generating all the palette’s background-color classes while keeping the rest of Huesitos up and running.