[themes] CSTheme - What to do, How to proceed?

[Trae McCombs]

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?


-- 
Trae "occy" McCombs || http://occy.net/
       Founder - Themes.org // Linux.com
     CivicSpaceLabs - http://civicspacelabs.org/