HomeMobile Website DesignSASS Partials and The Problems Surrounding Them

SASS Partials and The Problems Surrounding Them

When doing front end work on a project that you are new to, there is often the question of what theme is being used and back in the old day, how is the CSS set up.

Now with SASS we are in a whole new world of organization and structure that can tend to be the Wild West of structure, some partials end up being ghost towns of bastardized SCSS while others end up being a metropolis of confusion.

The problem is: no CMS or theme has a definite rule about how to structure the SCSS partials. Omega has partials that lend to break point specific SASS. Zen has a purposeful, complete seven partials that aggregate into a single sheet, but often the design falls into one sheet that becomes too large. Aurora, (my theme of choice at the moment), has two different structures, both of which have their advantages and disadvantages. All of these themes share the same underlying problem, where Drupal has a defined structure about where code is to go and how it is to function, the themes are not under the same structural scrutiny with Partials.

This problem however is a good thing. Trying to fit a theme into a structure is similar to putting a designer in a box, there will be too many things that don’t conform to the structure and the theme will become unruly as the project grows beyond the initial scope.

I am not going to propose a logical system to the partial layouts because the truth is that the structure needs to be defined by the project at hand. It not only needs to be defined by the project at hand, it needs to be constantly redefined by the project at hand.

Here is a small proposal:

1) Read and write README.md for each theme.

2) Don’t strongarm, use finesse and swiftness.

3) Question: What makes sense to the new mind and will they do step 1 and 2?