SSNULL

The HAL system of helpers, appearance and layout came as an idea based on SMACSS. It came out of the need to develop front end designs quickly without needing to continually add new styles to an ever growing stylesheet.

There are three pieces to this system:

• Leverage the use of helper classes on elements for styling.
• Seperate the appearance of an element from its layout.
• Easily memorizable and repeatable code for front end developers.

A System for Front End Developers

This part isn't in the HAL acronym, but making your CSS framework easy to work with is the most important takeaway of the system.

HAL keeps us out of our stylesheets. The only reason we edit those stylesheets is to either add additional helpers, or tweak existing styles. Because of this, HAL really demands the usage of HTML Components, like what you would see in frameworks like Vue and Svelte.

HAL still has global stylesheets, and I suggest organizing these stylesheets under SMACSS guidelines.

Design elements that need a specific class or HTML structure must be a component.

HAL deviates from SMACSS in that is does not like modules of CSS in stylesheets. In the HAL system we want to avoid needing to memorize abstract, arbitrary or semantic class names. You should never need to remember that `<input type="button">` needs to have a class combination of `btn btn-small btn-primary`.

By using components we can remove the human error element from styling. It's frightently easy even for front end developers to forget a particular class already exists and create duplicate a selector as a result. It also reduces the amount of styling other developers have to contend with, a common complaint I hear from backend developers isn't working with HTML, it's having to work with CSS and CSS class names. This brings me to the next point...

HAL is meant to be easy to understand for front end developers

I initially tried to create a CSS architecture that would be backend developer friendly. What I ended up creating was a system that was easy for front end developers to understand.

Helper classes are a big part of HAL for rapidly laying out elements and overriding base styles. All of the helper classes have names based on their CSS instructions:

undefined

I actually found a lot of similarities to the helper classes I was creating for HAL to what Bootstrap was already doing. The similarities were close enough that I began to rewrite helper classes to conform with Bootstrap's naming. Since HAL is philosophy, it's also possible to plug Bootstrap into a project and use that as a helper library. Bootstrap has it's pros and cons that I won't get into, but HAL functions great with it.

Keep appearance seperate from layout.

This is a fairly simple rule at heart. The idea is to keep styles that dictate what elements look like seperate from how elements are arranged. When we do this, it's easier to rearrange elements without changing their appearance, and vice versa. It also helps us decide where best to put styles.

The simplest application of this is for the main layout of a given application, your header, footer, sidebars and content box. Suppose you have the following design:

undefined

undefined

It can be quite tempting to blend our background styles right into our layout styles:

undefined

For our simple use case is this entirely innocuous, but we run into problems in larger applications where we have the following factors to deal with:

• Logic integrated with front end code, such as conditionals, loops and variables.
• Large components with hundreds of lines of code.
• Elements within elements.

As an application grows and design changes are made, this tends to lead to technical debt, excessive CSS overrides and broken layouts.

Components make it real easy to seperate appearance from layout, using Svelte as the example here:

undefined

undefined

undefined

undefined

There are a few other methods that can be done to keep appearance styles seperate from layout styles, but components don't come with hidden drawbacks like the following methods have:

• Using seperate selectors.
• Using seperate classes.
• Applying styles in seperate code blocks.

Using Helpers Effectively

This is the last section in HAL because on their own, helper classes look like a terrible mess of an idea.

Let's first build something like the following element a few different ways. This way we can see the extreme bell end of helper classes:

The CSS Only example is going to look really nice here:

undefined

undefined

Using only helper classes we don't need any CSS, though we do end up with excessively long class attributes:

undefined

We can see why Bootstrap decided to abbreviate class names like margin, padding and background resulting in a more convincing and concise look for helpers only. This is also why we still have global stylesheets that establish base styles for elements like label and input:

undefined

HAL does not dictate which of the two methods above to use, or to which extent both methods can be blended together. HAL only requires of the CSS only example that all custom CSS is confined to a immediate and relavent component.

The big no-no with HAL is to create CSS class modules in our global stylesheets:

undefined

Where helpers really shine is when you have a concise grouping of elements, take the following design:

We can get away with just two helper classes:

undefined

Which I find to be much easier and faster than writing up one off classes in a style tag at the bottom of a component:

undefined

undefined

This last example is important, because we will find these micro-styling situations everywhere within a web application. The CSS Only example is fine until you start to find yourself repeatadly having to invent a new class name for another element that contains some combination of display: flex; justify-content: around;. Helper classes not only keep our stylesheets neat and tidy, they also help keep the style tags in our components free from repeat instructions that can cloud out our more complex styles (like transitions and animations).