CSTheme - What to do, How to proceed?
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/
On 04/12/05, Trae McCombs <occy@occy.net> wrote:
1. Class ordering I'm looking at the same thing right now for my own flexible theme. Here's some opinions other than my own on the topic: http://meyerweb.com/eric/thoughts/2004/06/26/structural-naming/ http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html http://www.digital-web.com/articles/architecting_css/
3. custom.tpl.php This is certainly something that would be beneficial. Usually it is just minor tweaks, but I've not thought of any way to achieve this without abstracting the theme functions slightly. The main reason I need this is to reorder the elements in a node - such as moving taxonomy terms to below the content.
-- David Carrington
Op maandag 05 december 2005 00:36, schreef David Carrington:
3. custom.tpl.php
This is certainly something that would be beneficial. Usually it is just minor tweaks, but I've not thought of any way to achieve this without abstracting the theme functions slightly. The main reason I need this is to reorder the elements in a node - such as moving taxonomy terms to below the content.
Does template.php not suffice? I always use that, mostly because I want to keep /any/ logic out of any tpl.php file. Bèr
On 05/12/05, Bèr Kessels <ber@webschuur.com> wrote:
3. custom.tpl.php Does template.php not suffice? I always use that, mostly because I want to keep /any/ logic out of any tpl.php file.
Since I base all my designs off one single theme, I am talking about changes only present in sub-themes. I'll be implementing this later on today (with a .theme). I'll give PHPTemplate some thought, but it's not on my priority list. -- David Carrington
Hmmm, Maybe we should move the stuff we have in template.php to something else. I know nothing about PHP per se, so... I'd probably be the wrong person to make this suggestion. I'll check with some other people. Thanks Ber, Trae Bèr Kessels wrote:
Op maandag 05 december 2005 00:36, schreef David Carrington:
3. custom.tpl.php
This is certainly something that would be beneficial. Usually it is just minor tweaks, but I've not thought of any way to achieve this without abstracting the theme functions slightly. The main reason I need this is to reorder the elements in a node - such as moving taxonomy terms to below the content.
Does template.php not suffice? I always use that, mostly because I want to keep /any/ logic out of any tpl.php file.
Bèr _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
I don't see how that would help. Unless CS Theme will have it's own engine-type system and break free of PHPTemplate, which would probably add even more complexity to the code. Robin On 12/5/05, Trae McCombs <occy@occy.net> wrote:
Hmmm,
Maybe we should move the stuff we have in template.php to something else. I know nothing about PHP per se, so... I'd probably be the wrong person to make this suggestion. I'll check with some other people.
Thanks Ber, Trae
Bèr Kessels wrote:
Op maandag 05 december 2005 00:36, schreef David Carrington:
3. custom.tpl.php
This is certainly something that would be beneficial. Usually it is just minor tweaks, but I've not thought of any way to achieve this without abstracting the theme functions slightly. The main reason I need this is to reorder the elements in a node - such as moving taxonomy terms to below the content.
Does template.php not suffice? I always use that, mostly because I want to keep /any/ logic out of any tpl.php file.
Bèr _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/ _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
If it were possible for CSTheme to expose its own settings somewhere in /admin/themes/settings, then the different regions of the page could be standardized and also given a weight (to be consistent with how blocks are arranged in the sidebars). Something like: HEADING: weight = -3 NAVIGATION: weight = -2 SIDEBAR LEFT: weight = -1 CONTENT: weight = 0 SIDEBAR RIGHT: weight = 1 FOOTER: weight = 10 Doesn't 4.7 already have new target regions for Blocks? Those same regions should be exposed in the theme config settings to everything matches up clearly. (I also think the navigation/menu naming needs to be more consistent in Drupal because navigation is what I would consider the primary/secondary links, which shouldn't be confused with menu.module and what gets displayed in blocks.)
Wow, this weighted idea is a really good one. Rowan Kerr wrote:
If it were possible for CSTheme to expose its own settings somewhere in /admin/themes/settings, then the different regions of the page could be standardized and also given a weight (to be consistent with how blocks are arranged in the sidebars).
Something like: HEADING: weight = -3 NAVIGATION: weight = -2 SIDEBAR LEFT: weight = -1 CONTENT: weight = 0 SIDEBAR RIGHT: weight = 1 FOOTER: weight = 10
Doesn't 4.7 already have new target regions for Blocks? Those same regions should be exposed in the theme config settings to everything matches up clearly.
(I also think the navigation/menu naming needs to be more consistent in Drupal because navigation is what I would consider the primary/secondary links, which shouldn't be confused with menu.module and what gets displayed in blocks.) _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
-- Trae "occy" McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
Op maandag 05 december 2005 19:08, schreef Trae McCombs:
Wow, this weighted idea is a really good one.
Rowan Kerr wrote:
If it were possible for CSTheme to expose its own settings somewhere in /admin/themes/settings, then the different regions of the page could be standardized and also given a weight (to be consistent with how blocks are arranged in the sidebars).
Something like: HEADING: weight = -3 NAVIGATION: weight = -2 SIDEBAR LEFT: weight = -1 CONTENT: weight = 0 SIDEBAR RIGHT: weight = 1 FOOTER: weight = 10
I really dislike this idea. Layouting anything trough a webinterface is just, well, cr@p. Something like this should be done with CSS. And changing any CSS will break the webinterface. And changing any weight in the webinterface will break your CSS. I know, I know, there are people that dont know CSS, but they will only be more frustrated if the weighting breaks the layout they had in mind. Besides all this, we can already weight any block in any region. Son introducing this, would give us a weighting in a weighting, on top of a CSS layout. Rather complex, and IMHO impossible to make a proper UI for. My advice: provide some nice style.css files that change the layout (which is not the same as the design), Bèr
On 12/5/05, Rowan Kerr <rowan0@gmail.com> wrote:
If it were possible for CSTheme to expose its own settings somewhere in /admin/themes/settings, then the different regions of the page could be standardized and also given a weight (to be consistent with how blocks are arranged in the sidebars).
Something like: HEADING: weight = -3 NAVIGATION: weight = -2 SIDEBAR LEFT: weight = -1 CONTENT: weight = 0 SIDEBAR RIGHT: weight = 1 FOOTER: weight = 10
Doesn't 4.7 already have new target regions for Blocks? Those same regions should be exposed in the theme config settings to everything matches up clearly.
Yes, that's a good point. I know blocks can be defined in an unlimited number of regions now, and blocks can be weighted, so this is already available to an extent in HEAD/4.7. Robin (I also think the navigation/menu naming needs to be more consistent
in Drupal because navigation is what I would consider the primary/secondary links, which shouldn't be confused with menu.module and what gets displayed in blocks.) _______________________________________________ themes mailing list themes@drupal.org http://lists.drupal.org/mailman/listinfo/themes
-- Robin Monks, CSL Web Administrator robin@civicspacelabs.org
participants (5)
-
Bèr Kessels -
David Carrington -
Robin Monks -
Rowan Kerr -
Trae McCombs