Project Plan for a new default Drupal 7 theme

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

The initial project plan is based on the one from Angie (webchick), our illustrious D7 maintainer, on http://drupal.org/node/293540#comment-1076165

Before modifying this project plan, please first read the discussion about this plan below.

How do we get a new default theme in core?

  1. Create a project plan for getting a new default theme into Drupal 7 core. (That’s why this page is a wiki.)
  2. Pick a flexible, easy to extend base theme for core. A group of Known Knowledgable Themers gets together and evaluates the pros/cons of all the various frameworks and chooses "the one" to go with. This is similar to how the selection of jQuery as Drupal's JS library went. Whoever heads this up, timebox the discussion at X weeks to give a firm deadline for when consensus must be reached (but leave enough time for people to comment).
  3. Add the new base theme to core. Once "The One" is chosen, we work on making that into core (which means replacing all of Drupal core's default output to match it). It should be emphasized that this is non-trivial. The chosen theme must be well-coded, well-documented, conform to coding and web standards, etc. etc. Therefore, I am completely less than jazzed about the idea of trying to do this more than approximately once. I'm very -1 to the idea of "Let's pick the X prettiest looking themes in contrib and just jam them into core." -- there is far, far more to a good solid theme than how pretty it is.
  4. Theming contest to create D7 sub-themes for core. Now that we have our flexible, easy to extend base theme in core, it's time to start a theming contest. This contest revolves around creating sub-themes for The One True Core Base Theme. Pick the best X of these and go to town. These are /much/ easier to review and get into core en masse, because they will probably be changing CSS only, or if they do override markup it'll be very short snippets.
    1. Create a theme contest RFP. We need a clear set of guidelines to what a core theme should include.
    2. Create a tarball of theme files. To get as many designers as possible, we should provide them with a simple downloadable set of files that they can use to more easily build their theme. People who enter the contest should not necessarily be Drupal theme system experts. As long as the tarball files are in version control, we can reverse-engineer any winners to see what they did and to clean up the code.
    3. Advertise the hell out of it.
    4. Vote for the winners.
  5. Evaluate the winning theme entries to see how close they are to being core worthy. Themes that have too high a wtf/min rate may need to be skipped.
  6. Add sub-themes to core. Take the “the chosen” and make them core ready and get them committed. Since the initial, un-styled tarball will be in version control, we can use that to determine what changes were made and, thus, what needs to stay in the sub-theme.
  7. Remove the cruft.

    $ cvs rm themes/pushbutton
    $ cvs rm themes/bluemarine
    $ cvs rm themes/chameleon
    $ cvs commit -m "So long, ugly table-based themes, and thanks for all the fish!"
  8. Profit! ;)

[Edit: 2008/12/14—I removed the dates from this plan since I was wildly optimistic when put them in initially.]

Comments

How much of a base theme should be in core?

JohnAlbin's picture

Let's get this discussion rolling…

Over at http://drupal.org/node/293540#comment-1076176, Merlinofchaos and I brought up a good point about webchick's “Pick a flexible, easy to extend base theme for core” idea. Almost all of Drupal core's templates and CSS is good enough to be considered a “base theme” as-is.

To see what Drupal core gives us as a strating point, you can create a new theme that just has a core.info file in it like this:

name = Core
description = Uses all of Drupal core’s default template files.
core = 6.x
engine = phptemplate

One thing that that should be really apparent to anyone who tries this is that Drupal core is missing a page layout method.

So I advocate a very light "base theme" that is more of "just a page layout method". In fact, it wouldn't even be a theme that would show up in admin/build/themes; it would just be some additional CSS and tpl modifications that any other theme can modify or override.

What does everyone think of this idea? And what do you think should be our page layout method and what are its pros and cons?

  - John (JohnAlbin)

  - John (JohnAlbin)

Theme settings?

stephthegeek's picture

What about layout options as theme settings? We've spent a lot of time working out generically useful theme settings, which have been a huge hit.

~~~
{ Drupal Themes from TopNotchThemes } Gorgeous Drupal 5 & 6 designs with support for popular modules, plus Ubercart themes!

Go Light AND go Heavy

mike stewart's picture

A light base theme is excellent. IMO, It's best (and needed) for advanced users.

But I think there should be another Heavy - Best Practices Theme - Zen, or the like.

I feel the difficulty for many new people starting with Drupal (esp. those less technical) is that Drupal so deep. It's hard to know where to begin... and there's so many "wrong" ways to do something. I think an additional HEAVY (or Deep) theme, similar to Zen, that illustrates best practices should also be part of core.

The goal should be something like:
It should be easy for people that know CSS and know Design, to be able to install Drupal and then "skin it" using their existing skillset: notepad, firebug/webdeveloper, and some web graphics program.

I even think this HEAVY theme could be a subtheme to a LIGHT core theme.

--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }

Heavy and light is good,

jeff1970's picture

Heavy and light is good, I've taken this approach also, although my theme framework goes the other way, heavy base theme with a Lite subtheme. Either way, its nice to have either in reserve for when its needed or makes sense.

I definately agree.. How

qbnflaco's picture

I definately agree..

How about "pond"(light theme) and "abyss"(deep theme)?

Base theme VS. Stater theme

JohnAlbin's picture

Oh! Excellent suggestion, Steph!

I really like the idea of a toggle that does:

[] left and right sidebars on either side of content.
[] left and right sidebars to the left of content.
[] left and right sidebars to the right of content.

It would be great for a sub-theme! But I think the base theme should be REALLY light.

So, I'm starting to think that we need to do something really similar to Zen's STARTERKIT.

  1. The base theme should be very light weight. Probably just minor touch-ups to the tpl.php files in core and the addition of a page layout CSS file.
  2. For the theming contest, we need a STARTERKIT that has really good options in it (and possibly lots of tpls in it that are dupes of core’s—making it easier for CSS experts that are not Drupal experts). This can be the "tarball" that I mentioned under the Theming contest plan.

  - John (JohnAlbin)

  - John (JohnAlbin)

Disagree on toggle

merlinofchaos's picture

IMO a toggle complicates things.

Why don't we make them different base themes. That is, frankly, easier for a themer. They just subclass the theme they want that has the layout they want to use and go from there. A toggle adds code and if you've got a person who is really good at HTML + CSS, code is just going to get in the way. It almost makes it harder to subclass the theme because do you really want to make themes account for all the possible layouts?

I see the following possibilities:

Fixed or not fixed
Sidebars: 1, 2 or 3
Sidebar positions: left or right, left/left, left/right, right/right or left/left/right or left/right/right respectively.

Set up the page.tpl.php and sensible layout.css and make the themes available. Then pick one or two, subclass them, and create a beautiful theme. Maybe add a toggle in the beautiful theme so that we can demonstrate how, but that's a discussion for much later.

Agreed.

JohnAlbin's picture

I guess I got caught up in the "ooh, this is cool!" factor.

You are correct in that having several sub-themes each with a different page layout is a much better way to hand out the options to prospective themers. A toggle is complex and Drupal core's "sidebars only if there's content" is already a hard enough concept to grasp for new themers/users. If we want to attract the widest possible designers, we should go the multiple sub-theme route.

  - John (JohnAlbin)

  - John (JohnAlbin)

So I agree completely that

caroltron's picture

So I agree completely that we do not want to over-complicate things by clunking up the interface with "toggles", however I do think we need to make basic theming a bit more approachable, and I really believe that one way to do that is to allow this "light" base theme to have more admin configure-ability. There are people who know CSS, but aren't as skilled in the page layout method that is used in Zen...I think there is value in doing that "math" for them.

In a perfect world a newbie could download drupal, install the site fairly easily (which already is great), and pick some colors for their theme and turn off regions like left and right sidebar, and maybe upload some banner images or other treatment that could add individuality to their site. The audience that I'd love to target is the basic user who only knows "light" css, i.e. font coloring, and other minor formatting. Why scare them with the site info file (which is not scary to me or other themers) and all the css layout methods. Why invite them to change the markup Drupal is giving you?

I guess I'm thinking of my friends, who know little to no CSS/HTML or even FTP, but they want to create and manage their own website and NOT use Apple's iWeb. I want them to use Drupal too.

-cc

Marina?

Crell's picture

The Marina theme that is included with Acquia includes a large number of toggles and buttons that make use of the theme settings api. Some are not so well implemented internally, IMO, but part of that is theme settings api's fault as it has to do some nasty footwork to avoid namespace collision. Still, one can do a decent theme with toggles if done properly. It's definitely worth looking into here.

I'd say step 1 should be tightening up theme settings api to make such toggles easier to to. Then we can decide which ones make sense to do once we can change which are done easily.

starter theme, contest

jeff1970's picture

So the starter theme would contain

startertheme.info
template.php (with sample preprocess functions aka Zen StarterKit)

Templates:
box
block
node
page
comment

CSS:
style.css
style-rtl.css (?)
ie.css (?)

With the layouts provided by core? eg.
layout.css

Like to see some effort towards an any-order-column layout method (to support content source ordering mainly) as opposed to a more simplistic float:left margin: right type layout.

Theme contestants should not be allowed to modify the layout html, and IMO the core 'beautiful' theme should support all the layout options. Moving and modding of other elements eg site_name, site_slogan, search_box etc should be allowed.

IMO we should unceremoniously dump support for series 5 browsers - maybe we can adopt YUI's A grade browser list as a guide for browser compatibility?.

@merlinofchaos - can you clarify what you mean by "left/left/right or left/right/right" , do you mean splitting the right or left sidebar (nesting) or a 4th column

I like where you're going

caroltron's picture

The idea of a giving the "website creator" a small number of steps is what appeals to be me here - a thinned layer. As a themer myself, I need a robust mold-able theme (like zen) so that I can bend any design into it. But if I wasn't a themer, and didn't know anything about the theming structure in Drupal I would immediately be confused about how to "tap into" all the great pieces of Drupal. I would want some hand holding or some pointers and the more those can be simplified the better. The less files the better.

I'd like to help out in whatever way I can. I've built enough sites using Zen and had to train very non-technical clients that I think I can offer some helpful perspective here. Let me know how I can help!

-cc

-cc

hidden flag

Crell's picture

Modules in D7 now have a hidden=TRUE option in info files that hides them from the admin. If we ship a "base theme" in core that is intended primarily for sub-classing, we should be sure to give themes the same capability so that we don't have a massive number of half-finished themes in the admin.

Actually we should probably do that anyway. :-)

Genesis theme as base?

stephthegeek's picture

http://drupal.org/project/genesis looks promising. I like that it's already got the ball rolling with subthemes and seems to have some good momentum behind it rather than being a dev version that's lingered around forever.

We (TNT folks) are definitely interested in helping with this, especially with the theme contest since this is something we were planning already anyway :) Our wedding is in November and things are uber-nutty right now though, so we'll probably be more involved after that.

~~~
{ Drupal Themes from TopNotchThemes } Gorgeous Drupal 5 & 6 designs with support for popular modules, plus Ubercart themes!

Genesis guy here.

jeff1970's picture

John, I love this concept, a lightweight set of layout classes or methods is perfect in my eyes.

Frankly I like good old floats and negative margin layouts. Initially I wrote about 20 such layouts for Genesis and stripped it back to 7 layouts that I use and prefer. Basically all I need to do is change the body id selector and the layout is set. Changing the widths of the columns is trivial - I can just copy over the respective layout (5 or 6 lines of CSS) to my subthemes CSS file and tweak it.

I don't think I could advocate using Genesis in its entirety (maybe its too fat + the way I use page_classes may not be an ideal approach, but it avoids me having to use chained selectors). I'll be bringing it out of dev next week, its pretty new and I've been ironing out the bugs the last week or so.

I like this idea of prebuilt layouts, I think its easy to get started with for many users. If most others think a set of grid classes is a better way to go, then well I suppose I'll help out on that, but frankly I'd never use it. Blueprint/Grid 960 etc are elegant but not source ordered and are stuck with fixed width. I really need the flexibility to be able to go beyond those limitations.

TNT theme settings are freakin awesome, Acquia Marina flawed me when I first saw it, that said I don't really like the idea of setting layout as a theme setting, for one its global (am I right here, or could it be made not to be?). I might want to have one section 2 cols on the right, another section 3 col standard etc so I like being able to use the body ID method and section specific page.tpl.php files. Originally Genesis used a theme setting to set the body ID, only near the end did I see the limitations and ripped it out.

I understand nothing about

Wolfflow's picture

I understand nothing about the different aspects to take in consideration of choosing the right and best theme to start over for proposing a new default theme for Drupal 7. I beg your pardon if I just chip in to propose a Theme that IMHO as a end-user of Drupal for about 2 Years I would take in consideration: Sky created by Gravitek Labs.

I can just say that for a beginner there is not much to do for starting over with this Theme. It looks like that it contains really all what you need for having may little configurations settings and it looks great. I my self have really tested many other Themes before ending to Sky for my own Blog.

Here some screen shots: http://sky.graviteklabs.com/screenshots

This is what I wanted to mention.
Wolfflow

Hooray

eigentor's picture

Bloody great, this is rolling!
Did not read the related issue recently, amazing! http://drupal.org/node/293540
I will be definitely on it - and on creating a cool web page for the contest.
How about:
www.drupal-gets-new-clothes.org ;)

Got some ideas for it: sure include a theme switcher to allow live previews. A feature to vote themes up and down would be nice for voting, so this gives it a bit more "punch" (If you get a lot of votes, you are on top). Also one could think about how much weight the community vote should have - there should be a Jury and also a portion of community vote. Maybe 50:50?

To give Sponsors sufficient visibility, a groups page might not be enough. so a dedicated website would be appropriate. What I also thought about is, give away a lot of small sponsor packages about $50, cause this affects anyone who works with Drupal, and one might easily accept to throw in a few bucks.

To me, this project is nearly as meaningful for Drupal as the drupal.org redesign. (well, not quite, but yet...) The product needs a package.

So I'll concentrate on organizational matters and keep away from the design and tech discussion for a while...
(but yeah: pick a base theme and do the rest in css-zen-garden way makes absolutely a lot of sense. This would also give the designers more concentration on design)

Life is a process

Life is a journey, not a destination

Having a really solid base to work from

jwolf's picture

Having a really solid base / framework to work from is extremely important. Let's forget about the eye candy and the bells and whistles for now and focus on the foundation.

Perhaps we can compile all the good aspects of some of the base themes that we already have to choose from and make a really solid foundation out of that.

A little bit of Zen Starterkit, some Blueprint, a touch of Genesis, and a pinch of Framework...

Once the base is complete, and documented, we can then pass it along to those wishing to compete in a theming contest.

Enhance page class

sun's picture

Not sure where to add this, so I just add it here, so someone might account for this when working on the base theme.

Designers often need to be able to style certain page "classes" differently. We turn the first argument already into a class name in core; the Genesis theme (which I do not use) provides this as "section-$arg1" and "page-$arg1-$arg2-..." classes. However, the first class is often too limited and all arguments are too specific. Here is what I use:

<?php
/**
* Determine and set path-based CSS class for advanced theming.
*
* Depending on the current path, corresponding CSS classes are generated;
* without numeric parts.
*
* @example
* - The path 'user/#/edit' becomes "user user-edit".
*/
function phptemplate_page_class(&$vars) {
 
$args = explode('/', $_GET['q']);
 
 
$class_full = $class_base = array('page');
 
$cut = FALSE;
  foreach (
$args as $arg) {
    if (!
is_numeric($arg)) {
     
$class_full[] = $arg;
    }
    else {
      if (!
$cut) {
       
$class_base = $class_full;
      }
     
$cut = TRUE;
    }
  }
 
 
$class = implode('-', $class_full);
 
$class_base = implode('-', $class_base);
  if (
$class_base != 'page' && $class_base != $class) {
   
$class .= ' '. $class_base;
  }
}
?>

Also, some important Drupal core issues that have a great impact on a base theme:

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

Class inheritance

sun's picture

Another thing a base theme should do finally right is implement proper class names. Drupal can, for example, output blocks inside nodes, nodes inside blocks, comments in blocks, blocks in comments inside nodes, nodes inside blocks inside comments, and most themes still stick with:

<div class="node">
  <div class="title">...</div>
  <div class="content">...</div>
</div>
<div class="block">
  <div class="title">...</div>
  <div class="content">...</div>
</div>
<div class="comment">
  <div class="title">...</div>
  <div class="content">...</div>
</div>

Now, when having to style large(r) Drupal sites, you either fix those classes (i.e. title => block-title aso.), or you do silly CSS overrides:
.block .title { margin: 10px; }
.block .comment .title { margin: 0; }

Daniel F. Kudwien
unleashed mind

Daniel F. Kudwien
netzstrategen

+1

jeff1970's picture

For class naming that allows greater specificity without the need for those silly over rides.

Bluemarine is already converted!

xmacinfo's picture

Please note that Bluemarine is now a citizen of fully web standards compliant themes. There were a task in GHOP to convert it.

http://drupal.org/node/200685

So one less theme to convert.

Can we talk about frameworks

dvessel's picture

Can we talk about frameworks first?

I did a quick run through of a few CSS "frameworks" looking through these two sites:

  1. http://hiddenpixels.com/css-stuffs/css-frameworks/
  2. http://konigi.com/notebook/css-framework-roundup

Here are the requirements I believe it should have.

  • Flexible –especially for layouts.
  • Light weight
  • Easy to use for web designers.
  • Most likely to be accepted by web designers and I mean the individuals that work the web and don't necessarily work with Drupal.

The ones omitted I thought were uninteresting, they borrowed from the ones listed here or their licensing prevented them from being hosted on d.o. (GPL).

  • Blueprint
    http://code.google.com/p/blueprintcss/
    license: GPL, MIT

    + Light weight.
    + Light xHTML markup. Doesn't require wrapping of divs to achieve its layout.
    + Easy to use and well documented.
    + Well known by the web community especially outside of Drupal.
    + Great for quick prototyping. –It's what Mark Boulton is doing for the drupal.org redesign.
    + Class names easy to understand even though they aren't semantic but I don't see this as a deal breaker.
    + Reset styles and maintains vertical rhythm. (nice to have.)

    - Strictly fixed width. The overall page width must equal the sum of all internal pixel columns making it rigid. Must design with that in mind or it can waste time tweaking to fit the grid. In other words, it doesn't work for everyone. It's ideal in certain workflows. There's work on percentage "spans" but I don't like the implementation. It's basically a swapping of pixel values with percents for the same .span-x classes.
    - Order of presented columns must match source order. This may not be important to many but having this flexibility would be nice.

  • Emtastic
    http://code.google.com/p/emastic/
    license: GPL

    + Light weight.
    + Light xHTML markup. Doesn't require complex wrapping of divs to achieve its layout.
    + It can use ems, px or % for the overall width.
    + It can also mix em's with a fluid space within a single row. For example, ems and an unmeasured fluid space. Also alows em sidebars and fluid centers.
    + Allows elastic layouts. [example]
    + Source order does not have to match display. There seems to be some limits with this but it looks flexible enough for most.
    + Reset styles and maintains vertical rhythm.

    - Still in beta (beta 2 atm).
    - Early in their development and low activity in their google project page. But in my brief testing, it was solid across all browsers including IE6.
    - Using ems for the whole row can cause the same limitations as Blueprint. i.e., the sum of the columns must equal any containers. This is expected though and it should be apparent to anyone with a good working knowledge of css.
    - Limited to em and fluid widths for internal rows. Only the outer page container has the option to use % and pixels. It's easy enough to modify if needed.
    - Problems with clearing in mixed fluid/em rows when the fluid column runs out of space. Easy to fix in all browsers except IE6 with "min-width". (IE7 supports this)
    - A few abbreviated class names makes it slightly opaque at first but due to its simple nature, I think it's okay. So this is a very small minus.

  • Tripoli
    http://devkick.com/lab/tripoli/
    license: GPL

    + Light weight.
    + Supposedly bullet-proof down to IE5.
    + Designed with the ability to "plug-in" external styles in mind. (Not sure how this works.)

    - Still in beta.
    - It's not a framework. A lot of assumptions on how your tags must be structured. This is expected in any framework but this goes beyond that.
    - Layout styles are limited. It's canned with either 2 or 3 columns set in percentages.
    - Forces specific id's on a few elements in the layout style.
    - A lot of forced font sizes and selectors use ".content". Could cause unintended effects since that class is commonly used.

Are there any more to consider? I'm really liking Emtastic on first glance. I'll play with it some more. I was considering creating my own but that's just crazy talk. :p

I haven't looked closely at the proposed themes but are any of them frameworks? Outside of the Blueprint theme, how about mentioning their flexibility. Do they have canned layouts? If so, -1 from me.

Grid 960 is GPL/MIT

jeff1970's picture

Grid 960 is GPL/MIT

This theme in contrib uses it - http://drupal.org/project/hiroshige

...

dvessel's picture

I thought it was based on Blueprint so I skipped it. Looks like it isn't. The approach is similar for their grid system so it would have the same limits.

But yea, another one to consider. I'll play with it and hope everyone else does the same.

Some background and details. http://sonspring.com/journal/960-grid-system

Playing with 960

jwolf's picture

A few thoughts that stand out for me after playing with the 960 Grid System are:

+ Pluses +
The bundled printable sketch sheets and design templates for Fireworks, Photoshop, OmniGraffle, and Vision. Having these available is a huge asset in helping with the communication between themers and designers.

A simplified naming convention. Blueprint's naming convention can take some time getting used to. Having a simple naming convention will definitely help reduce the learning curve for those who are tackling a framework for the first time. This simplification means more time spent on creating themes and less time learning how.

- Minuses -
(very minor minuses)

960 has a very limited typography foundation and no foundation for forms. I think having a solid foundation of default styling for forms is very important for Drupal theming.

I'm really liking 960 grid

dvessel's picture

I'm really liking 960 grid system. Thanks jmburnz for bringing it up!

+ Makes no presumptions on colors. Unlike Blueprint, it doesn't color backgrounds like the table header or page background. Doesn't color fonts either. It's up to you. The base theme would be as plain as possible. I found one instance of a color property which was on a horizontal rule. Core should be cleaned of colors too.

+ Doesn't need IE specific styles. All it needs is a display:inline rule in the main 960.css file to avoid the double margin float bug. Standard browsers don't mind it. This is minor since just about all themes will end-up using IE specific styles but I thought this was interesting.

+ No need for a .last class to chop off the right margin on the last row. All the margins (gutters) are accounted for in the full width. It's the reason why Blueprint uses 950 pixles. The 10 px margin is cut off. Minor, I know..

+ The margins are also placed on both sides of each column which I think would be easier to work with. Blueprint only uses right margins and designing like that you have to have a slight mental shift when laying things out in Photoshop in some situations.

+ I think the class names makes sense. Mainly "grid_x" vs "span-x" in Blueprint. The creator mentions that span already has meaning in html so it bothered him. I do agree that it's a little annoying.

+ Comes with templates for Photoshop, Fireworks, OmniGraffle and Visio. It also includes a printable sketch sheet. This is a nice touch. :) I prefer to sketch designs on paper first and this would come in handy.

- Fixed at 960 pixels. This was a design decision so it matches a printed A3 page –my mistake. Got confused from Boultons article and it wasn't even a3 and remotely close to the right reason. The real reason is here. I don't mind this and it can be worked around but others may prefer more flexibility without tweaking the css. We could extend this a little so this isn't a problem.

- The internal columns are fixed pixels so it's the same situation as Blueprint. You need to design with that in mind. The printable sketch sheet and templates mitigates this a bit.

- Class names use underscores. It goes against Drupal's convention of using dashes.

Even though everything is fixed width, I think with some tweaking it will allow more flexibility by allowing fluid columns. The reason Emtastic allows it is because the fluid regions are static. It doesn't float, only the blocks with em widths float. This also holds true for Blueprint of course. The reliability in this when the page is filled with something closer to real content is unknown but I'll try to play with this.

So far, I like 960 the best.

-1

elv's picture

One vote against all themes with fixed width columns (Blueprint, 960gs...), I believe it's not flexible enough as a base theme.
Sometimes you just need columns with different width to fit with some contents (especially ads and videos).
Also as a themer you are sometimes given mockups with column widths that don't match those grids.

It's one of the reasons I don't use Blueprint anymore.

...

dvessel's picture

I agree with you. It's not something I'd try to use in all situations and having some limitations when starting from scratch does force me to focus so I like it for that.

I agree working with fixed

SeanBannister's picture

I agree working with fixed width columns is a pain

I agree!

CZ's picture

Yes, and I am not a fan of blueprint bluetrip 960 or other static* and fix (px), liquid (%) or elastisch (em) only css frameworks.

Can we not use a flexible/editable grid in a core theme [2]?

*Colum width defined static in the css files.
[1] http://groups.drupal.org/node/16200#comment-68321
[2] http://groups.drupal.org/node/19817#comment-69598

Another vote against fixed width

whatdoesitwant's picture

I myself would prefer the approach mentioned here:
http://alistapart.com/articles/fluidgrids

Someone managed to create a mootools based interpretation of 960 to get to fluid grids.
While not practical, a jquery reworking of that could benefit ie users.

update on source ordering vs. visual order.

dvessel's picture

Blueprint was updated so the source order doesn't have to follow the visual flow. It's done through the .push-x/.pull-x classes which existed already but didn't take it far enough.

It hasn't been released yet but it's a very simple addition. This would also be very simple to add in 960.

I'm a huge fan of Blueprint

m3avrck's picture

I'm a huge fan of Blueprint and maintain the Drupal version of it ; http://drupal.org/project/blueprint works great and I'd be in favor of something like this in core just like jQuery.

Partner at Detroit Venture Partners. Sold ParentsClick to A&E. Ex-Drupal dev. Cornell Engineering alum. Tech pioneer leading startup renaissance in Detroit.

Also...

keith.smith's picture

I noticed this "BlueTrip" framework on the front page of del.icio.us's popular links today; I think it's a cross between Blueprint and Tripoli. There are a couple of grid and typography demos on:

http://capsizedesigns.com/blog/2008/04/bluetripcss-a-fusion-of-blueprint...

I just added the adaptation

couzinhub's picture

I just added the adaptation of the BlueTrip framework to drupal.org, you can try it out here :

http://drupal.org/project/bluetrip

Will develop more about this new theme soon

Layout Gala

eigentor's picture

Please don't forget Layout Gala.
Minimalistic to the bone - editors choice.
http://blog.html.it/layoutgala/

Even if it not exactly a framework, it does the same job.

Life is a process

Life is a journey, not a destination

-1

dvessel's picture

Each layout has very specific styles. Their goal is to use the same markup for various layouts. I think it should be the opposite. Providing multitude of styles that can be plugged in may be useful to some but I think it's too limiting and difficult to maintain.

Source order

jeff1970's picture

One thing I like about Layout Gala, and Zen for that matter, is the content source ordering. For my regular clients this is very important.

Don't forget new themers

ztyx's picture

It is a nice feature but can at the same time be very confusing for beginner themers. I opt for having both a theme with source ordering and one without.

Marketing approach

iraszl's picture

I think as a first step we should identify why we need core themes? What is their purpose and who are the people using them. This is a marketing perspective, not a developer one, but I think it's useful.

Target groups

There are four types of Drupal users in regards to themes:

1. Site builder who will have a custom theme done by someone else.
He needs a core theme to display content, so he can build the site functionally. He doesn't care how pretty it is, but he does care about how well and clear all content is displayed. Any prettification for him is a distraction and counter productive. He doesn't care about the looks, because he knows that a custom theme will be done for the site eventually anyway.

2. Designer who needs a core theme to use it as a starting point to create his custom theme.
Same applies here as for point 1 with extra requirements. All content has to be easily addressable and well cascading. Also, everything has to be very well documented.

3. Hobbyist or low budget site developer with no design knowledge.
This person has no money or time to build a custom theme. He need a great selection of themes he can try out easily and customize easily to make it as unique as possible. For these guys it would be best to have a big selection of ready made themes or themes that can be customized with certain limits (like the current core theme).

4. Hobbyist of low budget designer with design knowledge.
This person has no money or time to build a custom theme. He needs themes that are highly customizable with ease. These themes should work out of the box, but could be easily modified to create relatively unique themes.

Theme types

Therefore I propose we do three branches of themes:

Minimal base theme
To cater for 1 and 2 we do a minimal theme that is extremely well done and well documented.

Themed themes
To cater for type 3 guys we do a few themes that can be customized by changing the color schemes. These themes should be radically different from each other and represent main stylistic areas of design. Again we may think about the targets here. For example we can identify subjects and build a theme for each. Each can be named accordingly to help selection type 3 guys:

  • Financial
  • Entertainment
  • Educational
  • etc.

Customizable themes
To cater for type 4 guys, here we identify a few main structural variations that are radically different from each other and represent a good coverage of design styles. Here the objective will be to create themes that are more than the minimal base theme and includes all the files including vector or layered bitmap files that are required to create relatively unique themes with ease. Here we can also create named versions such as:

  • Navigation heavy
  • Image heavy
  • Text heavy
  • etc.



We could split the job into 3 main groups and under Themed themes and Customizable themes we can create sub groups.

So, what do you guys think?

...

dvessel's picture

I agree, we should all know who we are targeting. I don't think we have to please everyone with this but the primary target should be known.

I was thinking of designers as primary group to target. If this can work out, the rest can follow.

There is one other primary

merlinofchaos's picture

There is one other primary target: that is the 'look and feel' of Drupal, which is the first impression people get. That's what Garland was meant to be. It helps establish that Drupal can be attractive. This theme isn't necessarily 'for use' but we'll find it gets used a lot simply because it's very easy to just set a site up.

This is the same reason that the base Wordpress theme (Marvin?) gets used all over the place -- because some people don't care.

Yes that's a very important

SeanBannister's picture

Yes that's a very important point, the chosen theme will be used on a lot of Drupal websites and therefore will be seen as "Drupal", it'll also be the first thing people see when installing Drupal so it has a lot to live up to. Not everyone who installs Drupal are developers and not everyone who installs Drupal for the first time has read about all the great backend stuff, they're just installing it to test it out and this theme will be the first thing they see.

Yes, I agree. This is an

iraszl's picture

Yes, I agree. This is an important addition. We should do a "display-window" theme that is shown by default.

Three types of marketing people

peterx's picture

I agree with considering the market. Marketing people are useful. There are three types of marketing people:

  • Those who understand mathematics
  • Those who do not

The problem with classifying current users and developers is the fact that Drupal already appeals to them. Analyzing them does not make Drupal appeal to people who do not like the Drupal current approach. For that reason, I suggest some left handed themes. Do the big winner theme and add some alternatives including a very light CSS only theme. Then add examples of really different layouts and menu approaches. Looking through the demonstrations of themes with default settings at http://d-theme.com/, here are some ideas to include as alternatives.

Skyliner, http://d-theme.com/skyliner, is pure CSS with background images that would be nice if it was wider.

CDMUG, http://d-theme.com/cdmug, has a fascinating variable heading. Look at the theme across the day and evening. Definitely worth inclusion as a demonstration subtheme built on your base theme.

Candy Corn, http://d-theme.com/candy_corn, was dropped because of GPL but those menu decorations should be in a demo subtheme. In fact, we should include subthemes demonstrating all the menu layouts shown in the Superfish examples at http://users.tpg.com.au/j_birch/plugins/superfish/#examples.

http://mulders.me/ shows 1024px, http://d-theme.com/1024px, with vertical centering. 1024px makes good use of whitespace, something missing from most themes. 1024px is easy to make fluid and is ready made for vertical centering, all features that some people want. Currently those people choose something other than Drupal because they can get the look they want out of the box.

If Drupal includes several base themes, pure CSS, a light white spaces source ordered accessible theme, and a monster swiss army tank like Zen, with each theme having subthemes for the various page and menu layouts plus some Candy Corn flexibility demonstrations, you could satisfy 95.73 percent of all the reasons people go elsewhere.

I've done a little looking

merlinofchaos's picture

I've done a little looking at some of these and they bother me. I don't like the naming schemes and I read a little criticism of emastic which I agree with: It's just moving <style> tags into class tags, but the classes are fairly specific and they're specifying more layout than I believe they should.

I'm becoming dubious that these css frameworks are a good idea for us.

...

dvessel's picture

I'm less enthused about Emastic now and it does take it a bit further on using classes as shorthand but it's really nothing new in what it's doing. It's been beaten up already on whether it's a good idea or not but frameworks are definitely useful. It has been embraced by a good number of web designers judging by the amount of activity on the web.

It's not for everyone. I generally dislike fixed designs but I've used Blueprint for some projects when the grid and fixed width are good enough. It is awesome for some workflows when you understand how to design on that grid. If we must make sure everything has to have semantic classes, your right. We should forget these frameworks. I personally draw the line on semantic markup. Semantic class names and id's are never perfect so I gave up trying to perfect them.

maybe a stupid idea, but how

sign's picture

maybe a stupid idea, but how about splitting themes into two parts:
layout
-- 2 col
-- 3 col fluid
-- custom
...

theme (style)
styles+images+overwritten tpl.php files or custom layout settings

the theme will work actually as a sub-theme (with possibility to overwrite tpl.php files) of a layout theme, but wont be required to be in the dir of layout,
then user can pick from layouts, and then themes (styles), or themes can merge with layouts they support (defined in .info file) on admin page, so it will create screen like

-garland fieldset
---3 col fixed (checkbox)
---3 col fluid (checkbox)
---2 col fixed (checkbox)

Hi, do you need help?

vladocar1's picture

Interesting discussion! I don't have much experience with drupal but I think is probably one of the best CMS. I'm author of Emastic(CSS Framework). I think that the idea of using some CSS Framework + Drupal is great. If you want I can make some extension or plugins for Drupal. Probably next mount I will publish the new version of Emastic with even more improved grid system. So if you need help let me know!

Thanks for dropping by. The

dvessel's picture

Thanks for dropping by. The only thing we need to consider at this point is a light weight and solid framework that is flexible enough for most of our themers. I did like that yours wasn't restricted to a rigid grid but still gave the option but could you give links to real sites using your framework? As much as you can give just to see how it holds up.

thanks!

The problem with Emastic is

vladocar1's picture

The problem with Emastic is just 3 mounts old and that and there are not so many people using it. For now I can share just my personal experience. I think that the grid structure is pretty solid and flexible at the same time. I did some tests(from IE5.5 to Chrome) putting DIV inside DIV inside DIV and the structure resisted. Basically you can put DIV with 200px inside the DIV with the same size(200px) without a problem. Yesterday in about 1 hour I did like 12 different layouts ( I will public them when I have extra time). In my opinion using Drupal + some CSS Framework is very interesting solution because Drupal is all about modules and grids. I'm not saying use Emastic or Blueprint just consider the possibility of making one standard CSS model who will be flexible for all.

Theme selection on istallation

eigentor's picture

It is so hard to stay out of this discussion... I give up and join in.
I forgot where chx made that remark. But what would really counteract a situation of over-garlandisation just with a new theme: He suggested to give the user a choice in installation which theme to use (of say a choice of four or five, not too many).

I really like that idea. What should be considered - given that others like it too - is this must not complicate the install process and confuse the user (I once installed ezPublish that has that feature and it frightened me). So my idea would be to put that step after the actual installation: "Installation is complete! Congratulations. Choose a design for your Drupal site." Extra page (wizard-like) with Thumbnails of designs to click. And a button to bypass this step and choose default theme. Doing it this way would also make the programming much easier: having just an outward-facing theme switcher and no extra logic.

And boom - the drupal face is diversified. After a while everybody will know the five Drupal Designs (that could be all based on our to be or not to be Framework or base template), so still everybody will know: this is Drupal. But personally I will be saved from Eye-Cancer and brain damage because of over-used default theme.

As the backend (Admin-) Theme will be a default one too (and by default a different one from the front-end Theme) There will always be a common Drupal face you can recognise, especially when watching Screencasts, that mostly wander round the Admin Section.

Life is a process

Life is a journey, not a destination

Theme Choice on Install

flickerfly's picture

I think giving users a quick choice of a theme on install is a great idea. Like eigentor mentioned, it should be super simple and easy to select them. Of course, this would be a very graphical thing. Perhaps we could even integrate the color module choice into the mix to help diversify things. Encouraging the use of the color module would make a big difference in this regard as well.

As mentioned previously some users won't care because they know a designer is following behind. Perhaps install should just give the option, "Would you like to select a theme: Yes or No". No would simply select a nice simple usable and quality theme. Yes would take them to a screen that gave them the option to preview the theme and then play with the color module to select a preset or custom color scheme.

It increases install complexity only if they want it too but give them the option to have a custom look through the simplicity to color module. Currently, setting up custom colors just isn't obvious or easy enough for those who only kinda care.

Base or not?

elv's picture

I'm starting to wonder if adding a base theme into core is a good idea. The nice thing with these base themes/css frameworks is that there are so many to choose from. Every one of them has a purpose, and often choosing one over another is just a matter of taste. Or zealotism :) We'll never reach a consensus on this topic.
For theming experts, imho we don't need one in core. They will choose the one they like in contrib.

On the other hand, what I think we may need and focus on is a default theme that is both nice and easy to tweak by people who are not html/css experts. People often keep the default theme and edit it, and of course they have a hard time as Garland is quite complex. I think they don't even try to use another simpler core theme because those don't look as nice as Garland.
So, nice with a simple structure, simple templates, simple css (yeah it's a bit of a challenge). And perhaps a few css only subthemes to show how it can be tweaked.

I also like Merlin's idea: using the default html output and creating css only themes. With sane defaults we can do a lot with css.

...

dvessel's picture

I'm starting to wonder if adding a base theme into core is a good idea. The nice thing with these base themes/css frameworks is that there are so many to choose from. Every one of them has a purpose, and often choosing one over another is just a matter of taste. Or zealotism :) We'll never reach a consensus on this topic.

I agree about adding existing themes into core as a "base". I never use contrib themes and if this happened, I'd never use the core theme. Having a framework like 960 or whatever else is nothing like getting a base theme which are already prettified. It would be a bigger waste of time undoing all the styles then starting from scratch.

On the other hand, what I think we may need and focus on is a default theme that is both nice and easy to tweak by people who are not html/css experts. People often keep the default theme and edit it, and of course they have a hard time as Garland is quite complex. I think they don't even try to use another simpler core theme because those don't look as nice as Garland.

This is where I think the frameworks can help. You don't need to be an expert. Just enough time to get acquainted and most compatibility issues are solved. IE problems is what really makes things difficult. If that was never an issue, css and html isn't all that hard to understand.

It also helps with support. The framework will allow a common language instead of second guessing what the theme is doing.

We can have our pretty theme but that base I think should be no frills not getting in the way. Not everyone has to use it. It would be an option but having it in core would simplify how we describe layouts and everyone would be on the same page.

This is where I think the

elv's picture

This is where I think the frameworks can help. You don't need to be an expert.

Well I'm on the fence, frameworks are not necessarily easier to deal with imho. They are more abstract, you have to learn how they work. For non-experts, changing the width, and perhaps the order of the columns in the html code may be more straightforward than adding obscure class names like "span-15 prepend-1". I mean, if you're going to tweak the styles, then you probably already know enough css to do this (for a simple layout).

By the way, Nick Lewis just published a post on the subject.

For something like YUI, I'm

dvessel's picture

For something like YUI, I'm with you. Very abstract which I find to be a hinderance but Blueprint, 960, etc.. the abstraction is very shallow.

The class naming can be learned and I think it's a relatively easy learning curve. For Blueprint, a lot of people already know it. The bigger issue is working within a grid which requires a specific mindset. If a prepackaged prettified theme has already dealt with that, then it's less of an issue for others to tweak.

reset?

Nick Lewis's picture

960 looks really cool. I'll have to check it out. Still though, I feel like people already have enough of an uphill battle learning drupal theming. If we go down the direction of adding in a CSS framework, I feel like we need to be able to argue that it will make it easier to dive head first into drupal theming, not the other way around.A first step might be adding a reset in drupal.css.


"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
blog: http://nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

Holy shnieky, tell me to

Nick Lewis's picture

Holy shnieky, tell me to shut up. I gave the 960 system a spin, and am floored. Its very easy, too easy. There's no more than 4 concepts you have to learn it seems. Okay, I take that all back, 960 [insert 10 chuck norris jokes here]....

"I'm not concerned about all hell breaking loose, but that a PART of hell will break loose... it'll be much harder to detect." - George Carlin
blog: http://www.nicklewis.org


"We are all worms. But I believe that I am a glow-worm." - Winston Churchill
work: http://www.chapterthree.com
blog: http://www.nicklewis.org

Now yer talkin!

jwolf's picture

Now yer talkin!

We should seriously consider a Drupal CSS Framework - something that is suitable for Drupal.

Packaging D7 up with a css framework can't hurt anything; it definitely would add some value.

Thank you!!!

dvessel's picture

Thanks for actually testing it out! Learning a generic theme with its own one-off layout properties vs. the framework.. How is this not a good thing? The latter can take us a lot further. There are other pluses I've mentioned in this thread but another is that this style of developing themes can help usability and visual consistency. How's that not a positive. Grids can work as a scaffold guiding designers into making cleaner layouts.

Another plus is that it could possibly make designers have a second look at Drupal. Even if we didn't include the framework, anyone can implement it on their own but bringing it into core would give some reassurance that there would be no gotchas in the process.

I'll personally clean up core styles so it's bare as long as I have someone besides me preventing patches from rotting. The other issue is core throwing colors around or making design decisions. Remember the Aussie team in that challenge? The themer had a hard time. Some of it has been fixed but it can still be improved for incoming designers. Drupal often gets in the way. Lets clear a path.

I just hope others can try it out themselves. Me or j_wolf will be releasing a bare base theme within the week just so others can test it out.

Yeah, Drupal's default CSS

SeanBannister's picture

Yeah, Drupal's default CSS does get in the way and you have to untheme it, that's one of the things I like about Zen's STARTERKIT theme

?

dvessel's picture

So, Zen does this? I don't remember it resetting the default css. Lots of reference files which is nice.

A few articles..

@#2

jeff1970's picture

Should we choose to go for a contrib theme rather than forging something new, I'd like to propose the Basic theme by Raincity Studios. Basic is a stripped back version of Zen and I think this provides for a pretty good starting point.

If we went for this I'd like to see a few changes:

1) Rip out the default styles. However, I tend to like the idea of the subtheme having a few basic styles, to avoid a possible wtf do I do now when first enabled.

2) Consolidate the stylesheets, i.e. help mitigate stylesheetitis and IE7's 31 stylesheet limit, as discussed here, which I've seen crop up, more than once. Perhaps this is irrelavent should most of it be served by core.

3) Beef up the templates, IMO theres not quite enough HTML there for design contingencies, more like original Zen is better, but with Basics more intuitive source order.

4) Follow suns recommendation and be more specific with class names, i.e h2.node-title not h2.title

5) Build a set of canned layouts similar to Genesis, ie left/centre/right, centre/left/right etc etc, I've played around with this in Zen and initially I think this is fairly strait forward. We could rip the layouts out of Genesis since they are pretty well tested and in essence are reasonably similar, probably a bad idea really, since I think Border Politics looks like it can handle it.

So, my vote is for Basic, I like the fact that is essentially Zen and could even be pitched as such, which carries identity and kudos as a project. Zen could then perhaps be seen as the heavy weight big-daddy framework to step up to should one need to.

Zen is smaller than Basic

mike stewart's picture

The fact of the matter is by using conditional includes, Zen is smaller than the Basic theme, with the benefit of being more "complete." http://drupal.org/node/306856#comment-1011409 (check out the intro too)

IMO a more complete, or DEEP theme, makes it easier to spread best practices, makes it easier for Teams to work together, helps N00bs learn, and since it is script, is soooo easy to rip out what you don't need, versus needing to know how to add what you do need when something is missing.

I like many of your other ideas though...

--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }

I think…

JohnAlbin's picture

I'd like to propose the Basic theme

Since the Basic theme was branched from Zen (~June 2008), there's been 7 pages of CVS updates to Zen and very little done to Basic.

Basics [has] more intuitive source order.

Basic just takes the navbar and puts it in the header, so the source order becomes: header, navbar, content, left side, right side, footer. Zen uses: header, content, navbar, left side, right side, footer. Zen's order is a better source-ordered arrangement and is better for SEO. Basic's order is easier to grok. But this can only be called a failure of Zen's documentation to fully explain how the navbar positioning works. My fault! I've given a couple Keynote presentations and I always see lightbulbs going off and "Holy crap, that's awesome!" comments when I talk about how it works; I just need to convert my presentation into handbook documentation. :-(

Consolidate the stylesheets, i.e. help mitigate stylesheetitis and IE7's 31 stylesheet limit

A couple of points here. 1. There's already a patch for the "IE 31 stylesheet limit" in D7's queue, so that shouldn't be a consideration here. 2. Consolidating stylesheets is the wrong direction. Granular stylesheets allow sub-themes to very easily knock out just the parts they don't want. We should take advantage of that modularity that Drupal provides us. Because it allows as to put a little more into core knowing that sub-themes can nix the bits of their choosing.

Beef up the templates…

We need to find the right balance, for sure. The most themable website is the CSS Zen Garden, but that is super heavy HTML. I prefer (not surprisingly) Zen's approach of a single wrapper div for each positioned div. Just that one wrapper div makes getting complex designs applied 1000% easier, IMO. And I can always override the tpl.php if I need something different.

Follow sun’s recommendation and be more specific with class names…

+1000!!! I think many of core's current style/classes are too generic. For example, the table styling is only needed in the admin section.

Build a set of canned layouts […] left/centre/right, centre/left/right etc

I think core should just have a simple fixed/fluid choice. But we should definitely build out a full suite of layouts, like those you mention, that we should make available during the theme contest.

  - John (JohnAlbin)

  - John (JohnAlbin)

...

jeff1970's picture

All good points John.

I think what I'm driving at (more so than simply strait-out using Basic) is the idea of using Zen derived tpl's and layout methods, which having been in use for quite a while and power many thousands of sites have stood up to the test.

a patch for the "IE 31 stylesheet limit"

I've been loosely following it, wasn't sure if it was getting anywhere, will be great if this thorny issues gets solved.

I prefer (not surprisingly) Zen's approach of a single wrapper div for each positioned div...

Yep, for sure, gives plenty of options.

just need to convert my presentation into handbook documentation

That would be great, I know how to use it, but many don't get it, I've been meaning to help you out on this for a long time (with some docs for it) so my bad also :(

we should definitely build out a full suite of layouts...

Yea, and these can live on in the documentation and subthemes/contrib or where-ever they will live after the contest ends.

Good stuff.

delete dupe

HansBKK's picture

delete dupe

Zen makes it easy for

SeanBannister's picture

Zen makes it easy for themers to get a clean theme that is free from all the extra Drupal CSS that confuses themers because they have to untheme it. When I started themeing Drupal this ability to just duplicate Zen's STARTERKIT and automatically have a clean theme made it very easy.

If we created a few nice themes based on Zen users who were new to themeing could just copy one of these themes and make their changes. Or users who were more advanced could start with a clean theme using the STARTERKIT. I think this is the best of both worlds, beginners get themes that are easy and ready to go and advanced users get all the goodness of the more advanced features in Zen.

+1 for ZEN or something close to it

HansBKK's picture

I've been following for a while and have been surprised this hasn't been more front and center.

I know some themers say they don't like the Zen "way of doing things", but there are always going to be differences, and people at that level have the skills to do whatever they want anyway.

My perception is that Zen already covers most of the bases. It's already "deep", in the sense of covering the feature set and being suitable as a well-structured base, the pretty-for-marketing aspects is easily covered with a specific sub-theme enabled by default.

As far as the "light" aspect goes, I'm not sure I understand it - I don't think it's feasible to have something that isn't full featured AND easy for newbies to grasp AND suitable as a base for when they do come to grips with theming. Or if it's possible why wouldn't it just be another subtheme choice?

If there are well-understood mainstream issues with Zen then let's get them worked on rather than re-inventing the wheel, there's really something to be said for continuity, not making the less-wizardly members of the community figure out a whole new paradigm every major release, incremental (doesn't mean "minor" or "slow") improvements to something with a huge installed base is IMO the way to go.

I totally agree. Zen's been

SeanBannister's picture

I totally agree. Zen's been around for more than 2 years and the Drupal 6 release of Zen made some great improvements, it's really well documented and commented and already has a large support base. I'd really like to hear from Jeff Robbins or John Albin who created Zen to see what they think about this.

Another +1 for zen

flickerfly's picture

Zen already has a significant following, history, documentation and has already been working on getting more subthemes available to users. It is in active development and has support from mant in the community. It is easy to pick up and theme for someone with CSS knowledge without custom manipulation of the tpl.php files.

Really serious themers will find their own solution to the mix and many will deviate by installing their own themes. I think we should target the people who are not yet familiar with drupal. Zen enables these people through documentation.

I would like to see improved class names added as have been mentioned above to Zen.

Would like to offer my help and my "Tendu" theme

tombigel's picture

I've created a general, light, cross-browser, RTL ready (and soon to have subthemes) theme called Tendu that is widely used by Drupal developers for BiDi sites and is formaly supported by Drupal Israel.

btw - I think that a base theme should be well commented and documented, easy to change, and automatically handle 1,2,3 columns designs.
No need for modules and what not to control the design, it becomes all too "Design view"-ish and has too much potential to eventually complicate and break things.

Can't wait for the theme competition.

Tom B.

RTL

jeff1970's picture

I've looked at the RTL in Tendu and its very well supported, I think RTL is important also. Your input in this area could be valuable. Not sure the sidebar flipping is 100% required (again, your input needed) but certainly inclusion of rtl ready stylesheets with at least the basics covered and perhaps some examples of how to get this working. The principals are pretty basic, we just need to make an effort.

That said, afaikt this is only really important if we start messing with right/left paddings/margins in the base theme (am I right/wrong Tom) or want to flip the sidebars.

Maybe its not so important for the contest? We can engineer this in to the winner?

Sidebar fliping in RTL

tombigel's picture

Sidebar flipping is a must because the direction of the entire page changes not just the text. You read form right to left so menus should be on the right etc.

This is actually an issue that should be discussed - the terms "sidebar-left" and "sidebar-right" are problematic in BiDi sites because when flipping direction the right sidebar becomes the left one and the left sidebar becomes the right sidebar and it causes some confusion.

I thought about changing this terminology in Tendu to something more general like "sidebar-first" and "sidebar-second" or "sidebar-primary" "sidebar-secondary" but decided to stick to the convention for now.

Anyway, since RTL is now implemented in Drupal core and we even managed to get Garland to fully support RTL in D6, a default theme should support cross-browser RTL by default.
RTL is not as easy as it seems because when you switch the page direction you open a Pandora box of new bugs in many browsers, though it's not that hard to overcome if the theme CSS is done right.

btw - I eventually created Tendu because Zen has some serious issues with RTL. Some of the techniques it uses like negative margins to float the sidebars needs some overrides and browser specific code (IE of course, but FF2 and Opera has some frustrating RTL bugs too) and there was a need for an out-of-the-box RTL solution.

Anyway, my RTL knowledge is at your disposal if needed.

flip the content?

jeff1970's picture

Sorry if I am taking this discussion off on tagent, please forgive me this one quickie:)

Cant we just flip the content, rather than the presentation? For example;

<div id="sidebar-left">
  <?php if ($language->dir == 'rtl') { print $right; } else { print $left; } ?>
</div>
<div id="sidebar-right">
  <?php if ($language->dir == 'rtl') { print $left; } else { print $right; } ?>
</div>

This is what I am considering doing for my themes, saves me having to duplicate a lot of CSS in layout-rtl.css etc.

Can you see any major drawback in this, I just thought of it so no deep thinking or testing etc.

Your solution will work if both sidebars look the same

tombigel's picture

But think of a case when the sidebars have different appearance (different background or different width for example), or when you need to address a block in the CSS with #sidebar-left .some-block{} for some reason (overriding, or poor server side programing that you have no control over as a client-side developer in a project).

So you solved a need for CSS overrides and created a slew of others...

Another side effect is that when you flip the content like that, you change the order of the content and can break the accessibility of a page (for example - moving the navigation menu to be the 5th block instead of the first one).
Though now when i think about it, this can be solved with this approach:

<div id="sidebar-<?php if ($language->dir == 'rtl') { print "left"; } else { print "right"; } ?>" >

These are all issues that can be solved one way or another, but my approach to RTLing a page is that the direction of the page is pure visual and should be achieved with CSS only and without tocuhing the code (accept for calling *-rtl.css files of course)

first/last instead?

stephthegeek's picture

When researching bidirectional site best practices for the amnesty.org theme, I found the recommendation to use "first" and "last" in class/ID names rather than "left" and "right", eg. sidebar-first. Then you're never wondering if "left" is the visual left or language left, and no code needed to swap names around.

I like Tendu

David Latapie's picture

Since Tendu is sort “Zen, but better” I see it as an excellent starting point for a new default theme. On the other hand, the Acquia-Slate theme is worth considering too. A way to mix both?

State of Basic

couzinhub's picture

I jump in the conversation just to clarify some aspects of BASIC (which I am one of the two maintainer, with S. Krueger). As opposed to ZEN, Basic wasn't developed to be the starter theme that most people should use to start its new Drupal theme.

I have been theming with ZEN for quite a while now, and I really loved the great improvements that ZEN's developers brought to drupal theming. But as our projects got bigger and more complicated, it became sometimes confusing to work as a team on such a sophisticated starter theme, and the chances of confusion were getting bigger for us, due to the amount of files/code that ZEN is using.

It felt like ZEN was providing us too much options, and it became too complicated for us as our development process was sometimes pretty heavy.

So we decided to create a very simple theme that would not have a sub-theme function (as we just develop themes that are unique for each client), and that would really have the strict minimum, with only some of the nice features that ZEN was including, and adding some of our own that we always end up using. So of course, it might be a bit 'empty' for a beginner, but we didn't built it for beginners, we built it for people who already know how to theme drupal, and who might not need all the help that ZEN is providing.

If it is your first theme, use ZEN, but if you know theming well, you might prefer to use Basic.

Also, it is true that ZEN has been more worked on than Basic, but remember that Basic has only been released in June 2008... it is only 4 month old ! We keep improving it as much as we can, but we can't say that it is as mature as ZEN, that has been created in ... 2006 !

... and to answer Mike Stewart that was starting his post by "Zen is smaller than Basic" , it might be true that the template.php is 2 lines longer, but I guess that might be due to the over-spacing we added, so really 2 lines doesn't mean anything (espacially if we were to remove the comments...), but I would suggest that you compare the amount of file that are in ZEN and Basic (or just the size of the 2 themes). Basic is REALLY a striped down version...

So of course, we shouldn't use BASIC as a default theme, and OF COURSE, Basic IS NOT an attempt to copy or equal ZEN, it is just another approach of drupal theming, for a different kind of users.

Cheers !

p.s. : Of course, I'd love to offer my help with the development process, I'll try to come up with some ideas or suggestions.

Zen vs Basic vs Custom: Just one user's experience

micahw156's picture

Just thought I'd share my own experience, since it seems to mirror the intent of the Basic theme.

My Experience with Zen

I started using Zen around the time that John Albin did the interview on the Lullabot podcast, so it helped me understand how and why Zen works by creating sub-themes. Zen is robust, and offers a lot of choices. It's very good at what it does, and it delivers a clean, content first layout.

I spent a lot of time getting the CSS right for the Navigation section. Chalk that up to my not being a CSS guru. I still have one site where I can't get the background color the way I want it because I don't understand the layout well enough.

Any time I wanted to "borrow" any functionality from other themes or published template.php code snippets, I had to rename and reformat everything to put them into my sub-theme so that I could keep Zen's template.php file pristine.

The problem for me is that the guts of the theme were a black box to me. I really didn't take the time to dig through and understand the inner workings of it, and if I had, I might as well have written my own theme using elements of Zen as a starting point. In fact, I had plans to do so, until the Basic theme was released.

My Experience with The Basic Theme

For the most part, I found working with Basic (applying colors, fonts, etc) wasn't much different than working with Zen. Directly hacking the theme was quicker than building a sub-theme. I didn't really mind that I was overwriting delivered values. I don't think I've ever downloaded an update to a contributed theme after implementing it.

However, I still really wanted to roll my own theme from scratch, so that I'd completely understand everything that it's doing and not be dependent upon someone else's code. Or so I thought.

Rolling my Own... or Not

I set out last night to start writing my own custom Drupal 6 theme. (I learned about this thread from Twitter this morning, so the timing is fortuitous, but coincidental.) My plan was to use the page ordering from Basic, rolling in bits and pieces from all different sources.

I started by creating a .info file and checking it out in a browser. Then I pulled in page.tpl.php from Basic, making just a few minor edits, and again examining the rendered HTML in Firefox. To make a long story short, I continued introducing additional parts of the Basic theme, one file at a time, editing each piece as I went. So it looks like I'll be using Basic as a starting point for custom themes for a while.

To me, a "starter" theme is one that can be easily understood, and that I can take each piece and implement it into my own theme. Does that make it a good default theme? Probably not. We want a default theme to look great out of the box. The down side of those themes is that there's too much to un-theme before you can apply your own look. I love the bare-bones foundations of Zen and Basic, because you don't have to undo the theme's look before creating your own.

I'm not sure how to get the best of both worlds in one theme, or if it's even possible. Maybe it's as simple as swapping in and out versions of Basic's main.css, or something similar.

Micah

Thanks for you input Micah,

SeanBannister's picture

Thanks for you input Micah, I agree that Zen does have a learning curve but I personally found it wasn't to hard to grasp it. Plus the documentation and support for Zen is really good so I found this helped a lot. And when it comes down to it I found the advantages far outweighed the disadvantages.

As already mentioned having a bare bone starter theme like Zen's STARTERKIT is very useful as we don't need to untheme Drupal. This would then be the basis for the new Drupal core themes. To me this is the best of both worlds.

The question then becomes does this starter theme use a CSS framework, and if so which one, or do we use Zen or something similar to Zen.

It's pretty rare

couzinhub's picture

@micah : agreeing 100% with your point of view. I find it sometime hard and painfull to explain the reason why we made Basic, and we kinda open pandora's box by touching the holly Zen, but I see that you totally get it.

Zen + additionnal layout

ineation's picture

So if I read well it seems that if we add a suite of additionnal layout to Zen we would have a working solution that fullthill most of our needs and we will not reinvent the wheel.

To me choosing zen would be a wise decision and an effective and fast way to have a reliable starter theme in core.

I've proposed to write a detail draft proposal in the zen task force group in order to formalize the specifications, strenght and weakness of a zen D7 core theme.
Of course other theme owners could write a similar proposal and then the decision would be made based on the comparison of these proposals ?

@John : what do you think should be done to have a formal proposal for Zen ?

Alex
www.ineation.com

The title of that article is unrelated to the content.

JohnAlbin's picture

Also, Terrance Wood shoots major holes in the study upon which this article was based.

Content-first source ordering is an industry best practice. We just need to better educate/train CSS designers how to create them.

  - John (JohnAlbin)

  - John (JohnAlbin)

Exactly, just because

SeanBannister's picture

Exactly, just because everyone does it doesn't make it right. It's reminds me of table based layouts, it works but doesn't make it right.

It's great to see this

beeradb's picture

It's great to see this discussion going so strong. I was away for the weekend, but looking over the conversation it looks like we're starting to focus on a handful of desirable features:

  • The base theme should be primarily concerned with flexibility, not eye-candy. Step 4 is for improving curb appeal, and we're not quite there yet.
  • We should avoid getting too fancy with admin options. Having a few subthemes which demonstrate the flexibility of the base theme is a better resource to designers, and likely has less roadblocks on the way to core.
  • Providing more descriptive class names for better CSS targeting is a must.
  • RTL support is important. We shouldn't undo any of the progress we've made there.
  • We should respect SEO best practice in respect to source ordering.

The main point of contention seems to be around whether a single CSS framework can cleanly provide us with the myriad of layout options required. I think for now trying to answer the fundamental question of whether or not to use an existing CSS framework is the best path forward.

Is there any way we can get a list of the pros and cons of frameworks in general? or does this really need to be evaluated on a per framework level?

Image-free, colorable (sub-)themes?

tonyn's picture

I am demonstrating a few very basic themes (cleanstate, nista, simpla, splender, spooner). They are colorable, in this case the it's pretty straight-forward since it's a single color shift.

I try to keep a demo of things over here: http://www.skiquel.com/lab/drupal-6/ (admin/admin)

I was thinking, maybe it wouldn't be such a bad idea to have something simple and color-friendly to replace pushbutton/chameleon etc. There are probably better people who would pull it off.

Lost of votes for Zen

jeff1970's picture

From the way I see it, the theme we are replacing is Bluemarine. Bluemarine has been there all along as the default starter theme - its simple, easy to get your head around, robust and easy to modify. Practically anyone could forge it into something.

Garland (and the deprecation of tables for layout) came along and buggered that all up. Yes, Garland is beautiful and IMO a fantastic theme, but people make the mistake of trying to customize it, thinking this is the default theme for Drupal and thus what they're meant to use... I see this in the forums every day - people struggling with Garland, hence we find ourselves here trying to give users something they can get started with.

Zen is the antithesis of Bluemarine. We all know both so no need to elaborate here.

IMO we should be focusing, ideologically, on the Bluemarine approach - simple, easy, barebones. Something that anyone can pick up and run with.

If that means taking the good from Zen and loosing the complexity, all good, if that means a grids based approach, lets entertain that idea. The fact remains also that we are rm 3 themes! Is there not room for simple Zen AND a grids derived "designers choice" in core? Just an idea.

Bluemarine was useful because of its simplicity, I don't think we should loose site of the fact that it made Drupal accessible for many non-designers by sticking to KISS principles.

Simple for newbies

stephthegeek's picture

Big +1 here, great comment. Not to knock Zen, but I think it's the theme for people who really want to dig into that pandora's box and learn a lot about theming -- not the theme for a new user trying to get a basic look and feel deployed.

Much like with the drupal.org redesign, we need to keep in mind who this theme is really for. If users want more in a base theme, they will seek it out. Big thumbs up on KISS!

best of both

catch's picture

I think the conversation is drifiting away from the original issue a bit.

There's no way we'll simply move Zen (or any other base theme) into core as a theme. What we'll have to do is convert modules/system/page.tpl.php and modules/node.tpl.php and all the rest to match whichever framework/base theme we decide on - then maybe add in a layout.css. Then on top of that, we can have eye-candy themes - which wouldn't even need a page.tpl.php and node.tpl.php in most cases - and with a bit of luck at least one of these would be the new Bluemarine.

The main reason for taking this approach, is because taking both markup/layout CSS and design at the same time - which moving a complete theme into core would be - is a recipe for a never ending issue of hell. This discussion is already more than 100 posts and it's only dealing with the base theme parts. If we combine markup/layout + design into one core patch, then we'll never see anything get in.

+1 for multiple base theme

MacRonin's picture

+1 for multiple base theme philosophies. In the world of designers that we are trying to attract, there are multiple philosophies on how a site should be structured. The odds of us creating a single base theme that can handle all of them in a way that makes the majority happy are slim. And we would be entering another one of those religious type wars with no winners and a lot of time and resources lost. For the long run it would probably be best to select two(or maybe three) of the basic design philosophies and create a theme base that exploits each. This way a new designer visiting DrupalWorld will find something that they already know how to work with instead of being told to change mindsets or start from scratch.

+1 for default admin theme

eigentor's picture

Even if this is not the actual topic of this thread: With so much effort going into this discussion, and the goal to do it for once and right, it is closely related.
But maybe there is not a broad consensus in the community that a separate Admin theme should be default? If a consensus would be there, the admin theme is linked to this task.

And a fixed Admin theme has the grace of not having to be customized (aaah, saves a lot of thinking...), so it just has to be done...But it would be a different discussion for this one has to focus.

Life is a process

Life is a journey, not a destination

2 more cents

HansBKK's picture

I think some people are confusing different issues. Here's my take on the audiences and their needs:

  1. Basic newbie checking out Drupal, (thinks he) wants to get a basic site up and running quickly, doesn't want to get into "theming". Should get a simple "wizard" at install time offering a selection of very nice looking choices, type of layout first, and then color schemes - and they (think they) are done. Addresses the "over Garlandization" issue, marketing concerns, ease of use and simplicity for them that need/want it.

  2. Those that do want to get into the theming process for a uniquely customized site. Need a flexible, structurally sound, fully featured, "deep" framework/base, sub-theme capabilities, most popular modules covered, etc. NOT "dumbed down", but well-documented, best practices encouraged by design.

Is there a 3?

Personally I don't think there's any reason why this can't all be handled by something based on an extended/fixed/modified Zen-type methodology and architecture. If you think Zen's not perfect, let's work on fixing/extending/enhancing it, or making it easier without losing features and flexibility.

Other than the "give me checkboxes" newbie, the critical audience to be served by the core theme is those that want to LEARN theming, and especially the large numbers who have already started climbing the (pretty steep and VERY high) learning curve with D5 and then D6. Don't force them to all learn a new theming paradigm just because core's getting a new release!

For all you already-wizardly themers, you're going to do what you want anyway, that's what contrib's all about.
All the different pros and cons re CSS frameworks, layout methodologies, that stuff shouldn't IMO be hard-coded into the structure. Give people CHOICES as to what grid framework they'd like to base their design on, or for those that don't like frameworks, then what kind of layout paradigm - negative margins or y or z - different flavors of Starterkit if you like, no reason to force these choices on. Let's have a contest for what handful of sub-theme base Starterkits will be included.

But for the foundation architecture, let's not reinvent the wheel when we've got a good foundation with a big installed base of users - continuity between versions is a HUGE part of usability, and please remember most of them don't want Drupal to take over their whole life. The whole API set changes completely, but the theming paradigm IMO shouldn't.

Very good Comment

eigentor's picture

To me Hans gets it to the point:
Two or three use-cases can help greatly to make this task manageable.
For if we don't adress them seperately, discussion can go on forever.

So, once more:

  1. Newbie with no intentions of custom theming has little or no CSS knowledge, but wants a pretty theme, more so a choice of pretty themes. Would like checkboxes to set fixed or flexible weight, Recolorability with color module, maybe change header logo and similar simple stuff
  2. Experienced Themer wanting to do fully customized Designthis person may not care about existing themes at all, for he may be creating his own from scratch (that's what I did when first using Drupal). But if he uses an existing theme to tweak, this must be very stripped down or provide a framework-like approach that makes sense for customizing. Rather complementary to Group1
  3. Inbetween the two others Person with a little CSS knowledge who wants to learn it. Will be adressed by the needs of the pro themers also, but may need a little more help. Needs even more puristic and stripped down theme, because will be confused otherwise.

Garland IMHO was an attempt to adress Group 1. Also the othewise excellent Roople Themes (Litejazz, Bealestreet, Newsflash) adress this group and that's why I gave up quickly trying to tweak them. A clear declaration of a theme as "for Themers" "for End Users" could be done and might people prevent from ever trying to tweak a Garland-like Theme again (and thinking Drupal theming is that complicated).

So how about buiding task forces: one for each group of users.
Does not solve which group should be adressed in the default theme, though :P

Life is a process

Life is a journey, not a destination

I don't understand why 1, 2

ineation's picture

I don't understand why 1, 2 and 3 could'nt be adressed by one framework such as zen.

For #2 people (expert) : you would give theme a framework with a clean and basic starter subtheme which will give them productivity. Or they will use their own framework or start from scratch...
For #1 people (beginners) : you would give theme sub-themes with fancy effects and parameters.
For #3 people (in between) : they would be able to start tuning the fancy sub-theme and learn from them and then build their own with the framework and a clean starter sub-theme...

In fact the main target for the framework is #3 people. And I guess it is a very important target...

And for the default theme ? Easy just give the choice of two install profiles in the installer: developper profile (with clean starter theme) or beginner profile (with fancy sub-theme).

Alex
www.ineation.com

Reasons

eigentor's picture

Well, to really be able to say something about it, I installed Zen (never used it) and have to say, if a framework, it might be the one of choice because it is Drupal-specific and very thoughtful and also quite slim for a framwork approach.

But still: personally I never used it and probably never will for creating a custom theme. To start with: there are about 10 css files I have to understand and what they are for, how and why I invoke them.

My approacht to basic theming I depicted here http://www.drupalcenter.de/handbuch/8821 Even if you speak no german, you will get the message: what do I really need? as little as possible.

I have repeated experience with people new to drupal who try to understand drupals templating system. They are lost every time and the general notion is transported: Drupal Theming is very hard. What are all those variables for?

You have no chance to understand it, let alone any if-Statements. While it is easy to understand for a coder, a css/Html guy/gal who hardly knows any PHP is totally apalled. But those are the people that do theming and should be attracted to Drupal instead of being frightened. So for me a simplistic theme means: as few variables in the thme as possible, ONE stylesheet, which is style.css, just a page.tpl.php, maybe a node.tpl.php.

Cause People who try to convert a pure Html Template should get a chance. If you look into a Drupal template and find but a few variables, that are self-explaining ($sidebar_left, $content $header, $tabs $footer), you may even figure it out without documentation. I think this is also what jmburnz comment about bluemarine targeted at.

You may do this with a framework, but the person working with it has to understand the framework first, which is too much for many.

Life is a process

Life is a journey, not a destination

I think it's really

beeradb's picture

I think it's really important due to the time constraints we're under we stay focused on the task directly in front of us. According to the roadmap we've laid out for this we're still on step 2.

Pick a flexible, easy to extend base theme for core. A group of Known Knowledgable Themers gets together and evaluates the pros/cons of all the various frameworks and chooses "the one" to go with.

As such we should make sure to maintain focus on achieving that goal, and not get ahead of ourselves and start talking about steps 4-8. Conversations about targeting specific groups with different subthemes, adding a theme chooser on installation, great administrative options we could add, and so forth are all great ideas - but I think we should hold off on those conversations until we've reached the appropriate step. If we don't maintain heavy focus on the task we're currently on, time WILL start becoming a big issue.

This is why I proposed that

ineation's picture

This is why I proposed that we write a proposal for every potential theme.

One wiki page per theme candidate.

For example, the Zen Task Force group could write a proposal for Zen to be the core theme.
And the same for others, if someone thinks a potential theme could be a candidate, then he can start a wiki and then others could help refining the argument.

Then we would discuss or vote against each formal proposal.

Each wiki should be structured the same way, sthg like : description, how it is structured, pros, cons, to dos, estimation of work needed, tbd...

So if you are OK, we could
* Decide on the structure of the proposal
* start creating several wiki page on this (theme development) group
* communicate on this action to get more people (first page of group or d.org)
* And maybe ask the group owner to create a specific panel for this content
* And finally in a few days launch a poll

Alex
www.ineation.com

aha

eigentor's picture

+1 for ineations proposal. Task forces yeah. I volunteer for the Zen Group ;)

Life is a process

Life is a journey, not a destination

My 5 Cents - Let's Stop and look at the BIG PICTURE.

design_dog's picture

First of all, somebody just sort of brought this to my attention, so I am a little late in the game. BUT

I HAVE to point a few things out.

Arrgh. I almost hate to say it. So far, in Drupal tradition most of the discussion has gone towards technical aspects of what should be included and I think the main thing to think about is WHAT really needs to be PROVIDED.

I think honestly, not to be difficult (honestly,) but a good idea is to step outside the box here and look at the BIG PICTURE about what is in the best interest of DRUPAL in the near future.

I really think also that this is an important discussion that core Drupal people should consider as I really believe this is a large form of Drupal Branding and "How People View Drupal."
Don't believe me??? Look what happened to Garland. Need I say more.

Iraszl was on to something when he mentioned his post on target market.
iraszl@drupal.org ^^
look above - comments regarding marketing target ^^

/** O.K. Here comes the good part. **/
Big question. What is WordPress famous for?? [pause...]

If one of the answers you mentioned was "a large amount of unbelievably excellent themes that rock right out of the box."
Then give yourself a gold star.
Gee. I wonder why WordPress is so popular? Besides ease of use which we won't get into right now.

O.K. Now let's ruin your lunch and talk about the J word. oh boy. Joomla.
As of 1.5 there are a handful of through the roof themes that people just eat up like Hot Tamales? 'member those??
That's right. Some themes are pay. What a concept. Anyway. Some or a lot - are not. But there are some pretty decent themes out there.

Although we are talking about different animals,... Outside of Drupal people often care about one thing - / Plug 'n Play.
Meaning. Install a program. Get a theme attached to it. Make some changes. See something at the end of the day.
Hopefully it looks something like a website. Yes. Eye Candy would be nice thank you very much.

o.k. SO. Maybe you say. What does this have to do with Drupal?? Well.
Actually it has a lot to do with Drupal.
Understandably the beloved Garland has served everyone well.
But it's time sadly, has come.

The truth of the matter is that you would be surprised how much people will actually choose or make a choice over a CMS based on how it looks "right out of the box."
You'd be surprised. Don't believe me?? Do a survey. I'll bet you a million bucks.
You have to realize the importance and the sort of the "first impression" it makes on people.
You want to hear somethng funny?? The Garland Theme has been the iconic "first impression" of Drupal to MILLIONS of people throughout the years.
So much so - That's it's almost become a part of the Branding.

Having said all that. If you're going to assign a "default" Drupal install theme, - It'd better be a good one! (actually the idea of install theme options sounds great!)
Anyway, what I am getting at is your install theme might just be the "next" future impression that Drupal has on people. Or maybe even the "first."
And if your GOAL is you want people to STAY AWAY from Drupal, (you know the one that everyone works so hard on with the awesome core code :-),
and I guess if you DON'T want OTHER people to choose Drupal as their CMS, or even download it, then you should:
A. Make it too complicated for anyone to get results fast.
B. Make it too plain and say "go to it."
C. Give them a theme that really has no real "use" in the real world.
D. Give them a theme that says "hey, if I modify this endlessly I just might have something."
E. Uses things like embedded graphics that are really a color coded hassle to change.
F. Actually isn't even flexible at all.
G. Has a manual with it with an Appendix.
H. Doesn't have a little Pizazz in it.
I. Is too niched somehow.
J. Hate to say it but you don't put some "cool" factor in it.
K. You bog down or increase size to the Core Drupal install.

To name a few. :-)

Now I understood that what we might be looking at is - a possible default and like before / 3-4 other install choices.
Someone in an earlier post pointed out Sky and I think that just maybe be a good candidate or something like it for one.
Also I want to point out, someone posted earlier, I was sort of impressed with Acquia Marina when I saw it.
That's is good example of an all-around appealing Drupal theme.

As for the Install Set - one might consider:

  1. as stated a starting point or blank themer based theme for one] Zen might be it (which I hate to say it but I think Zen is super awesome but at some point got kinda Over-worked at some point - I think the key out the box is simplicity along with the flexibility.)
  2. a good general purpose them with some style] Can be applied to all industries. Anything from blog to medical to music to educational. Think maybe d.o. redesign.(?)
  3. two eye-candy sort of themes that rock the socks off of most everyone] To get a good idea honestly I suggest you take a good look around at what some of the other CMS's have as options under their belt.

I almost hate to say it. But, unfortunately, people like Plug 'n Play. Or as in "Right Out of the Box." A lot of people don't have time to even want to theme or make a lot of changes.
Don't believe me?? O.K. Well, fine. Pull some parameters out of Garland and Google it one day and see how many Drupal sites their are out there that STILL are left undone or unaltered.
People want results and they just want to get a website up and running first and foremost through the initial starting gate.
After that it's a whole other ballgame.

Drupal isn't evil. I personally don't want to continue or contribute to this stigma that Drupal is the CMS with the learning curve from hell.

Drupal may just be a developers framework, but that doesn't mean that other people can't consider it as just a good old CMS. The truth is that it REALLY doesn't take a whole lot to make a nice simple functional site in literally minutes that brings value to the table to end users that want just that. Why would you push them away and send them somewhere else? Unless of course you want to add an HUGE instruction manual to your default install theme and your purpose was to chase them away.

Think about the direction of what is in the best interest for Drupal to go. Take a look around at what others have done Outside of Drupal. Think about what somebody else might want to be stuck with. And then you might just have a theme.

(In the meantime. I'll try to give it some thought or work if I can before the deadline but I did want to comment.)

/ stephthegeek also made a good comment.
"Big +1 here, great comment. Not to knock Zen, but I think it's the theme for people who really want to dig into that pandora's box and learn a lot about theming -- not the theme for a new user trying to get a basic look and feel deployed.
Much like with the drupal.org redesign, we need to keep in mind who this theme is really for. If users want more in a base theme, they will seek it out."

I think that there is a bit

ineation's picture

I think that there is a bit of confusion in the conversation.

Having a theme framework (zen or others) in core does not mean that you cannot have an eye candy theme also.

This is why I defend the idea of having a great framework, that will give productivity to themers in core. And that we build subthemes, using that framework, with great eye candy features, which will demonstrate the power of drupal features and will be used by beginners out of the box.

Again with that in core we will have a product for :
* Beginners using outstanding out of the box sub-themes (also good for marketing as it will show what Drupal is capable of))
* Intermediate being able to slightly modify some of the sub-themes
* Intermediate or expert using the framework to build new themes
* Expert using their own framework or starting from scratch

I can tell you about my experience, using a framework enabled me to build new, great looking themes very easily w/o great knowledge of CSS. Having a framework is also a good way for professional new to Drupal to start playing with the theme system. Therefore having a framework in core is good for Drupal.

Alex
www.ineation.com

possible breakdown

design_dog's picture

I think the wiki idea or / better yet /

breaking into small groups or at least a couple of people working together on a theme idea is a good one.
Thus having the ability to break down tasks and deal with the time constraints.

one or a couple of people can work on certain parts of the code / design / and others on other 'stuff.

Interface - a bit off subject

couzinhub's picture

So yes, as design_dog said it, the 'right out off the box' impression is mostly due to garland, as it is basically the first thing they see when installing their website. So what ? Garland is a great theme, and I don't think that it is time to change it.. maybe refresh its design, but I don't see where Garland could be a negative factor... in fact, I always considered it as a good administration theme, as it is by far one of the most stable theme out here, created by Acko, so guaranted super tested.

What I think could help getting away from the 'Garland only' effect, is to give the users the possibility to install an alternative theme right from the install point. When installing his new drupal site, the user would, as usual, fill the install form, and then, instead of arriving to the 'welcome to your new website' page, he could select a theme to use for his site, by selecting one the default theme, or even better, activate a 'THEME BROWSER' that would gather infos from drupal.org/project/theme and display a list with description of the themes available out there. The ultimate goal would be to have an 'INSTALL THIS THEME' link, that would do all the work... but that might be a little to much to ask... is it ?

That would give the user a quick first glance of what could be possible with his new website, and also, more important, make the user realize, that Garland is not the only choice.

By default, I would recommend that Garland stay as the administration theme though, as it is extremely stable.

With this, there would be less stress attached to the default theme set we should provide, even though I think that design_dog is in the right when he says that we need a :

1. as stated a starting point or blank themer based theme
2. a good general purpose theme with some style
3. two eye-candy sort of themes that rock the socks off of most everyone

Cheers !

Good Point

design_dog's picture

Cousinhub brought up a good point.

I know this is something that many may not want to hear .... BUT

It might not be a bad idea to consider REDOING or REDESIGNING Garland from a Branding standpoint.

Don't forget - to my understanding - core is going to have at least 2-3 themes.

Although to some might and comparably to others, might seem a bit dated - It is afterall, a huge part of Drupal's history.

When people see Garland they IMMEDIATELY assimilate Drupal.

I think possibly a real challenge would be to completely redesign Garland and make it look like something totally updated and awesome plus maybe visit it technically again? Maybe just completely REDO it with a little left over Branding?? Garland on steroids?
It may seem trivial but now is the time and somebody has to bring stuff like this up I think.

[2. a good general purpose theme with some style.] Actually if you think about it. Some may disagree but in the past, this was sort of Garlands purpose. Maybe Garland could fit the bill once again in this slot if it was totally REDESIGNED.

My only concern is that whatever replaces it. It should be pretty all purpose through-the-roof awesome. I'm not sure at this point how much theme option ability will be built in initial core / but of course at some point it would be super.

One Last Thing...

design_dog's picture

Another thing to think about.

Not to get sidetracked but Couzinhub just bought up another thing.

"When installing his new drupal site, the user would, as usual, fill the install form, and then, instead of arriving to the 'welcome to your new website' page,"

This is something that Dries has brought up before I believe (dont make me find the link.:-) Which, also, I have talked about it with a couple other people. And I think this is a good point to bring up.

Instead of typically after install complete it has the current default page it should have at least a completed page or something.

But here is a step further - I think - And I have seen it before with many apps - typically Drupal should (at least have an option) to install a General set up pages that you might find in a BASIC site.

About Us.
Contact
Story 1
Story 2
Our Work
Blog(?)

WITH MENUS ETC

Right out the box NEW PEOPLE have a small set to work with and thus giving instant results.

Other apps do that.

The only reason I mention this is it might be something someone want to think about and how it reflects actual CORE DRUPAL THEMES.

Meaning - You might want to think about how the theme might mingle in a couple of page settings / rather than how it looks in just one screenshot. or give that consideration(?)

Please stop the off topic brainstorming for now

yoroy's picture

Like catch says above:

What we'll have to do is convert modules/system/page.tpl.php and modules/node.tpl.php and all the rest to match whichever framework/base theme we decide on - then maybe add in a layout.css. Then on top of that, we can have eye-candy themes - which wouldn't even need a page.tpl.php and node.tpl.php in most cases - and with a bit of luck at least one of these would be the new Bluemarine.

We want to pick a basetheme first. Core tpl.php files will have to be reworked to match that base theme.
Big job. Needs to get done first. So far I see three possible routes:

  1. "Something ultra bare minimum, very close to what core does out of box"
  2. A drupalized version of http://960.gs, providing a css grid framework
  3. "Something like Zen"

That's not a very specific I know, but can we focus on picking the best route from these options (and not split up the discussion by starting different proposals where we risk repeating the same arguments for and against in 5 more threads)

Maybe someone can give a more informed summary the pros/cons of these 3 approaches?
(Could #2 be a subtheme of #1 for example?)

yep

catch's picture

To break down yoroy's post even more:

Do we want modules/system/page.tpl.php to provide:

  1. markup that the 960 framework can use
  2. pretty much what it does now
  3. pretty much the same as zen's page.tpl.php

If the answer to (a) is to use 960, then do we want a theme in core other than Garland, which isn't based on the framework?

If the answer to (a) is 2 or 3, do we want a theme in core which implements the 960 framework too?

Pretty much, those are the only questions which need answering for now. Once the page.tpl.php and some consensus on a layout.css/framework is there - then bringing in additional typography, classes, $variables etc. can all be done in followup patches. As can eye-candy subthemes.

leave page.tpl.php

dvessel's picture

I'm hoping to see the framework as an option to help theme designers out. The big thing about of a lot of these CSS frameworks is that it's the markup that needs to change. The style sheets involved in the framework is the constant. By using class names mixed with your markup brings forth your layout. Working within the rules of the framework should pretty much guarantee that any browser quirks should not be encountered in laying out your site.

So no, I don't see changing modules/system/page.tpl.php or Garland for that matter. The former is very useful to have that as a starting point if someone chooses not to use the framework theme. If someone wants to make a sub-theme based on the framework, they should be expected to copy it from the template provided by the theme which holds the framework or create their own. Knowing the simple style rules will free themers from wrangling with getting the page flow they want. Markup is easy; How custom styles apply to your markup can be challenging to some. I would make sure there's easy to digest documentation on how it all works.

I'm preparing the theme for everyone to try out. I should have it up by late tomorrow. I'll post it with a full list of pros and cons in another post.

OFF-topic??

design_dog's picture

o.K. Fair enough.

Then maybe someone in charge needs to clarify because according to what's at the top of this discussion page / that's what I am commenting on and thought the discussion was about - ...

/ Maybe it needs to be split up or clarified.

If this discussion IS in fact on or about /system/page.tpl.php and a layout.css/framework - then clue me in.

/ AND if it is. /

I certainly would like to hear from other people with experience with 960, because it does look cool, but have no idea yet.
It would help to get feedback on that.
Also, not to complicate, but what about blueprint css? I only mention it because I don't think it was one of the ones mentioned. It may not be a good as 960 but some Drupal dev has already been done. If anyone has got 960 experience please Chime in.

And if it is going to be based on Zen, which is not a framework, then specificly someone give details on how exactly that would work.
I got the sys page tpl and the layout.css but the question is then what all would be encompassed there or additionally if Zen was used?
A total of 2 maybe 3 files the calls and that's how the core would be based??

[2. pretty much what it does now] / I would be interested to find out how that would work and what's in there now.

ugh

design_dog's picture

Isn't the whole point to have options so that whoever wants to use drupal can decide on their own framework?
Or even upgrade when needed?
You have to be specific about what your getting at and I am not sure you want to hardcode that into system tpl or do you??
are you trying to say what do you want 7 core to be based on out the box? and what callouts its using?
and if in fact it is - for the love of the lord someone please document it this time.

Answering Catch

HansBKK's picture

Do we want modules/system/page.tpl.php to provide:

1. markup that the 960 framework can use

No, dependency on any CSS framework should IMO be optional (subtheme of a scaffolding theme like Zen?)

2. pretty much what it does now

Maybe but then why the expressed need to change it?

3. pretty much the same as zen's page.tpl.php

+1 for me

(OT opinionated waffling follows)

Include the scaffolding theme (IMO Zen) in the install (that is if its maintainers want that) even if it's not the default. But I think the default should be as compatible as possible with that, to reinforce these standards for those "just checking it out" before they actually start getting into theming.

Anything that makes it clear to people learning theming that they should follow a standardized well-maintained and supported path has to be a good thing. If the way Zen does things that aren't thought to be best practices by other leading theming experts, well then let's try to come to a consensus on those and make the necessary adjustments using the community development process; pooling efforts in this area has to also be a good thing.

Of course the already-wizardly will all do their own thing most likely from scratch anyway, they don't need this kind of scaffolding support, nor even much from core; it's the newbies and those not-yet-wizardly with theming that need this support.

The default theme will of course need to be eye candy, but there should IMO be a clear instruction to select the scaffolding theme if the user wants to make anything other than trivial modifications or to get started on learning theming, including building their own up from an "unskinned" base. The default theme should be also be re-implemented as the default sub theme of the scaffoding theme, so everyone can see that as a well-constructed example, or even use that as a starting point for their modifications if they like.

The 960 support could be another optional sub-theme, maybe the Blueprint guys could be persuaded to re-engineer theirs as such as well, maybe someone would even do a YUI? These would give non-Drupal designers familiar with these a good start on Drupal-specific design.

IMO all the themes shipping in core should be re-implemented this way, but maybe that's too monolithic for an open-source community to tolerate :) Note that the full suite of contributed themes with their myriad different approaches will still be there to give diversity of approach, including other scaffolding themes to compete with Zen and keep the task force on its toes.

PS I know it's OT, but for the non-scaffolding-based core default eye-candy starting point, ideally the beginner/evaluator who isn't going to get into theming at all will be given choices, (as close as possible to check boxes/radio buttons) for:

  • layout
  • color scheme and
  • branding/header/banner/logo style

or this last should at least be very easy for a noob to modify. I also like the idea of randomizing the default selection of these choices to reduce the thousands-of-Drupal-sites-look-the-same syndrome. Ideally there would even be a few different eye-candy styles to choose from.

OK I'll (try to) shut up now :)

+1

CZ's picture

The core themes can have editable values like:

--- default ---
* Structure (Grid - Drupal generated grid)
* Layout
* Color
* Typo
* Images

--- advanced ---
* Toggle display
* ...

PS: Collabsible theme settings (see "What is that, Mission statement?" [1]).

And then a jQuery theme editor/builder edit (only) the theme settings or maybe more. "Like firebug" Drupal7UK.

Drupal 7 should have not only one theme "Stark (or maybe also zen) is not realy a theme" [1]

[1] http://www.youtube.com/watch?v=A-T1GrJ36yU

I made a new post on 960

dvessel's picture

I made a new post on 960 with two sample themes.

http://groups.drupal.org/node/16457

Just for a completely random

jeff1970's picture

Just for a completely random bit of, albeit rather interesting, trivia:

From Oct 23 - Nov 3rd the starter themes comparison test site recorded 10 667 page views. The site was launched on Oct 22.

Around 640pv went to the comparison table, with the rest to the actual demo's. There's around 300 visitors per day looking at about 3.5 pages each.

FYI, all the themes are the latest versions, except for Blueprint, which is in active development - hopefully I'll have time to upgrade to the latest -dev snapshot in the next day or two.

Subscribing

m.linnemans's picture

Subscribe

Do not subscribe to threads

moshe weitzman's picture

Do not subscribe to threads here by posting meaningless messages. Thats common practice at d.o but not here. Your messages get emailed to many people. We have proper subscription features here.

One quick last comment

design_dog's picture

I just want to point out FWIW that again by no means, and I hope it doesn't come off that way, ever intend or never intended to dowse a bucket of water on this discussion. and I hope it doesn't seem so. if it appears that way my apologies.

I think, and I know there will certainly difference of opinion, but after thinking about it what makes sense to me is:

  1. Maybe what's a good idea is to REDESIGN Garland. Call me crazy but I think it's a good idea.
    If it's done right it might actually or possibly be some kind of a starting theme or still retain some Garlandish style.
    Doesn't have to be the same but sorta like or based on Garland Just a Super Improved version.

  2. A Framework thats extensible. Whether be 960 or a grid system OR if these are lightweight enough maybe 960 and a Super light Zenish?
    I played around with 960 and I do have to admit it is super cool. And the PNG files for FireWorks are Awesome!
    Hopefully if I can I'll try to spend more time with it.

  3. 2 super awesome themes. I know this sounds bad but I think it might not be a bad idea to Look Around maybe outside the Drupal world and find out what people Best Like in a Theme or hate to say it but Get some ideas from The most popular themes for say WordPress. we can probably learn a lot. I think it should be something people really want out of the box. People will have a tendency to at least maybe choose Drupal across the board more often based on how it looks out the box.

I'm trying to pry time and I'm not a great coder but for whats its worth I'm just gonna keep workin towards it.

I think a contest might be a good idea. if their was an event or a broader way to announce it might be good. I think DrupalCon might be too far down the line, ?I don't know. It's stretchin it but maybe ya can include it like the TShirt contest? Hey why not? Wild idea I know.

dvessel did some good work with the 960 and that Grey fluid accordion demo is through the roof.

Difficult to choose between the frameworks? try Bluetrip

ica's picture

Difficult to choose between the frameworks, and than Bluetrip comes along

"BlueTrip CSS Framework.
A full featured and beautiful CSS (Cascading Style Sheets) framework which combined the best of Blueprint, Tripoli (hence the name), Hartija's print stylesheet, 960.gs's simplicity, and Elements' icons, and has now found a life of its own."

check out the demos of grid, typography
http://bluetrip.org/demos
and the code itself
http://bluetrip.org/download

As said a bit up, you can

couzinhub's picture

As said a bit up, you can now also download it here : http://drupal.org/project/bluetrip

Perhaps I'm wrong, but...

Stefan Nagtegaal's picture

Perhaps I'm wrong, but to be quite honoust I think we are all in the wrong direction here.

Offcourse Drupals standard stylesheets could be improved (together with their classes and id's), into easier to (re)use selectors. And colors need to get removed out of the default stylesheets. colours are presentation and should be part of the themes itself.

What I think is wrong (and I'm saying that for a couple of years now) is that our understanding of themes are wrong. One year ago we introduced regions into our themes, which was great. But after using that quite extensively, I am sure we are missing a step.

IMO it would be better if we could setup/configure the way our regions are displayed. So some sort of theme builder which allows us to devide our regions into rows and columns (sort of views-like, only simpler). This way it would be easier to apply a certain sort of "feel" to the site you are trying to achieve.

Some other idea I'm playing with lately is to have several layout-template files, which could be applied to one or more regions. A directory structure like this:
- layout/
- layout/liquid/1-column.tpl.php
- layout/liquid/2-column.tpl.php
- layout/liquid/3-column.tpl.php
etc, etc...

Drupals current tpl.php files just need some rethinking, with more intelligent and re-usable classes combined with well choosen id's. There is no need to adapt a CSS framework. Once rethinking the template files, you'll notice that we do not need that much to improve things and we can simply scratch our own itch by writing our very own css framework, completely crossbrowser without the need for extra hacks.

Besides all this, I think it's time for every core theme to move to the contributions repository and ship Drupal with just one theme. No matter if that is Garland, or anything else, as long as it presents what drupal is about: Rock solid, flexible and beautifull piece of work!

As the designer of Garland, I would like to say that - if people are tired of the "standard" way Garland is presenting Drupal, it is possible to have some variants on the rather clean main Garland-theme.
Or what I would rather do, is to design a complete new theme for Drupal 7, incl a complete new and advanced admin-theme. Although, this is not up to me..

I'm only saying that I would like to dedicate some time to design a new core theme, which is (more) suitable for the majority of users.. So, webchick if you want to work with or advise me on this, please feel free to contact me. I have several idea's and mockups to get started...

panels?

catch's picture

I think the theme builder you're talking about is really panels, while it's undergoing a lot of changes at the moment for the Drupal 6 port, I'd hope it'll be a candidate to replace the regions and blocks system at some point (probably Drupal 8 though at least). Of course if 960 does end up in core, I doubt it'd be difficult to add support for the framework to panels layouts in Drupal 7 contrib (or for that matter D6).

+1 for moving all the core themes to contrib - even if we shipped Drupal 7 with only Garland that'd be an improvement on the current situation.

+1 on this too

couzinhub's picture

+1 for removing all base themes except Garland from default install

...

dvessel's picture

I would love to see block regions redone but this seems to be out of scope. I'm not sure how much time we have left but if you don't mind doing so, could you create a new post with your ideas on how it would be implemented.

There are plenty of CSS frameworks out there so I don't see the point of creating one from scratch right now. I'd certainly have no problem with it if we took the best ideas and fit them into Drupal. If something completely custom was created, it better be an amazing framework. :)

The framework should be discrete though and not tied to any particular system for block presentation in core. If there was some glue to tie it together, that's fine but the themer should have control over which underlying CSS framework is used (or not used).

About the colors set in core styles. I completely agree and would work towards that end.

Work it into the Themes

eigentor's picture

Good ideas, Stefan. Try to get it into our concept.
Changing everything though will have a hard time to find a consensus.
With time constraints and experience on how things go on in such a community effort it sure will be necessary to do it step by step - there won't be a chance to get everything one wishes for into D7, some things have to stay on the roadmap.

Have a go at 960° Grid System - it is worth the effort and may help us to lay a solid basis for whatever theme is going to be developed. And the more people have real experience with it, the more we can discuss from a common ground.

Life is a process

Life is a journey, not a destination

Should we consider Chrysalis

recidive's picture

Should we consider Chrysalis as a candidate for a new core theme?

I did this with core in mind. It's very lightweight and has a clean code.

Also, as this is an early project, changes can be made easily. I'm open to ideas to improve this, and I volunteer to make this match core standards.

See the demo site.

What I like about what

caroltron's picture

What I like about what you've done with Chrysalis is how the page.tpl.php is very approachable to a newbie in Drupal theming. However I don't think it delivers as good of SEO as Zen does. One of the best things about Zen is its layout method. It actually prints the navigation and sidebars (both secondary content) after the page title and $content. This means that Google is always reading the most important bits first, which is important for search engine ranking. Extensive amounts of documentation have been added inline to assist through the modification of these layouts.

I do think that Zen can be made more approachable, in the same way that we see here with this theme. Zen gives you a lot to work with and I think our goal should be to give the new themer to Drupal "hints" at working out the CSS and help them modify the theme without ever having to fiddle with the page.tpl.php - which truthfully scares off a lot of non-php guru people.

-cc

-cc

The best of all the frameworks...

langworthy's picture

I'm super excited to see Bluetrip now offered in tasty Drupal form.

A full featured and beautiful CSS (Cascading Style Sheets) framework which combined the best of Blueprint, Tripoli (hence the name), Hartija's print stylesheet, 960.gs's simplicity, and Elements' icons. BlueTrip gives you a sensible set of styles and a common way to build a website so that you can skip past the grunt work and get right to designing.

Quite a few comments here about CSS frameworks. This one seems to take the very best from all.

To Get in Core it Needs to be an Example to Emulate

mgifford's picture

It could very well be that Bluetrip is the framework theme of the future, but it's critical that anything that goes into core validates against xHTML Strict 1.0 and CSS 2.1. In evaluating a number of Drupal themes for basic validation, I was surprised to see how many I looked at really didn't look like much when you just turned them on. There are a few like the Scruffy theme that leap out as being not just a Drupal site and visually interesting, but so many are just a framework. Would be great if people after installing Drupal 7 could flick about on a few themes and go wow!

Less than a month ago WCAG 2.0 was released. In the past week I've had two RFP's asking for a site with WCAG 2.0 Level A compliance slip across my desk. It's really time that at least one if not all Drupal Core themes are heavily tested for accessibility issues. In this regard the Flexible theme I think is the current winner. I still need to do more investigation of this theme, but it's pushed several theming elements further than the others I've examined.

Also, related to the accessibility front, probably should bundle a mobile theme. Not exactly sure when we'll see Drupal 7 have the majority of Drupal installs on the net, but we can all be pretty confident that when that happens browsing sites with mobile devices will be even more common than it is now.

OpenConcept | CLF 2.0 | Accessibility

D6 out of the box themes with validation

peterx's picture

You can see D6 themes with out of the box settings at http://d-theme.com/ with their validation results. Many of the base themes/frameworks look like rubbish and do not have demonstration themes to show what they could look like. Their evaluation should include a demonstration theme to show how much work is required to make them useful.

Some of the themes with very good demonstration subthemes do not validate because the framework is flawed. Given the very small number of flaws in some frameworks, I believe we could help some of those themes clean up their act before submitting them to a competition.

The next decision is CSS 2.1 or CSS 3. If D6 aims for CSS 2.1, D7 probably should aim for CSS3 as CSS 3 will be implemented in all major browsers during the life of D7. Perhaps a base theme for 2.1 then a subtheme for CSS 3 adding rounded corners to everything.

The next step that would help is a naming convention. Something as simple as the outside div on a page has dozens of different names across the 300+ themes currently listed for Drupal (D-theme has over 360). I suggest the id derive from the .tpl file. page.tpl.php added divs named page, page-b, page2, page-956, etc. Users would then know that anything with an id of page or page-* is from page.tpl.php. This would be a Good Example® (:-))

Another good example would be the multiple container approach for horizontal and vertical centering. Using <div id="wrapper"><div class="add-some-space"><div id="page"> is a Bad Bad Example. Setting an example of <div id="page-3"><div id="page-2"><div id="page"> or equivalent makes more sense. When there is one div, it has a standard name. When there are two divs for horizontal centering, one of the divs is the same and the other is predictable. When there are three divs for vertical centering, two are the same as the previous case and the third is predictable using the same series.

petermoulding.com/web_architect

Standard Tested Themes

CZ's picture
  1. I think, we should have a small core theme, validated by a external company.

- XHTML 1 Strict valid
- CSS valid
- WCAG 1.0 or 2.0 valid
- BITV valid (german) [2].

  1. Theme Standards

- A directory "css/"
- reset.css
- typo.css (or type.css or text.css)
- forms.css
- tables.css
- navigation.css (or menue.css or tabs.css)
- base.css or style.css or grid.css
- colors.css
- print.css
- hacks.css (or ie.css or opera.css)

  1. The Genesis is a good theme for the drupal core http://drupal.org/project/genesis but use for example no tabindex for a skiplink to the content [6] (see [1] [2] [4])

  2. Yes. Remove not accessible, web accessible and not valide themes from the core [5].

The Garland theme is not the best web accessible theme but better than bluemarine (tables).

The blueprint or 960 css framework are not web accessible themes (layout fix) [7], and blueprint is not a valid theme, say [5].

Take a look at:
[1] http://wob11.de (german) [6]
[2] http://www.bitvtest.de (german) [6].
[3] http://drupal.org/usability-test-university-baltimore-community-solutions
[4] Theme Builder standard theme demo http://www.zwahlendesign.ch/drupal6/ .[6]
[5] http://openconcept.ca/blog/mgifford/accessible_drupal_six_themes
[6] A example of a web accessible website: Press the key "Tab" (tabindex 1) and "Enter", you will see a skip link to the content.
[7] http://www.zwahlendesign.ch/downloads/CSS_Frameworks.html

For English Folks

mgifford's picture

Sorry Christian, but can you clarify what your German sites are designed to do? Is Bitv an accessibility test or something? And definitely would be useful to have some examples of more generic keyboard navigation like the tab/enter combination you mentioned.

The breakdown of css you provide is interesting. I do wonder if it might be a bit much given how already there are at least 5 CSS files in any given web site. Not sure if it helps themers to break it down that far.

print.css is an important distinction though as that will save us all a lot of paper and frustration in the long run.

Mike

OpenConcept | CLF 2.0 | Podcasting

BITV and WCAG

CZ's picture

The BITV test based on WCAG1.
-BITV priority 1 is like WCAG1 priority 2 (AA)
-BITV priority 2 is like WCAG1 priority 3 (AAA)

wob11.de is a alliance for web accessible communication technology

For the officially violence are web accessible websites required (Germany) say the law BGG ( Behindertengleichstellungsgesetz).

http://checkwebsite.erigami.com/bitv.html#bitv

peterx's picture

Visit http://checkwebsite.erigami.com/bitv.html then click the + button to see the US 508 and WCAG automated tests included in BITV with the BITV point equivalents. The actual checkwebsite.erigami.com test is less useful than using the Total Validator WCAG test plus the Total Validator US 508 test. Cynthia Says, another test used at D-theme.com, provides the best checklists for human testing. checkwebsite.erigami.com includes download times but the Firefox Firebug list is better. I have not find any other automated BITV validation.

petermoulding.com/web_architect

Certified templates

CZ's picture

See example a plone website [1] with a certificate level AA+. And maybe we can do this for themes.

[1] http://www.zug.ch/

subscribe

Noyz's picture

subscribing

@Noyz - please use the

moshe weitzman's picture

@Noyz - please use the myriad of subscription options after hovering over the blue Subscribe button. groups.drupal.org dooes not use the ghetto drupal.org way of subscribing. Thanks.

Correct me if I am wrong

mansspams's picture

there are three kinds of people we can think of:

a) simple folk
They don't know html/css. They don't care about framework. They want ~10 great themes out of the box. Period. Oh, colorize? Wicked! REQUIREMENTS: eye candy.

b) curious folk
They know html/css (maybe). They don't care about framework. They can/want to change some shapes and colors, but they will never design web site from scratch. REQUIREMENTS: clean, resetted, commented css.

c) uuber folk
Bundled framework? Who needs that? I can download what I want myself! REQUIREMENTS: shut the f*ck up and coffee.

So I see three categories and NONE of them cares about bundled framework. I am not suggesting there should be none, im suggesting it does not really matter. Just choose the one that is cleanest and can deliver eye candy and ...

a) theme away for simple folk,
b) leave one well marked up starter theme for curious folk and
c) forget about pros - they will survive with knife and modem.

Zen is my choice. Not that it matters MUCH.

It's been a while since I

dvessel's picture

It's been a while since I posted here and I have to agree. I wanted 960 in core but I've changed my mind. What should be in core is a kick-ass theme. The foundation it sits on should not be the determining factor.

That doesn't mean it's pointless to have a framework theme in core. All I'm saying is that a solid example should be built on top of it. Not have a framework theme for the sake of having one. I still think 960 is amazingly well thought out and I'll use it when appropriate.

I've to agree with you. The

ckng's picture

I've to agree with you. The real facts are
- user are not designer
- designer are not themer
- anything above themer can take care of themselves

The former two would constitute of 80% of users, the later could be 20% and are the one who would have commented here. So who are we targetting and what do we trying to achieve for a default D7 theme?

Users just want something they can choose that just worked and where they can customize without even touching the CSS (what is that?) Those are the 80-90% of users we're dealing with and should be the base of a D7 theme. ;)

CK Ng
forDrupal.com -we make drupal beautiful

CK Ng | myFineJob.com

Choose more

peterx's picture

I is simple folk. I want somethink what works.

Something so simple that even a manager can understand it.

I agree with your two choices. For really simple, it has to work always for everything and should be recommended as the default for administration. I suggest setting the administration theme separate to the site theme so people will always have a working admin theme even when using a new them for the rest of the site. Have warnings about using something else for administration, something about claiming your firstborn or supplying your GPS location to North Korea.

One truly weird thing about theme testing is the login page. When the brown stuff hits the fan and nothing works, example.com/user uses the broken theme instead of the trusty admin theme. Perhaps there should be an example.com/admin/user page for logging in when you cannot log in.

Then I would divide curious folk into those who want to delve into CSS and those who want to delve into PHP. The CSS delvers love a good pure CSS theme and there are several contenders for the pure CSS slot.

The PHP delvers want a really well commented page.tpl.php and a few other files. Really well commented, not /* does stuff */. I have not found a theme like that. Given that APC will be in PHP 6, comments cost nothing during page delivery. A Really really well commented set of PHP theme files would help. I would start by listing all the variables available at the start of a file or the URL of the drupal.org page describing all the variables available at the start of the script.

The other night the three contestants on Masterchef were narrowed down to two based on cooking three dishes each. The loser cooked with beer. How can you lose when you are the only cook using beer? Like many reality television shows, the results were scripted so the unrealistic results would fit the demographics the advertisers want to reach. Themes are a bit like that. When I am testing a database access module to perform a miracle on an impossibly small 386 based server with a 5 megabyte hard drive, a manager will look over my shoulder and grunt something about the look of the page then buy an $80000 Microsoft IIS based CMS because the demo looks better. The same manager will then ask me to install Windows Vista and IIS on that 5 megabyte hard drive and blame me if I fail. (There is a trick to that involving adding a screen shot of Vista to uClinux...)

Now we are talking curious folk (developers) and really really really simple folk (did I mention management) having something totally reliable for development but instantly recognizable as close to the finished product. Based on most people asking for site that look like the Ducati site or the New Your Times site or Royal Troon, we could have a list of subthemes cleverly imitating those sites and disguised as duke.info, nyt.info, rt.info etc. Given that subthemes occupy minimal space, 458 bytes in the case of some Colours subthemes, we could offer an imposing array of box-out-off themes.

petermoulding.com/web_architect

Closure

peterx's picture

$closure is supposed to be the last thing in the page but, based on a variety of page.tpl.php files, some people are using $closure in other ways. I went looking for a well documented theme and found that the default page.tpl.php file, in modules/system, has nice opening remarks listing the variables available at the start of page.tpl.php. The actual code prints $closure before the page division is closed. What is $closure for? How will our D7 reference themes demonstrate it?

Some themes use $closure to download image and Javascript files after the page is loaded. They need $closure after the page is finished so the visitor can read the finished page while the other files download. They have to make sure there is no content or white space in or around $closure because that destroys the vertical spacing of the page.

Other themes use $closure as the footer you have after the footer. They output their brag links and have to have it before the page division is closed. Surely these people could have a #footer-footer division and leave $closure for closing actions. Perhaps $closure should be renamed
$spot-to-place-file-download-references-after-the-page-is-loaded

I am experimenting in various browsers with a theme that uses 100% vertical space for small pages and the theme outputs $closure the following way. This is closest to my interpretation of $closure.
</div><?php print trim($closure); ?></body>

petermoulding.com/web_architect

why not let themers theme

prince.pangaea's picture

i am pretty new to theming, and i hope not to appear to be a fool in front of you all.
i love drupal but often find myself wrestling with the admin theme in themes i am creating.
why is that
i feel like i have to wrestle with the admin theme to make the site (as microsoft would say) "experience" better,
i would love to see an admin interface that wont put it self all over the place and "behave" like a good little drupal

Theme development

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: