Hocus-Pocus: Building a Design-Free Sass Framework

Hocus-Pocus is a design-free Sass framework that I’m working on in my free time. The main idea behind Hocus-Pocus is to make a universal and lightweight stylesheet starter kit that focuses on the most common features. In this article, I’ll cover why I decided to build my own Sass framework and the approach I’ve taken when doing so.

Key Takeaways

• Hocus-Pocus is a design-free Sass framework that offers a lightweight, universal stylesheet starter kit, focusing on the most common features. It allows users to change the look of every single component with variables and enables the disabling of certain features or defining a range of helpers.
• The framework is easy to install with Bower and npm, requiring Sass and Autoprefixer to run. It follows a regular, dash style class naming convention and pays close attention to documentation and updates to the Hocus-Pocus changelog.
• Future plans for Hocus-Pocus include making it an ideal Sass starter kit for complex projects, focusing on project-specific UI components and theme definition. Major new features are not planned, but improvements to syntax and class names may be implemented.

Why Have I Started Working on a Sass Framework?

In short, I would say I’ve started working on a Sass framework because I wanted to save time when starting new web projects. I’ve noticed that even when I work on really custom designs, I always add the same set of tools, include the same standard packages, and implement a similar collection of basic CSS components.

The second question that follows then is — Why you don’t you use an existing, well-known and proven framework like Bootstrap?

My response to this comes down to preferences and my approach to CSS. I think libraries like Bootstrap or Foundation are great and have greatly changed how people think about CSS. However, in most cases within my own project work, I just don’t need all these features and UI components like progress bars or breadcrumbs. Instead, I prefer to have something more universal. I prefer something that I can use in any project, without needing to override framework CSS classes.

Due to the reasons above, in Hocus-Pocus you can change the look of every single component with variables. You can even disable some features or define a range of helpers. The downside of this approach is that I can’t provide a compiled CSS version of the framework as there is no reasonable way to use Hocus-Pocus without an ability to update variables.

Pre-requirements and principles

Installation

The framework is available and easy to install with two different package managers: Bower and npm. It requires Sass (minimum required version is 3.3.0) and Autoprefixer to run. Autoprefixer is used to add necessary vendor prefixes to the final compiled CSS file. I don’t worry too much about compatibility between various browsers nowadays as I personally find autoprefixing to be sufficient. Additionally, I use sass linter (scss-lint), but this is not required for running Hocus-Pocus and doing things the right way. Hocus-Pocus will work without it.

Naming Convention

The next principle is an important one for every framework — the naming convention. I prefer regular, dash style class names without BEM. I won’t complain if you are a fan of BEM and prefer to use the BEM naming convention, if it works for you — go for it. From my perspective, BEM doesn’t fix all of the responsibility problems in CSS. I also find that I approach my CSS using less class-level elements when I use BEM. Adding a new element to an existing block is just too easy.

Documentation

Last but not least, I pay close attention to writing documentation and keeping the Hocus-Pocus changelog up to date. Documentation doesn’t have to be perfect, especially at the beginning, but I always try to find time to improve it. This helps newcomers learn how the tool works and allows me to keep track of framework features.

Framework Features

The following framework features are the most characteristic to Hocus-Pocus in my opinion and give the best overview of what its focus really is.

Most of the framework classes are inspired from existing projects that I’ve worked on in the past. You may also spot some similarities to other CSS frameworks that have inspired me, especially my favorites — Primer and InuitCSS.

Framework features in Hocus-Pocus include:

1. Normalize with some enhancements like global box-sizing set to border-box or text elements without top margin.
2. A new default color palette based on clrs.cc.
3. A fluid grid based on flexbox with width helpers that use fractions as class names (.1/2, .1/3 and so on).
4. Wide support for responsive web design. There is an option to choose either “mobile first” or “desktop first” as your preferred approach. You are also able to define breakpoints for each and each of them gets their own set of helpers for spacing, grid, visibility, and an individual Sass mixin.

For example:

$<span>rwd-type: desktop-first;
</span>$<span>rwd-map: (
</span>  <span>'mobile': 680px
</span><span>); 
</span>$<span>spacing-map: (
</span>  <span>'double': double($spacing-unit)
</span><span>);</span>

Then in compiled CSS you’ll have access to classes like .mobile-1/2, .mobile-hidden and .mobile-padding-double.

1. Generic default styles for text elements with vertical rhythm based on Gridlover.
2. Extra modifiers for other HTML elements like an inline list, a menu list, a circle image or a zebra table.
3. Various button types and three versions of forms: inline, stacked and horizontal.
4. Essential UI components like the media object, box object, navbar, a hero element for landing pages and a sticky footer. Nothing more.

Future Hopes for Hocus-Pocus

My goal is to make Hocus-Pocus an ideal Sass starter kit no matter how complex your projects are. This way, you can focus on writing project specific UI components and defining your theme.

I don’t plan to implement any major new features. I think the features included are a reasonable amount of features and are likely to be the final ones. I’ll probably improve syntax for some components or change some single class names, but I don’t predict any compatibility breaking changes from the current version. For now, I’m more committed to fixing bugs that occur as more people give Hocus-Pocus a try.

If you think the Hocus-Pocus framework might be helpful for you in an upcoming project, you can find full documentation at hocus-pocus.io. The Hocus-Pocus code is open source and all available on GitHub. I appreciate any comments, feedback, and information about potential issues.

Frequently Asked Questions (FAQs) about Building a Design-Free Sass Framework

What is a Sass Framework and why is it important in web development?

A Sass (Syntactically Awesome Stylesheets) Framework is a pre-prepared library that is meant to be used as a base to start a project. It’s important in web development because it helps to speed up the process of creating style sheets for websites. It allows developers to use variables, nested rules, mixins, and functions, all of which can be very useful in maintaining CSS.

How does a design-free Sass framework differ from a regular Sass framework?

A design-free Sass framework is different from a regular Sass framework in that it doesn’t impose any design decisions on the user. It provides a clean slate for developers to build upon, allowing them to implement their own design choices without having to override any pre-existing styles.

What are the benefits of using a design-free Sass framework?

Using a design-free Sass framework offers several benefits. It allows developers to maintain a clean and organized codebase, making it easier to manage and update. It also provides a solid foundation to build upon, saving time and effort in the initial stages of development.

How can I start building a design-free Sass framework?

Building a design-free Sass framework involves several steps. First, you need to set up your project structure. Then, you can start creating your variables, mixins, and functions. After that, you can start building your base styles and layout modules. Finally, you can compile your Sass into CSS.

What tools do I need to build a design-free Sass framework?

To build a design-free Sass framework, you’ll need a text editor, a Sass compiler, and a web browser for testing. You may also find it helpful to use a task runner like Gulp or Grunt to automate your workflow.

Can I use a design-free Sass framework for any type of project?

Yes, a design-free Sass framework can be used for any type of project. It’s particularly useful for large projects where maintaining a clean and organized codebase is crucial.

How can I customize a design-free Sass framework to suit my needs?

You can customize a design-free Sass framework by modifying the variables, mixins, and functions to suit your needs. You can also add your own styles and layout modules.

What are some best practices when working with a design-free Sass framework?

Some best practices when working with a design-free Sass framework include keeping your code DRY (Don’t Repeat Yourself), using meaningful names for your variables and mixins, and organizing your code in a logical and consistent manner.

Can I use a design-free Sass framework with other CSS frameworks?

Yes, you can use a design-free Sass framework with other CSS frameworks. However, you may need to override some of the default styles of the other framework to ensure that your design choices are not overridden.

Where can I find more resources on building a design-free Sass framework?

There are many online resources available for learning more about building a design-free Sass framework. Some good places to start include the official Sass documentation, online tutorials, and web development forums.

The above is the detailed content of Hocus-Pocus: Building a Design-Free Sass Framework. For more information, please follow other related articles on the PHP Chinese website!