Below is an email I sent to someone discussing what to do with the future of the CivicSpace Theme. Feel free to comment and add ideas.

In addition to #drupal-themes I also have a channel for the development and building of the CivicSpace Theme.

I feel a lot of these ideas could actually serve ultimately to make for a base Theme all developers start building "Layouts" and "Skins" from.

...

I wanted to layout the different tasks that are ahead of us on this CSTheme revamp.

Objective: Rebuild the CivicSpace Theme so it is a solid base for building other themes on top of.

Background: So, to make sure we are on the same page, currently the way we have things setup is this.

- current setup - Base CivicSpace Theme - visual.css, layout.css, others...

Layout - layout.css(OVERRIDES MAIN layout.css) + Pulls main CSTheme styling in

Skin - custom.css(OVERRIDES MAIN visual.css) + pull Layout stuff.

- proposed setup - Base CivicSpace Theme - no visual.css or layout.css

Layout - layout.css (Setups up the way this layout is presented) * dictate CLASS SOURCE ORDERING??? [see below]

Skin - custom.css (pulls in Layout from it's Parent Layout)

Tasks: 1. Class ordering I think it would be important if there were some way a Themer could do source ordering or structuring of classes in page.tpl.php I have NO idea how this would work, but. Example:

HTML: <div id="header"><h1>header</h1></div> <div id="menu"><h1>menu</h1></div> <div id="content"><h1>content</h1></div> <div id="sub-section"><h1>sub-section</h1></div> <div id="footer"><h1>footer</h1></div>

Let's say a themer wanted to shuffle these around so they could achieve a different layout. It would be nice if there was some way we could accomodate these changes. Depending on floats and what-not, people might want these id's to show up in different places. How can we accomodate these different positions?

You do understand we'll have layouts in the "layouts/" directory. Is there a way we could pre-configure all the different combinations of our CSS major classes: example:

1 - header, menu, content, sub-section, footer 2 - menu, header, content, sub-section, footer 3 -

This doesn't work either, as that could easily lead to well over 125 combo's alone. :/ There needs to be a way where people could, in perhaps their style.css of thier Layout file put something like:

#HEADER,#MENU,#CONTENT,#SUBSECTION,#FOOTER (proper names of course, these are just examples)

And then it orders the areas according to what is found in that file? Does that make sense? So your Layout file has something like:

/* CIVICSPACETHEME ORDERING */ /* #CONTENT,#MENU,#HEADER,#SUBSECTION,#FOOTER */

/* * =Republica Layout */

body { foo }

Does that make sense? And by default, if there wasn't any SOURCE ORDERING stuff present, then it would use the default method.

This makes total sense to me, but then again... heh, what do I know?[tm]

This also seems like it could be the proper setup for a Wizard to allow people to change areas. Not that we are even talking Wizard stuff now.

...

2. Default Skin Selection Currently, to my knowledge, and the guy who was working on CivicSpace Theme before me (Chris Messina), there is no way to "call" the skin you want to be the default skin, in a way that Drupal will understand.

We need to get visual.css out of the base CSTheme directory, and put it in an actual Skin. As well as any other CSS that may get called in the default BASE setup. All of these need to be on a per-Skin basis.

...

3. custom.tpl.php This might be a future feature, but if it's easy to add, I don't see why we don't add it now.

The Problem If people want to add custom php to their theme, a lot of time they hack up the page.tpl.php file. When they do this, they break from the default CivicSpace Theme distro and make themeselves Non-upgradeable. If there was a call to say a custom.tpl.php file, that we did NOT ship, but simply refered to, then they could put all of their custom php inside this file and not have to worry about it upon upgrading.

...

4. Javascript calls [on/off] I think we should probably have a javascript.tpl.php that ships with the CSTheme. What we do is, we take all of the javascript crap out of page.tpl.php, and include a toggle switch or config or something that makes it easy for people to enable or disable the javascript stuff in the theme. I personally completely dislike any javascript to load in my themes. I want clean, fast and clear of junk.

...

In conclusion, I think these fixes should probably be easy to do. But then again, I don't know how to code do I? ;) Jeremy, please hop on #cstheme if you can from time to time so we can work on some of these issues.

Thanks bunches. Trae

PS. I think this would be a good email to send to CS-Dev and the Drupal Themes mailing list. What about you guys?