I have always liked the fact that previous Zen versions had separate stylesheets fot layout, html elements, custom styles etc. More separation can also be useful, but downloading the latest D7 version was quite a shock to me. When the css directory of a fresh subtheme contiains 28 css files, I'm not sure where to start anymore. I'm wondering if this still efficient for my own and other people's workflow.

When I work with a team on a Drupal site, we need to know where we can expect certain css declarations. I'm afraid that too many stylesheets can cause confusion. Different developers can have different opinions about the right place for a certain declaration, or declarations that belong together will end up in different stylesheets.

I also think it's confusing that there is a large number of stylesheets, but only a part of it is enabled by default. New users may not immediately understand why editing a certain stylesheet has no effect. It may be more consistent to add only the enabled stylesheets to the starterkit css directory, and put the optional ones elsewhere. After all the templates directory isn't packed with example tpl's by default.

This is only my €0.02, based on a first impression. Maybe I will learn to appreciate it over time... I'm curious to hear your thoughts and experiences.

#14 smacss+sass.png18.09 KBJohnAlbin
Members fund testing for the Drupal project. Drupal Association Learn more


Jeremy Toaster’s picture

I'm just beginning to use the Zen them for a few sites, but years ago when I started learning CSS, the whole concept behind it was simplicity and organization. Instead of embedding all your style sheets into every single HTML page, you have 2 or 3 external sheets that are called in.
I've been seeing a trend in Drupal of there being way too many style sheets as well as in phpBB and other CMS / forums. What ends up happening is each module or plugin ends up having it's own style sheet and conflicts start amassing and piling up. One sheet overrides another or un-does some other sheet. You end up spending hours digging through style sheets trying to find that one single font size tag that keeps changing things on you!

They've made something that was supposed to streamline and speed up web site production and have come full circle to complicating and making cumbersome again...

akalata’s picture

Status: Active » Closed (duplicate)

Let's consolidate this discussion at http://groups.drupal.org/node/94329

JohnAlbin’s picture

Version: 7.x-3.x-dev » 7.x-5.x-dev
Category: support » task
Status: Closed (duplicate) » Active

Let's re-open this issue, shall we? I never actually saw this or http://groups.drupal.org/node/94329

marcvangend’s picture

Yes please!

There are already some good points and interesting thoughts in the g.d.o thread. I guess it comes down to this:
Having many stylesheets instead of one can help to keep your css clean and organized. However, it can only be used effectively if:
- it's crystal clear (to everyone working on the project) which css rules belong in which files;
- the initial number of stylesheets (when initializing a starterkit subtheme) isn't overwhelming;
- you know how to turn on CSS aggregation.
Even though the readme file in zen/STARTERKIT/css is excellent, those preconditions are not always met. Some people choose to add another stylesheet for their own code and leave the Zen stylesheets (mostly) untouched. This works fine but it defeats the purpose of having multiple stylesheets.

Zach Harkey’s picture

I've been giving this a lot of careful thought and sitting on a draft of this post for too long (I get all pumped up and hammer out my thoughts, only to realize my tone is too aggressive and I get worried that I might come off as crapping on other people's hard work — I hope not.) but here goes nothing:


Zen gets a bad rap for being bloated and it shouldn't.

If it weren't for the mammoth collection of 28 CSS files, Zen would be a lean, mean, theme building machine.

28 default stylesheet files isn't really practical or helpful to anyone. The advanced themers resent the bloat and enforced structure, and the beginners are getting confused and overwhelmed by them.

And for what gain? At the end of the day they don't really even provide any style. If Zen were trying to provide a baseline visual framework that could be used right out of the box (like twitter bootstrap), it would make sense to impose such such a massive CSS file system, but it's not.

I'm lucky to use 10% of the selectors in these stylesheets, and I bet most of you guys do too — be honest.

Even if I used 3x this many selectors, I personally would never use this many separate documents to manage them. Am I the edge case here? Does the typical Zen web designer/themer really prefer to have their design spread across 20+ separate files?

Don't answer that because it's a moot point...

Because even if I did want to manage this many separate files, I'd be better off collecting them into a library of SASS _partial.scss files and @import-ing them (along with all my variables and mixins) into a single compiled stylesheet for the theme registry.

@importing them as SASS _partials let's me split them into as many files as I care to manage — and I can experiment with adding, removing, reordering, regrouping, reformatting them as often I see fit without ever having to flush the theme registry. And don't end up producing 20+ additional physical files full of empty css rules and comments only to have them aggregated by Drupal later on (if I remember to turn on css aggregation).

Zen should produce one default css file containing layout and just enough selectors and comments to be useful.

I personally use something like this:

styles.css (compiled)

_base.scss (@imports all global _partials)
styles.scss (@imports _base and contains my design styles.)

If a themer wants to add 28 more _partials, or even 28 more css files, they can, and they can organize them in whichever way works best for them and their organization.

I also feel like this is cleaner than having to @import 'base' at the top of dozens of stylesheets because I can toggle _partials on and off from a single master index. That, and it generates one compiled styles.css file.

But let's call the existing 20+ stylesheets what they are: an insanely comprehensive reference of every possible Drupal CSS selector known to man. And let's move them to the Zen documentation on drupal.org and replace them with a URL in a comment:

 /* A comprehensive reference of common Drupal CSS selectors 
  * can be found at: http://drupal.org/node/xxx
  * (Pssst: just use Firebug.)


This would benefit advanced themers and beginners alike by not getting in their way or scaring them off, and Zen would truly live up to its name.

JohnAlbin’s picture

Priority: Normal » Critical

Been working on a project at Palantir where our current organization method completely fell apart. When pages are a giant mix of panels, views, and fields, how do you get 3 developers to put the styles in the same places?

I'm going to let comment #5 sink in before I respond. Leveraging Sass to improve our stylesheet organization is a must.

KrisBulman’s picture

I use a similar method to #5 in Aether, here is the stylesheet breakdown which may be of some interest.


-Mania-’s picture

I loved when there was only a few stylesheets but haven't been a big fan of Zen ever since the decision to separate them into tiny chunks. Not to mention many of these stylesheets are completely empty! I'd be interested in a lighter Zen-spinoff if there's one available. :)

echoz’s picture

I have always deleted the empty selectors and don’t see how they are useful, since I discover them from the other direction, using dev tools to find what I want to effect (like the “(Pssst: just use Firebug)” comment in #5). If anyone feels they are helpful, I like Zach’s suggestion in #5 to move them to documentation.

I do develop with a few separate stylesheets; for layout, normalize, pages, menus, forms, and put most of zen’s extra stuff in pages.

marcvangend’s picture

Thanks everyone for your input. This made me think about how I use Zen stylesheets. The way I and my colleagues work, I see 3 types of stylesheets:

  1. Set-and-forget
    The kind of CSS file I edit at the beginning of a project and serves as a base for the rest of my CSS. In Zen, this is normalize.css and the layout stylesheet. The pages.css file contains some useful defaults too.
  2. Use-it-or-not
    The default stylesheets I either use or not, depending on the design. For example tabs.css: sometimes it's useful, sometimes it just gets in the way. Usually these are not edited.
  3. Custom styling
    The stylesheet that contains most of the site-specific styling. Instead of using multiple files for customizations like fields.css (which causes problems like John described in #6) we tend to have a single [themename].css. This is also the simplest way to get rid of all empty selectors. Occasionally we use 2 or 3 of these stylesheets, but only when the site has clearly separated sections (like a webshop) so there can be no doubt about what belongs where.

The 3rd point is where themers spend most of their time, and it's usually where you need to be when you have to make changes later on. I don't see a need for default stylesheets there.

JohnAlbin’s picture

I've been studying the SMACSS approach to see if there is a wheel we can refrain from reinventing. http://smacss.com

JohnAlbin’s picture

But let's call the existing 20+ stylesheets what they are: an insanely comprehensive reference of every possible Drupal CSS selector known to man. And let's move them to the Zen documentation on drupal.org and replace them with a URL in a comment:

I like this idea very much.

Zach Harkey’s picture

The same idea could be applied to the tpl files.

All that documentation is extremely useful, but it's too much text for a tpl file. In most cases the comments are way longer than the code. I feel like I'm constantly deleting them just so I can see my code without having to page down. Once I delete them I feel like I can breathe, and ironically my template file feels easier to understand. But I never feel good about deleting documentation, or having to dig up a pristine copy of e.g., page.tpl.php just to see a list of variables.

The placement of lengthy documentation inside the tpl file contributes to Zen's reputation for being bloated. It is common to see people brag about their solution using "less code than zen’s opening page.tpl.php comment".

It isn't fair to penalize Zen for having good documentation, but the location of the documentation does cause unnecessary friction in my daily workflow. Good documentation shouldn't be a penalizing factor. Especially when, as before, we can have our cake and eat it too. Just move all the non-critical documentation to the drupal.org and replace it with a URL.

An extreme example of cutting every non-essential line in page.tpl.php:

 * Complete documentation for this file is available online:
 * @see http://drupal.org/node/193318

(Where the URL would link directly to the page documenting that specific template.)

I realize this suggestion exceeds the scope of the original topic of stylesheets, but the idea is the same: Improve the experience for the themer by reducing unnecessary bloat and reducing friction wherever possible without sacrificing any valuable documentation.

JohnAlbin’s picture

18.09 KB

I just created a CSS selector doc page. :-) http://drupal.org/node/1707736

I'm working on some reorganization in the 998526-stylesheet-reorganization branch. Here's a diagram of the proposed organization. Please provide feedback!

JohnAlbin’s picture

Here's a comparison of what I'm proposing:

SMACSS category organization in Zen 7.x-5.1 (and earlier) proposed organization
Base normalize.css normalize.css
Layout layouts/responsive-sidebars.css layouts/responsive-sidebars.css
Modules wireframes.css
/* Add your own modular files here. */
States none included by default none included by default
Theme none included by default none included by default
Total # of files: 13 (+ 6 RTL) 5 (+ 4 RTL)

One of the 5 files is a not listed in the new organization; it is a new styles.css/styles.scss which has no styles of its own and @import's all the files listed in the table above. This allows Sass’ @extend to work across separate files as the extended styles are created properly in the generated styles.css. If not using Sass, Drupal’s CSS aggregator will still work properly as it inline-replaces the content of an @import'ed file inline into the aggregated stylesheet.

* The modular-styles.css file is a concatenation of the old files, but with the empty selectors removed.

JohnAlbin’s picture

Component: Miscellaneous » CSS/SASS/HTML markup
Status: Active » Fixed

I just created #1711768: Move tpl documentation to doc pages

And pushed the work I did for this issue. Thanks, everyone! :-D

JohnAlbin’s picture

Title: So many stylesheets - is this still efficient? » Simplify stylesheet organization using SMACSS categories
rupl’s picture

I haven't looked at the new code but a huge +1 for this!

I've put Zen 7.x-5.x to work for two major sites, and both times I essentially zeroed it out to the proposed solution within #15 in favor of Sass partial concatenation. I thought the old files were quite interesting in that you see every possible selector. But this is definitely more Zen-like :)

-Mania-’s picture

This is great, nice work JohnAlbin!

-Mania-’s picture

Heads up: I couldn't get the css aggregation (in Drupal performance settings) working properly with the new files. Well, aggregation worked but it didn't pick the styles up. I think it's the @import commands in styles.css. At the moment I fixed it by including all of the @import files listed in styles.css in the theme.info file.

Status: Fixed » Closed (fixed)

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

caschbre’s picture

I'm currently using Zen 7.x-5.1 but would like to move my scss/css files to this structure. How would I go about making those changes manually? Is it simply changing the files as noted in #14/#15 or are there other files (i.e. tpl.php) affected?

If someone was to upgrade to 7.x-5.2 (when it comes out), how does the upgrade path look?