• Blog >
  • The evolution of separating substance from style in your sass

magento-evolution.jpg

This post details how my front-end methodology for theming Magento builds has evolved as my knowledge of the platform and front-end in general have become more comprehensive over the years.

I progress from the conventional style.css approach to modular SASS combining approaches from popular CSS methodologies to consistently evaluate and optimise my build process.

How it began

When working on a large project styles can quickly become cluttered, unorganised and messy. Every developer has worked on any number of small projects that spiral out of control and become much bigger than intended. You start with one file called styles.scss and before you know it you have an unorganised mess 2000+ lines long. Fast forward 2 weeks when you go back to your project to make a small tweak and you can’t find easily what you need to change because you’ve produced something so unmaintainable.

Now try taking that approach with a Magento build and as you can imagine it leads to a website that has redundant, repeated and often inefficient styles.

Onboarding a new developer on the project becomes infeasible. What's worse, as the team grows you increase the risk of merge conflicts within your version control system. Its barely a feasible proposition for one developer but when you have a team of people working on a single project it just won’t work. Untidy code aside you’ll more than likely end up with git conflicts everywhere.

When I was learning & getting to grips with Magento my approach was a cautious one. I’d take the demo theme and copy it into my new theme. I’d then restructure and re-style based on the existing files. I was able to identify how Magento styles tend to be separated into different files and what the modules are related to which file. Once I had grasped this however, the approach became effort as I found the demo theme a struggle to work with and hard to quickly make changes.

Magento Improves. Or does it?

Not too long ago Magento released a new demo theme called Madison Island. This theme for the first time utilised SASS and as a result mustered a lot of attention and excitement in the Magento community. Developers hoped the new theme would provide a better, modern starting point for Magento theming and save us countless hours of development.

Unfortunately the theme was developed as a commercial exercise to better demonstrate the potential of Magento and convert potential customers rather than an improvement to development practices. Trying to use this theme as a starting point comes with a whole new set of problems caused by specificity & unneeded style variables like colours & fonts scattered throughout the files.

Embracing CSS Methodologies

I wanted to get away from working with the default theme as quickly as possible & create my own Magento theme that I would use as a starting point for all of my projects. After reading online I realised that a great approach would be to adopt a CSS methodology such as SMACSS or BEM. The idea is that your styles are split into smaller, maintainable modules that are independent of other modules on the site. With this approach you could take these styles & place them in another build (built with a similar CSS methodology) & the module would look the same.

Luckily, around the time I started working for CTI Digital who had their own base theme already. It was built upon their own interpretation of several CSS methodologies which when combined made theming Magento much quicker and much easier. The theme separates Magento components into relevant files shown in the following structure:

CTI-theme
    - js
    - images
    - sass
        - theme.scss
        - modules
            - _cart.scss
            - _account.scss
            - _checkout.scss

Then within each file we contain all the code for a module within a single closure to like below:

.menu {
    background: #000;
    border: 1px solid #
    color: #fff;
    height: 100px;
    width: 500px;
}

We will nest the state styles within the module below its default styles. This clearly separates the default module styles from the state styles whilst clearly defining the relationship between the two. We then name our classes relevantly with naming conventions inspired by BEM to make things even clearer. For example we would add the state styles for an open menu or alternative menu styles like below:

.menu {
    border: 1px solid #000;
    color: #fff;
    width: 220px;
    &.menu--is-open {
    background: #fff;
    color: #000;
}
    &.menu--dark {
        background: #000;
        border-color: #fff;
    }
}

This is the current approach that our Magento projects take and has been for a long time. It hasn’t been improved for so long because in all honesty it works pretty well; we’re able to quickly identify where the code for a feature will be along with all of its states & theming as they are located within one clearly defined module.

The next step

Lately, I’ve been evaluating this approach because I feel that it can improved even further. The nature of Magento means that many projects have a basic structure for several large areas of the site such as the category, product and account pages for example. If we could separate the structure from our styles then we can save time on re-building these sections of the site & spend more time polishing it with better features and a cleaner user experience.

Going back to basics and reading up on CSS methodologies (SMACSS & BEM in particular) I noticed that SMACSS is extremely well suited to Magento because of its further separation of substance from style. SMACSS separates structure, theme & state even further than we have here in the past.

I will be investigating this on my next Magento project and will apply the following, stricter SMACSS methodology to my SASS structure:

CTI-theme
    - js
    - images
    - sass
        - theme.scss
        - modules
            - cart
                - _state.scss
                - _structure.scss
                - _theme.scss

Each module will be split into three separate files; each file will only contain styles relevant to either the structure, theme or state. Separating the styles into these categories for each module files will help with future projects because it is better suited to adaptation. For example, if my next (or any in the future) Magento build happens to have the exact same structure and states to a previous build then I will only need to edit the theme.scss file to match the new designs. I’ll waste no time re-creating a structure that has already been built before or searching through a file deciding which styles are needed and those that are surplus to requirements.

By evaluating a trusted approach to our theme development and comparing it to the CSS methodologies available we may be able to further optimise our build process allowing us to spend more time on the features that differentiate a good site from a great site. We’re constantly looking to improve both the efficiency and quality of our Magento projects.

Keep your eyes peeled for more guides from our expert Magento team!

● ● ●