SMACSS has categorization rules for CSS that start with the "base" rules that contain styling for base HTML elements. http://smacss.com/book/type-base

Compass' best practices ( http://compass-style.org/help/tutorials/best_practices/ ), a relatively obscure documentation page actually, recommends using a _base.scss partial to define your variables and import your Compass extensions.

Its extremely confusing in the existing styles.scss to do:

@import "base"; /* compass base, not SMACSS base */
@import "normalize"; /* SMACSS Base rules */

Given that the Compass recommended practice is much less widely known then the SMACSS category, I think we should rename the _base.scss partial.

But what to?

_config.scss, _configuration.scss, _settings.scss, _setup.scss? Any other better suggestions?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

JohnAlbin’s picture

Title: base partial does not contain SMACSS base styles » _base partial does not contain SMACSS base styles

I posed this question to the Compass users' group: https://groups.google.com/forum/?fromgroups=#!topic/compass-users/TRlhkUZ1Q3E

I'm now leaning towards _init.scss.

But let's see what response we get from that list. :-)

dropfen’s picture

Why not change the SMACSS category "_base" to "_global" ?

Lukas von Blarer’s picture

This is what just confused me... The _normalize.scss is a reset stylesheet, not for base styles.

A sample file structure form the SMACSS book:

+-layout/
| +-grid.scss
| +-alternate.scss
+-module/
| +-callout.scss
| +-bookmarks.scss
| +-btn.scss
| +-btn-compose.scss
+-base.scss
+-states.scss
+-site-settings.scss
+-mixins.scss

We should have something like this:

_settings.scss
_mixins.scss
_normalize.scss
_base.scss
_layout.scss
_modules.scss
_states.scss
_print.scss
styles.scss

What do you think?

Should we introduce folders? Maybe a folder for layouts, modules and themes? I remember that once there was one for layouts... Why was it removed?

caschbre’s picture

I think using folders would be great. I've had a few projects where I wanted to break up the scss files into smaller includes.

Lukas von Blarer’s picture

What do you think of the my file setup? Specifically these ones:

_settings.scss
_mixins.scss
_normalize.scss
_base.scss

caschbre’s picture

Looks like _mixins and _settings are the only new files? What would typically go into the settings file?

Lukas von Blarer’s picture

I would split up the current _base.scss file into these two. _settings.scss containing all global settings and _mixins.scss all custom mixins.

As a replacement we could then use _base.scss as the base as it is referenced in SMACSS. To define global styles.

caschbre’s picture

Ah, that makes sense. I like it.

Lukas von Blarer’s picture

Great. I just started creating a Zen subtheme using this approach and it feels good :)

@JohnAlbin do you agree?

mobweb’s picture

Patch according to the changes proposed in #7.

mobweb’s picture

Ignore the previous patch, forgot to include the changes made to styles.scss, sorry.

JohnAlbin’s picture

Status: Active » Fixed

I've renamed _base.scss to _init.scss.

And I've re-added the layouts folder. And included a new components folder. This is a directory structure I've been playing with and mirrors what I've seen others do.

http://drupalcode.org/project/zen.git/commitdiff/504b743

Lukas von Blarer’s picture

Status: Fixed » Active

Ok... It would be nice to have a file structure that is intuitive and works for different sizes of projects. And therefore have one structure across all zen subthemes.

The _base.scss is missing now.

Why did you remove the _global_states.scss? (I don't use it though.)

Why did you use the term components? Why not use the same terminology as in SMACSS?

JohnAlbin’s picture

The _base.scss is missing now.

As I said in comment #1, I've renamed it to _init.scss.

Why did you remove the _global_states.scss? (I don't use it though.)

It wasn't useful. State changes of components should be placed next to the component. Putting the state styling in a separate file was a mistake on my part when I first implemented SMACSS organization in Zen.

Why not use the same terminology as in SMACSS?

We're using components in Drupal 8 because SMACSS uses "modules", which… is mega-confusing for Drupal users.

echoz’s picture

Status: Active » Fixed
Lukas von Blarer’s picture

As I said in comment #1, I've renamed it to _init.scss.

But the _base.scss is supposed to be the place to define global styles. This is why we renamed it to _init.scss initially, right?

It wasn't useful. State changes of components should be placed next to the component. Putting the state styling in a separate file was a mistake on my part when I first implemented SMACSS organization in Zen.

Agreed.

We're using components in Drupal 8 because SMACSS uses "modules", which… is mega-confusing for Drupal users.

Ok. Makes sense as well.

Lukas von Blarer’s picture

BTW... I really like to have a separate file for settings and one for mixins. I don't see the reason for them to be in the same file.

dropfen’s picture

1+ It makes sense to separate this files.
configs are not mixins. Configs are something you want modify once, by creating your project.

JohnAlbin’s picture

Title: _base partial does not contain SMACSS base styles » Rename _base partial to _init since it does not contain SMACSS base styles

But the _base.scss is supposed to be the place to define global styles. This is why we renamed it to _init.scss initially, right?

No, we renamed it because it doesn't contain our base styles. The normalize.scss file contains the base styles.

BTW... I really like to have a separate file for settings and one for mixins. I don't see the reason for them to be in the same file.

Yeah, I'm not too crazy about them being in the same file too. Let's move that discussion to #2038527: Move custom mixins out of _init.scss

Lukas von Blarer’s picture

Ok. I thought that _normalize.scss was supposed to be untouched and all resets should be made in a separate file instead (this is what i prefer since mixing CSS code of a reset stylesheet and very project specific global styles might be confusing). But in that case everything is clear now.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.