New core theme for Drupal 7: Corolla

Firstly, I see that you've used the Drupal wordmark. I'm not too sure if this is appropriate use of it unless you have a license. Secondly, isn't this too late for core?

I want to start tagging these D7 theme submissions so we can track them better.

Hmm, I think it may be possible for core, but not for contrib. Here's the policy: http://drupal.com/trademark

subscribe - I really like the vibrant colours on this theme.

I like the stripey footer thing and the orange for the feeds. However, I think there's a bit too much space between the slogan and the primary links. Is that just because of my vertically-challenged netbook screen?

Jarek, this is absolutely awesome.
Is "Web-2.0-y" as I'd say, and in a good way.
We created some Use cases in Paris, and this one would fit into the "social" category to me, fit well for a community page.

We had four use cases: News/Blog - Business - Social - Gallery/Portfolio.
One could as well differentiate by other measures (color vivid - calm. Elements many - few). Whatever, main thing is to cover a wide variety with the (if so) Core themes.

As for color, and as tastes are different: Basically use of color module would be much welcome.
But--- In terms of someone not knowledgable to drupal and trying to tweak a theme, it absolutely sucks. For even if someone finds the folder where the actual styles are stored and would edit it: switch the colors in the interface, drupal creates a new folder for that and all your changes gone.... well not gone, needs manual fiddling to get them back...

So the approach Litejazz and the other Roople Themes take might be an alternative: provide Folders in the theme folder, that contain images and stylesheet (well only the color styles) for the chosen palette. These are consistent and thus much easier to manage.

My personal favourite would be the best of both worlds: select or create your own palette with color module.
Then press "Freeze" - Drupal copies over the folder with images and style sheet to your themes folder, and makes it persistent.

Since this is (now that we appear to have somehow solved the problem of writing permissions to Drupal directories, or at least are into it) not doable for core I guess, we should do it in conttrib.

If the permission problem can be solved, it would even be an extremely simple module - one operation of copying files, done!

ah, and here the theme of Jarek for all to see:

Well Tabs and contextual links are intermixed a bit in some places - the concept is still very new and does not take account of every detail.

TD for layout: definitely not :) We are standards-mad. There are suficcient css-Ninjas here to solve _any_ problem. If you post your code (did you already create a project?) lots of people can help you with that. Same with color module integration - over at Jensimmons theme someone else implemented that.

The only situation where I personally use tables in layout is when I definitely need to center stuff vertically, and even this can often be circumvented.

Looks good!

A few points:
- I don't think the "Powered by" block needs styling per theme. If we're to use the wordmark, it should be throughout all core themes. I presume there's a reason why the little logo block was dropped for 7.
- What's the dropdown triangle on the Pages item? What does it do and how is it powered?
- You know having a 'Pages' item makes it look a bit Wordpress-y? ;)

> - After hovering over the small triangle a suckerfish drop down menu will show up. Just make sure that you have enabled "Show as expanded" option in menu settings.

That's not how theme menu links work -- are you expecting the user to put in the 'Main menu' *block* in rather than enable the 'Main menu' *theme feature* at admin/appearance/settings/global? If so, that's non-standard and I don't think we should do that in core.

> - I know, design was inspired by Dilectio, the most awesome Wordpress theme ever made.
That's fine, inspiration has to come from somewhere... but a 'Pages' item looks out of place on Drupal.

> Usability research showed that users were confused because there were two ways for enabling menus: either by going to theme or block settings. Users often ended up with two main menus being showed on the same page. I think there should be only one way to do this, and using blocks seems to be a more flexible option.

Then get this fixed in core first, before we confuse users even more by having themes in core that do things two ways!

jarek: Hehe I won't give up on tableless layout.

To be frank: your theme has no chance to get to core if it uses tables for layout. We are that bad :) There definitely are solutions.

Maybe I have not understood right what you want to do with flexible settings, what and where shall be flexible. Maybe a schematic drawing with blocks and regions can help, and we can depict solutions.

If you already have a usable theme, upload it here, but much better create a project page, this needs to happen anyway. We need to work on the css and code collaboratively.

Subscribing. Looks nice. Tables for layouts aren't going to make it into core, eigentor's right about that. Marking as needs work until we get some code to look at and try out for ourselves.

If you want to do the layout without tables, check out the existing Drupal theme Fervens, which is structurally identical to Dilectio.

@ Number 16 - you can use the if/else approach for this if you want to give the ability for the main navigation to be replaced, but I do not think it is a good idea to expect people to go set that menu up first time too.

Something like this:

<div class="main-links">
  <?php if ($superfish_menu):
    print $superfish_menu;
  elseif (isset($primary_links)): {
    print kiwicore_primary($primary_links);
  }
  endif; ?>
</div>

This way if there are no blocks in the $superfish_menu block, the standard primary links are shown.

Looks like a compelling theme. I like the 3 column layout, and the extra row of blocks at the footer.

subscribe.

Jacine indicated on IRC that I perhaps haven't been as urgent about this as I need to be. Here goes.

I am extremely concerned that we are heading into February, and I am not seeing fervent back and forth patch reviews on this issue. This is the surest sign to me as a core maintainer that rapid progress is happening and there is a team of people to drive this home. Right now I see no team. I see something that looks nice on the surface and a lot of comments that amount to basically "+1!".

If there is such activity happening in an off-site repo (such as github) to better facilitate collaboration, then great, but there absolutely has to be periodic patches/summaries posted here so that the rest of us can keep up with (and contribute to) the progress. Our core patch reviewers are here, not in github, and it's imperative that these reviews be tracked transparently for all to contribute to.

I am also very nervous that we will end up with 3-4 nice looking, but non-core-worthy themes because of resource allocation issues, and this whole initiative will end up getting bumped to Drupal 8. We have a very limited number of front-end developers contributing to core at all, and those people are currently stretched around at least three core themes plus whatever else they were already working on. If we don't see a huge influx of new front-end people giving reviews, I think we might need to cut our losses and try to get just one of these in rather than three. :\ I really don't want to do that, because this would be totally amazing if we could pull it off, but we need critical mass in order to do so and I am not seeing it.

So what I need to see, absolutely as soon as possible, are actual code reviews, and lots of them on this issue. That only happens when we start posting interim patches. So please let's get some code in this issue!

I am prepared to review and test this as it develops. I've loaded up the zip from #25. It is working nicely, but I see improvements available in the design. The most glaring thing is the need for buttons. I really like the layout settings. That is slick.

Can we get more opionions as to whether a table based layout is suitable for core? I'm strongly against it (and eigentor seems to agree), and I don't want jarek/others to spend a lot of time coding a tabled theme that will never get committed if others are against it as well.

This is a very nice theme, no doubt... I'm wondering, though, if it's going to be able to define 'Drupal' in the same way Garland/Minnelli did back in the days of Drupal 5.

It's not bad to think outside the box, but I think the theme would benefit from a little bit more 'Drupal-esqe' theming, with some Drupal blue thrown in, in some way or another.

It's easy to see when someone creates a quick one-off site in Drupal right now, because they all use a very readily recognizable Drupal theme. I fear that this theme, in its current incarnation, is not iconic enough to be the default (at least) core theme...

Also, just a small gripe, but could we use the open source/standard RSS icon, which almost looks identical to the icon in the theme right now? http://www.feedicons.com/

[Edit: More code review below]

I don't particularly like the idea of curvycorners.js included in the theme. That weighs in at 29KB, and adds a bit of cruft. In many ways, I think it would be a good idea to simply ditch curved corners in IE, and employ progressive enhancement instead...

I'm also not a fan of using Trebuchet MS as one of the highlighted fonts in this theme. Not only is it a Microsoft-centric font, it doesn't inspire a sense of modern beauty (in terms of web design) to me. (Just a personal thing, though).

Also, for CSS rules, you mightn't need to use div.class-name everywhere... it simply adds a ton of unnecessary cruft to the CSS rules, and is rarely needed, in terms of specificity.

For comments and code style, things vary between css files, and it would probably be good to get things more uniform (I'm thinking of poll.css and reset.css in particular). Again, in template.php, comments and code/indentation will need to follow the Drupal coding standard... http://drupal.org/coding-standards

For page.tpl.php, you might want to follow more of the conventions used in Drupal core's .tpl.php files (Zen is a good sample of this), in terms of PHP includes, if-then statements, etc. You'll also need to get rid of the tables, imo ;-)

Whoops! Didn't mean to remove the tag.

Also, if this has tables, that will not work at all (imho). One of the trump cards many in the Drupal community has used in the past year is "we no longer use table-based layouts in core" - they are non-semantic, and kind of take away from the veneer of Drupal being a beautiful platform for die-hard developers...

It shouldn't be too hard to convert from tables to semantic, though, and I would definitely help work out the bugs.

Also, setting active since there's no patch yet (http://drupal.org/node/156119)

As for Drupal-style branding, I would suggest to consider Seven, the admin theme, as defining the (new) Drupal brand and let these candidates free to define their own typical front-end look. I think it'd be much cooler to have themes that you can't tell are Drupal based at all.

Tables are a no-go, but we have experts that can help with that.

Consider moving to a real patch soon. Tweaking mockups can still be done in parallel, you will still be the art director for this theme and decide on the final look etc.

subscribe

Also, it might just be me, but I'm not a big fan of putting all kinds of layout options on the theme settings page. IMO, we don't need to give the user a ton of options about min and max width in px based on the number of columns at the moment, etc. It's just a ton of code and confusing options (confusing for non-technical users, that is) which, for the most part, won't be used.

However, if I'm alone on this, that's fine :)

> Also, it might just be me, but I'm not a big fan of putting all kinds of layout options on the theme settings page. IMO, we don't need to give the user a ton of options about min and max width in px based on the number of columns at the moment, etc. It's just a ton of code and confusing options (confusing for non-technical users, that is) which, for the most part, won't be used.

I agree completely. It's mostly just more junk in the variables table...

scribing

Regarding the font, that's subjective, I understand ;-)

And after thinking about the settings and such, it's no big deal to me, but less is more, when it comes to default/base themes. Garland is fairly simple in this regard. It has color module support, but other than that, it's easy for someone to basically add a logo and favicon, and off they go!

Code style cleanups would go a long way towards finishing off this patch, too ;-)

Once you get a patch together, I'll try to help in any way I can, especially with getting this thing tableless. I haven't had to use a table in a layout since about 8 years ago, and I've built out some rather complex designs - all using CSS and divs...

Nice theme

subscribe

subscribe.

[Edit: see below]

jarek, do not bother. This is what the others can do much faster and better. We are in the same situation like you are.
In Drupal there is a saying (learned from Mark Boultons new Website yesterday :)

"Fail fast, publicly". Or, if you have not read, read this groundbreaking Article: http://www.webchick.net/embrace-the-chaos

/me knows he sits in a mighty big Glasshouse throwing stones...

Subscribing

@jarek - please don't do any work for the next few hours. I'm re-writing the whole theme and am nearly complete.

Here's my new theme. I've renamed it to just Kiwi - hope that's ok with you. It's not done yet, but I'm embracing the chaos and uploading it early. http://github.com/dmitrig01/Kiwi

Here's a list of things I can think of right now that need to be done.
- Finish sidebar 1 theming blocks
- Theme sidebar 2
- Theme nodes with images (both user images and imagefield images)
- Theme sidebar menus
- Add footer blocks regions (see http://drupal.org/files/issues/home_0_0.png)
- Theme the footer
- Theme the pagers
- Comments
- Steal the "published by" code from bartik
- Try it in IE
- Theme secondary tabs
- Theme administration screens
- Make it work in the overlay
- Port over poll styles
- Print stylesheet
- Primary links

> Should I separate each CSS rule with an empty line? Stylesheets from core are very inconsistent about that and it doesn't seem to be mentioned in coding standards.

File a bug for that gap in the standards :)

In the meantime, I would do what the newer themes do. My own instinct it no empty line between rules though.

Zen and many contrib themes on d.org use one empty space between rules... like so:

.node h2.title {
  margin-bottom: 1em;
}

.node .content {
  padding: .25em 1em;
}

.node p,
.node ol,
.node ul {
  margin: 0;
}

The coding standards page is kind of like a neglected piece of cheese in the fridge. It's quite stale, and has never gotten much attention.

Bartik doesn't seem to have spaces

subscribing

subscribe

This discussion would probably be best to take place over here:
http://groups.drupal.org/node/14421

Maybe there is no purpose for border radius but Internet Explorer will only work with ems, so please keep them in ems.

I merged our two branches together except for the pagers, which I'll get to tomorrow. Can you make a new branch for your further changes just to make it easier for me to merge the pagers in? Thanks.

Also, it doesn't look great if you upload an image into an article and you have a user picture.

Lastly, the secondary tabs still need to be styled.

Overall, however, I think we're getting really close to soliciting a review.

Here is a demo site: http://kiwi.harmonikos.com/

jarek, with your latest commit, if someone puts 100 blocks into the footer, it will look horrible. Using my solution, they choose how many columns, from 1-3 - if they put a block into one of the bottom columns, it stretches all the way. If they put them in two, they occupy 50%. if they put three in, they occupy 100%.

I added a poll and a forum: http://kiwi.harmonikos.com/ - patch forthcoming

Also:
1) Putting templates in templates/ is not the convention.
2) Let's try to stay away from javascript.

Just my two cents.

The oversize site name looks a little rough in Windows, maybe needs some rethinking there as it really precludes even using site name unless you dont mind it looking like crap.

Contextual links are same color as background and the arrow is misaligned when active (yes very trivial but worth mentioning).

Specificity seems a bit inconsistent in places, eg

#page-wrapper ul#secondary-menu li is over specified whereas #secondary-menu li would suffice.

We have ul li {background: url(../images/bullet.png) no-repeat 0px 9px;} which will require plenty of whack-a-mole resetting to clean up menus, item lists etc etc.

Overall its a nice looking theme.

Ok, initial patch here. You'll need to add the patch, and the images are in the images .tar.gz.

Name Ideas: help yourself

freebo
swifter
freefly
connect
dinamik
pabolo

Re: the naming, let's not replicate the bikeshed that happened in #534402: Administration theme name. I say let jarek pick something (though preferably not Garland2.0, it needs to be completely different than Garland, Minnelli, Seven, and Bartik to avoid confusion), and unless it's just horrible, we go with it.

@jarek : Curious why you'd want to get the number of blocks ?

sure dude, if you need some help I can clean a lot of this stuff up, all these fiddly little things etc.

I dont see any discussion about browser testing which should probably come pretty early on, esp wrt RTL support which I think is a gimme in a core them (a must have). I could step in here and take this on also, I have a wealth of exp in RTL.

The block handling stuff is interesting, but I think you're trying to do too much for the user here.

I would say if the user wants their blocks 50% width, they can do it themselves, it's only a single CSS rule. Then they can also figure out how to make that look given the number of blocks they want in that region.

@joachim, but adding a single CSS rule isn't an easy thing to do without hacking core on a core theme. You'd have to create a sub-theme for one line of CSS. *shudder*

@ #88 -maybe propose a local.css file for all core themes? it would be a missing file from the theme directory and if someone wants to add some more css, they just drop in a local.css file.

I want to chime in here and say I don't want any of these core themes having little neat one-off doo-dad gadgets in them. For example, the Bartik feature to make the "Published on" string configurable in the UI, or what it sounds like this "Dynamic column resizer" feature is here.

It makes it incredibly confusing for end users who get used to the way one of the core themes works, then go to do that same thing on another one, and then can't find that neat little thing they played with before. It also causes maintenance overhead because changes to themes can't be made consistently throughout.

If such features are found to be useful, they should be added to core itself (like Color module) so that any and all themes can hook into them. And since Drupal 7 is closed for new features, this would have to happen in Drupal 8.

So please keep these themes to just that: themes.

@Jeff - it seems that my branch contains the latest changes, so feel free to fork that and help out with cross browser stuff and RTL support - thanks!

> I find it less confusing than having 4 separate footer regions

But as webchick says, users will find it confusing and inconsistent that core themes work differently -- to users, core themes are all part of the big 'Drupal' box, so they expect consistency.

looking good

this is a bit odd though: http://www.kiwi-themes.com/demosite-1/user/6 -> http://gyazo.com/3e0210ac0a0dfccb7f0dbec0c921418e.png

perhaps push the image down a bit? like http://gyazo.com/10225b3f25ab52474e770e4c5ed7677c.png ?

.profile .user-picture {
  margin: 3em 1em 1em;
}

or even

.profile .user-picture {
  margin: 0;
  padding: 3em 1em 1em;
}

I think it's time for another round of interim patches, to see if we can get this wrapped up by March 1.

Subscribing, greetings, Martijn

Either vars or variables is fine as long as you are consistent!

Your problem is this:

function kiwi_process_html(&$variables) {   <--- got variables
  // Hook into color.module
  if (module_exists('color')) {
    _color_html_alter($vars);  <--- so $vars is empty!!!
  }

So which one you use is a stylistic thing. See what rest of core does (which is possibly inconsistent.... :(

my first thought was, 'named after a car?' and 'isn't that trademarked?'

then i learned, in case anyone else had the same questions, "(botany) the whorl of petals of a flower that collectively form an inner floral envelope or layer of the perianth".

nice.

I'm liking it... hoping to see a patch file soon; would love to try this out on a test site and give it a whirl in my testing suite (IE6, 7, 8, FF 2.5, 3, 3.5, Chrome 4, Safari 3, 4, Opera 10). Would love to also help debug any cross-browser issues that pop up. Well, as long as it doesn't have to do with IE6!

There is no 'logout' link on any of your 'corolla' pages. The 'logout' link on the dashboard lets me get out of the administrative account but otherwise I would be stuck.

The admin toolbar is not available for other than admin users. So the test user I defined for the system can log in but not out. There was a log out button available on older version at top of header. Gone here.

Garland, bartik, and busy all have a logout element, though they may do it differently. It shouldn't have to be implemented by theme adopter though they certainly might want to modify it.

OK. After looking around their seems to be serious discussion about 'primary and secondary links' vs 'primary and secondary menus' and it doesn't seem settled to me. If Garland is the standard, then it should be done like that. I added a user-menu block to the site for now.

No need to solve that in the theme. The default installation does have the user menu block enabled, so the link to logout will show up. Would be handy to include it in the mockups of course.

I have not tried this theme yet but it looks fantastic.

@jarek

With your use of the color module patch, is the number of color schemes now unlimited or does Corolla use a lot of images as well ?

Nice Color styles, Jarek. May you provide Screenshots that cover more of the theme to see which other areas are also affected?

@jarek How much work would there be for you to port Corolla to D6 and have you considered doing so?

Nothing concrete and this simply may be personal preference, but here goes:

1. The block titles as all caps do not look too good IMO (I am using Wiondows 7)
2. The right is pretty narrow - and the text sizes seem too large for that width of column.

and a distant third:

3. I think Bartik is allowing for 640px wide images in the main content. Will they also fit in here or would the theme need to be made wider to accomodate such things?

EDIT - just a fourth aswell - the green writing on the blue background of the first block - it does not go too well. I think blue writing of such a light shade may fit better.

A * very * quick 3 minute accessibility review of the front page.

1. List of tags for articles on front page not marked up as a list.

2. Recent content is in a table with three columns, nothing is in the second and third columns.

3. There should be a Skip link to take users to the content in the sidebar

4. There should be a heading to allow easier navigation to the footer

5. Colours should be tested to make sure that they are WCAG 2.0 AA compliant

6. Do all actionable elements receive focus?
7. Is focus visually determinable?

8. Does focus follow the visual layout of the page?
9. How can administrators change the alt text for the site logo?

I am happy to give a more thorough review once these issues are corrected or commented upon.

The green hinted writing should be visible in the attached screenshot (or is it jsut my eyes?).

(as for overall theme width, I think you need to set one as too large a width does not look good, neither does one that is too narrow.)

Firefox 3.6 on Windows 7.

Just to be clear, I have not installed the zip file. I am looking at the demo site you have set up.

We're now post March 1.

I guess I'll need to bring up this situation with Dries at our meeting this week. But my feeling is that we're now > 30 days (close to 60, actually) since this new theme initiative began, and what we have to show for it are three unfinished themes. It probably makes sense to pick only one of them and focus all the community energy around it, to get it done in a timely manner. And so far, Bartik seems to have had the most mindshare/effort behind it...

@ #133 - From a purely aesthetic standpoint, I think if we could possibly push for Bartik (seems like a pretty solid base theme) and Corolla (this theme has more of that 'lickable candy' appeal), that would be best for the actual release of Drupal 7.

Heck, I might even use one of these themes for some of the quick sites I post.

For marketing purposes, a theme with some lively color in core would do well, I think. It's just a matter of getting movement on this issue. Perhaps deliver an ultimatum?

Jarek has put enormous work into his theme and complied to a lot of standards issues like throwing out theme settings for the core candidate version. It is just he has not as many people helping. So while this might be a lesson (how to get more people on board: how to get things done in the issue queue), I could fully understand if he was very disappointed. It is sure true for the Busy theme that there has been lack of action, but not for Corolla.

But isn't it an alternative to work on a checklist about what core candidate themes should deliver and set a deadline to keep, just like Jarek sais? Am willing to help working this out, as it applies to the other two themes the same. Aesthetics are hard to measure but they do not appear to be the problem. Yet the general css quality, accessibility and absence of one-off theme settings needs some standards to be defined.

Jarek has done some things that helped us: he outlined on the demo site that books, forums, polls and whatever need to be styled. Still we should make a list of all this stuff. Could be helpful for generations to come :)

I've just downloaded this and given it a quick spin.

Bugs:
- I don't see the secondary menu anywhere. No sign of $secondary_menu getting printed in page.tpl (This is a critical one.)
- the label for a multiple field in the edit box is grey text on grey background -- because FieldAPI outputs a TH for the main label above the draggable fields.
- operations on the theme admin page are in a vertical list rather than horizontal.

Some thoughts:
- how easy is it for a site admin to rearrange the sidebars to the more conventional left and right? Is the layout CSS reasonably easy to hack or override?
- everything seems REALLY BIG in this theme. Things like node links and the block margins. The block admin page especially feels massive -- I think the padding on that table needs reducing by quite a bit.

Contrib module interactions:
- admin_menu has more spacing in this theme too.
- devel's exec PHP block in the footer is too narrow. huuuuge padding on krumo output too.

re: #137

> But isn't it an alternative to work on a checklist about what core candidate themes should deliver and set a deadline to keep, just like Jarek sais? Am willing to help working this out, as it applies to the other two themes the same.

I agree completely - we need a checklist of things a theme ought to do. One very good example is secondary menu support, which both Corolla and Bartik omitted. This would help contrib theme developers too: I see far too many themes that fall over on the basics that Drupal should do out of the box.

I'm happy to help out with this. Shall we start an issue to discuss this or a handbook page?

Let's do a handbook page and reference it repeatedly.

A checklist sounds like a good place to start. Thanks!

I certainly don't want to make anyone pissed off, and do appreciate the work that's been done on all fronts, believe me. I would love to see Drupal 7 have many gorgeous themes as much as anyone else. But as a release manager, I need to balance the fact that we need to get Drupal 7 out the door, feature freeze was 6 months ago, and this new theme initiative was terribly late to get started to begin with. I noted when it began that unless we had a huge influx of new front-end developers to the core queue, we would end up in exactly the spot we're at now: where three "teams" of people who have basically worked away in isolation (and almost in competition), and now each of them are at various stages of incompleteness almost two months in. This absolutely cannot go on; we clearly don't have the resources for it, and it's killing morale.

One way or another, we need this initiative wrapped up, and it needs to happen soon. I really don't want to move all three themes to Drupal 8. I'm open to ideas.

I see little benefit in shutting down various issues and encouraging folks to koombaya together in one theme issue. this is evolution. let em battle it out. if noone is ready, thats evolution too.

To add an accessibility perspective. I have tested both this theme and Bartik, very very preliminarily. I will give a final more thorough, but not complete, audit to whatever theme @Webchick feels has the greatest chance of getting into core. I wish I could do a full audit on all three themes, but I don't have that much time to contribute right now. As everyone working on themes have the ability to ensure that their theme is accessible, I hope they aren't surprised or disappointed if I point out significant problems.

I hope I'm not being presumptuous putting my nickel in here. I have tried and played with all three themes and am very interested in seeing how they develop. But I'm new to Drupal(6 weeks) and am definitely a stranger to this country. I am looking to support a museum site. But most of the themes I see are for blogger style community sites or sites with a strong public outreach and community involvement. This organization has a larger service/backroom business outlook. So I am interested in seeing Busy go through but I can also see modifying the other 2 to my use.

Deadlines are fair in a put-it-up-or-shut-up sense but unfair in a volunteer environment where not everything is under one's control. It would be fair to make a deadline that makes sense for the whole project and it should be held to. But it wouldn't be fair at this point to make that deadline a week away.

If garland is the standard is that with or without the color module fix? The state of that project seems to be a sticking point. That one feature gives the most bang for the buck in terms of providing 'quick' customization. A long list of configurable options can discourage as well as enable.

Nice looking new theme. I just was looking at http://www.kiwi-themes.com/demosite-1/

http://fae.cita.uiuc.edu & http://wave.webaim.org both give you a clean review

http://www.tawdis.net's WCAG 2.0 review isn't quite so good:
Selection form control without grouping [H71] Fail 5 303, 307, 311, 315, 319
Structure and semantics Two headers of the same level with no content in between [H42] Fail 1 394
Use of absolute font sizes Ayuda (http://www.kiwi-themes.com/demosite-1/sites/all/themes/corolla/style.css?w) [C12,C13,C14] Fail 10 10, 178, 237, 453, 559, 655, 700, 973,

I haven't looked at these in more depth though and automated tests miss a lot.

Latest code is from #129?

Installed the latest Verison of Corolla, here are my findings:

- It could use a bit more contrast between the content section and the background. It might be on purpose it is almost the same and thus rather open without borders. But then it should be completely open and not have a border around the content area. As it is it is a bit undecided between boxed and non-boxed.

- how to handle the "Featured" block, how to enable the user to easily give the strong color to a block (without fiddling with css)? It is important to the base design, without it, Corolla loses. We face the same problem with Busy and I came to believe the best way is to make a seperate region for that, and name it in an understandable way. So someone draws a block in there: bang, strong color.

- I very much like that the blue version does not use the yellowish background (not that I don't like the yellowish). The green and orange version use it and get too similar IMHO. Working on color schemes would be a clear followup patch after committing Corolla to core, if so.

- The footer region is completely empty by default (the one above the dark closing area). As Busy and probably Bartik is facing the same problem: Maybe there needs to be one change in core to give more Control to themers:
Allow themes to put system blocks into freely chosen regions
Gonna write an issue for that, needs to happen really soon if it happens. If it is too hard to do, at least on the base install for Drupal it should be doable.
We had the problem that we wanted to put the login Block in the footer. This is simply not possible (maybe debatable if it makes sense) but it should be definable for a theme.

- The Theme is only about 930px wide. While this may be intentional to be sure to show the green line in the top, Maybe it would be a bigger gain to go to at least 960 or even more (as you got no Drop-Shadow). The 30-50 pixels you win could be a gain for the main content area, or the second sidebar

- I second Joachim in that everything is BIG in this theme. While this is sure intentional and basically makes the character of the theme (I find similarities to Magazeen http://drupal.org/project/magazeen), the design could win if you put in more hierarchy. In Detail:

* the sidebar titles are almost as big as the main node titles. Those could be smaller and also of a different color. This would also help to more clearly divide the sidebar from the main content
* Submitted text and tags are now much bigger than the copy text. While this makes for a good seperation, it is somehow a reverse hierarchy, as the main text in generally more important. It is a bit awkward reading because of this.
*Maybe the "Read more" and "X comments" Buttons could indeed be a bit smaller. Am not sure if this destroys the feeling of the theme, but it is worth a try. This size should be reserved for Submit Buttons and is a bit misleading, for those are not submit buttons.
* overall, you could move all elements down a bit on the size scale. The Page title does not need to be as big, and all other things are battling a bit for the user's attention. I guess you would still preserve the fresh and dynamic look of the theme.

All this would make a Great theme even better :)
I like the fresh look of it, the choice between two and three sidebars bring quite some possibilities, and you put a lot of love into detail, styling most any- and everything. Hey, these nifty dotted borders when one clicks a main menu item ;)

Hm this gets me to that we need more design reviews for the core candidate themes... Come on designers out there. Favorable or not, all comments help.

Tested with Chrome 4, IE 8 and FF 3.6 and looks great, for me it's ready. No issues detected.

@Jarek

Re: #125

2. Recent content is in a table with three columns, nothing is in the second and third columns.

Agreed, Drupal generates awful markup here. But I'm afraid I can't do much as a themer, it seems to be an issue with core Drupal modules.

Looks like the Recent Content block is themable http://api.drupal.org/api/function/theme_node_recent_block/7

Not a big deal, just thought I'd update you on it. The second and third columns of the table are used for links if the user has proper permissions.

@Everett

Regarding the recent content block, I had the same beef (empty cells) with this when I first saw it. I tried to fix it but unfortunately it wasn't that simple. The problem is that the block was designed for use in the dashboard by users with permission to at least one of the options (edit or delete). Due to "limitations" with theme_table(), although some might call it "by design," it's not possible to dynamically handle the number of columns each row will have. If you are interested in commenting on this issue, it's located here: #337947: Correct whitespace issue for 'recent content block' in dashboard. Note: The table part of the discussion starts at comment #204.

When you navigate from pages with one sidebar to pages with two sidebars, the width changes. This makes it look extremely inconsistent. Can we standardize between pages so it doesn't "jump" ?

Also, there needs to be a selected style in the main menu.

@Jarek

Good work on the Recent Content issue, I'll let you know if I find the answer to the conditional override question.

Hey jarek, I wouldn't call removing the intended functionality of the block fixing the problem, but since you don't have the same design requirements as Seven, maybe you can do better here. What if you add edit and delete links back, but have them displayed inside the list item, i.e. "This is my node title (edit | delete)?" Either way, you should get rid of $rows = array(); in your theme function. :)

@jarek

I would agree with @Jacine, ideally the admin functionality would remain. I think that what she suggested would work.

Small issue: the visible width on the home page differs from the visible width on other pages: the home page is wider. This may be the same issue as #156, though, as the home page has three columns on the demo site.

Updated Design review: It is very nice that you added so many color styles.
Still the fact that you color the entire top area takes away quite something from the initial charm of this theme: Especially the header region had a nice free breathing room, with the big color bar it looks a lot like other themes with conventional block-like headers. Feels a bit locked in the top.

The font sizes still are very big to me, the main text was 13 px size last time I checked. Scaling down all fonts one step would do it good IMHO.

@eigentor I agree, the colored header really takes away from the original design, be nice if there was an option for white. Fonts I think are too big and I think limit the appeal, especially the very large Links buttons which dominate teaser lists. The changing width thing is very disconcerting and looks weird, I can see that being a chief source of bug reports should that be committed to core.

This needs to be in CVS soon, Jarek doesn't need an account to get this committed, Dmitri could commit, so could several others, but this needs to be committed so we have a proper issue and patch queue.

Yes.

jarek, please don't rewrite from scratch alone. You have experts offering their help here. I strongly suggest you make a folder with the most complete version you have *now* and attach a zip here and give your ok for somebody to commit this to d.o/project/corolla. We can't keep reviewing all the bits and pieces in one single issue.

You have put in a lot of work on your own now, but to make this a real succes you will want to share it in the way that lets people dig in and help improve. I think *that* is top priority now.

BTW, I think it would be nice if someone stepped in to help get jarek's CVS application approved.

#687466: jarek [jarek]

IMO, it's a real shame that his application has been help up so long.

Oh that is unfortunate. I bumped that one to critical for a quick fix asap. Sorry jarek, didn't know about your cvs application lingering.

I reviewed the Titan code and gave it the thumbs up, lets hope this can get pushed through in the next day or two. Otherwise yeah, someone can commit it and we can get stuck in with the patches.

The CVS issue is fixed!

Jarek: go for it. Let us know if you want help navigating the add-to-CVS maze. It gets easier once the initial commit is there :)

Just like to second what yoroy said in #170 - getting this committed and opened up to the community is *the top priority*. We're here with our sleeves rolled up, embrace the chaos ;)

Jarek, color module support is one of the agreed to requirements for core themes.

Personally I would prefer if all core themes support color module so we have consistency for the end users. There are many devs here who have much experience with color module so I wouldn't worry about those issues right now, we can fix them.

I'd agree with the integration of the color module for all themes, including Seven. At the moment Seven isn't supporting it but I think it would be a lot better if it did. The constant gray is going to get a bit boring after a short while. Would be good to have an easy way to mix it up a bit.

Especially if we're pushing for more use of the color modules it's important to be aware of color contrast issues for accessibility:
#660576: Ensuring Proper Color Contrast for Garland
#740756: Ensuring Proper Color Contrast for Seven
#134359: Warn users about contrast problems when using the color module

There are some great tools to evaluate color choices.

Lets discuss Corolla here, not Seven.

Jarek: your number one priority is still to submit your stuff to CVS, not to redo everything on your own.

Sorry. I started to to see if Seven had used the color module or if it was just Seven. Some of the issues still apply in that if we are suggesting pallets then they need to be run through a contrast checker to see that we're not introducing accessibility problems.

Moved my comments over to:
http://drupal.org/node/737136#comment-2776588

@Jarek

If the design/theme cannot work with the color module then according to the requirements its not a candidate. The gradient can be removed with display properties (cheap workaround, but it works). The preview is exactly that, a *preview*, I do not think it has be an exact rendering of the full theme.

Webchick has already vetoed extra theme settings, so extra color stylesheets is out.

Ok, discussed this with Dries and the Bartik maintainers at Drupalcon.

We would like to see the first beta release of Drupal 7 on or around May 21, 2010. If we're going to add core themes, they need to be RTBC before the first beta release. That means working in all major browsers, no obvious visual bugs, and all the other stuff on this list needs to be done (or at the very least a very solid plan for completing them).

Therefore, this means the deadline for new core themes is May 17, 2010 to allow for a few days to squash any additional bugs before the beta.

Start yer engines!

Oh, good! I'm really glad you're still working on this. I was worried you had dropped off since the issue was so silent. :(

Oha, the design is quite a bit changed.
Must say that I like it overall. The Main Menu is a bit confusing (espially when you have just been using Drupal 7 and its Admin bar :P

You have completely gotten rid of the "button-style" links for add comments a.s.o.
Not so sure about this, this was giving the theme character (though I complained about them being too big)

Hey Designers, please review the changed design at the demo page http://www.kiwi-themes.com/demosite-1/

I like it a lot. Only found one minor improvement and that is that the pager could be better centered and the active page highlighted more. see http://www.kiwi-themes.com/demosite-1/node?page=2

Seconding the two comments above; a subtle difference should be made between the action links and the tags. Also, perhaps you could base pager styling off of drupal.org's styling; it looks nice.

Are you using hover for the menus? Not tested it but I think that won't work in IE6

Just tested site with IE6, the hover action does work on the upper menu (that includes Home, Forum, Book ...), but the color is off. Instead of a slightly opaque white the viewer sees a fully white color. That makes it hard to see the menu items when it's hovered.

@jarek:

I just have to convert menu-hover.png to menu-hover.gif

How do you figure? GIFs don't support alpha-level transparency, so you can't get that semi-transparency with a GIF.

There are ways to make pngs work in IE6. Either via transforms (which require hard coded urls and a height argument - height:100% works for dynamic height stuff.) or using an IE specific fix file a few of which are doing the rounds in places.

It's easy enough to add in drop-down menus via the Nice Menus module, if need be, and IE6 support means that any alpha transparency solution or drop down support would be rather difficult and/or kludgy to implement.

I think these features will have to wait until IE8 for a core theme.

Disabling all core stylesheets in a contrib theme is perfectly fine, but I can definitely see the point of not doing this for a core theme.

I'm not really sure I can agree with the points regarding maintainability at all, given that you now shifted the CSS *somewhere else* so changes for core now need to duplicated in Corolla, so afaict the maintenance is potentially duplicated for core. When I look at something like dashboard in Corolla it looks pretty much the same as in Bartik (very similar) yet the CSS is quite different and now needs to be maintained - core maintainers now will have to look over their shoulders at Corollas special casing of every core stylesheet unset by the theme.

Extend this right out over the whole spectrum and you see an issue immediately, think if something critical gets added to system.css or other, now we have think double and special case for Corolla, we have to add the fix (two different fixes likely). Granted this can happen anyway, I can see it being more work and more to think about.

Have talked to John Albin and can see the point: If we keep similar classes and IDs for the elements (which we should), disabling the core stylesheets and then writing new styles is also duplication, just done in a different way.

Core themes should not change the standards, but set them.
E.g. if someone takes your theme as a sample, but does not disable all those stylesheets, he will be surprised that he does not get a similar effect.

While this should not be a blocker for the deadline, it must be redone. Maybe two weeks time should be enough for that. Am willing to help out on it. In the end it is quite some work, but in the end not much brainwork, since you got your layout right now and only need to think about clever overwrites to keep it.

I would like to suppose that the core theme has done the core stylesheets in a clever way so they are easy to overwrite and do not twist your brain. ;)

Head over to this issue to discuss the style sheet stuff further: #794346: .element-invisible defined in CSS

Did a check of the current status of Corolla against the Core Theme Candidate Requirements http://drupal.org/node/769692
Here are the findings: http://drupal.org/node/789522#comment-2926032

Looking pretty good :)
Some bigger issues are just being solved right now (disabling of core stylesheets et al).

Reviews are very welcome, Jarek sais the new version will be online tomorrow evening. This needs quite some eyes if there shall be a chance to make it until monday.

I've installed it here as the default theme for now - http://drupal7.dev.openconcept.ca/

Looks much better from my brief review of it. Good luck on catching up on your other tasks!

I guess this needs a patch. Tarball probably will have a hard time being accepted.
As CVS is total pain for that many directories and files, creating the patch with Git should be a lot easier. Tip from dereine to make testbot love the git patch: git diff --no-prefix --no-color

The tarball from #206 works for me with IE8 and FF 3 with Vista and FF3 and Chromium with Linux without any glaring bugs. How many browsers do we need for RTBC?

I had a look into IE6 and 7.

The resizing of columns when resizing the browser window need to be fixed for IE 6 and 7 (remove fixed width
and get same behaviour as in other browsers).
There is quite some detail stuff to be fixed especially for IE6 (man, for the first time I am seeing
D7 through IE6 - this is not Corolla's fault that rounded corners are missing everywhere)
but I found nothing that breaks the layout. Mostly padding and margin stuff of small elements.
The re-turning on of core stylesheets will pay off ;) since it already adresses lots of IE stuff.

IE7 in general looks much better, only a few, easy-to-fix glitches here.

The add to shortcut link with icon now apparently appears on the frontend, too, this one is a bit
annoying and visible in all browsers.

Testbot still does not love it.
Did you use the flags --no-prefix --no-color?
Manually tested the patch applies.

As this might get buried: As to http://drupal.org/node/789522#comment-2926032 Corolla meets all requirements for a core theme.
(If nitpicking some are only at 80% :) )
Only point as mentioned is IE6/7 support must be improved which is pure CSS.

Not sure if this is enough to get this to RTBC, maybe it's webchicks call to give feedback so we know where we're at.

Is that patch a git patch? I dont get it, why cant we pull head from CVS?

Is the #206 tarbel the same as HEAD + patch?

Retrying.

The layout needs some major rethinking to get it work correctly in IE with fluid widths, especially for RTL. If you feed IE the same layout as Firefox, Opera etc it explodes in RTL and breaks in LTR as you change the width of the viewport. For starters you cannot allow fluid widths to add up to 100% in IE because of sub-pixel rounding, 2nd the trick to IE fluid widths (especially less than 100%) in RTL is to trigger hasLayout to contain the sidebars - this is not trivial and takes a lot of testing. Zen and Genesis are two themes that get this right and work beautifully in RTL. I would assume the current idea to have fixed width in IE is a work-around - not good.

Jeff if you got experience with this, help would be extremely welcome. I hardly ever do fluid layouts and only tried once to get it working in Ie6. From what you say I finally get why this is not so easy...

Well, I know its doable and I can give it a crack, but how to proceed dudes, do I grab the latest from Git or work against the RC and just dump a tarbel back here? Frankly I know zippy-do-da about Git so thats not really in my time favour to work with Git.

Update - I hacked away at this for an hour or so and got it working, still needs a small amount of love in IE6 but the big grunty stuff is done and it works - fluid + RTL all browsers. Its very rough and needs some serious love (but it works) - what do I do with it?

Jarek would you mind adding mehr as co-maintainer, too?

Hmmm, OK, well I would feel terrible about committing what I have at the moment, its very very rough, I'll need to work it again so its much cleaner. I'll try to find some more time to clean it up.

@jarek: thx :) ok so let's hit the old dreaded IE6

@jeff burnz please commit if you feal reasonably well with it. If you make major changes, I'd like to build on these, so better not to be too much off sync.

subscribing

Just did a big Bartik review: http://drupal.org/node/683026#comment-2984348 Planning to do the same for Corolla but there might be things in there that you want to check out for Corolla.

OK peps heres the commit: http://drupal.org/cvs?commit=368766

Basically I'll try to explain in a few words what this does:

1. the original layout is toast and replaced by one of my layouts lifted strait out of an existing theme (which has around 2.5 years testing and 2500 sites under its belt so I know its very solid). The layout is a negative margin layout (aka similar to Zen and ripped strait out of Adaptivetheme), we probably could get away with a standard floated layout but I know this one works very well and developing a layout from scratch is a time consuming and "testing heavy" process.

2. Original DIV id's and classes have been retained as much as possible - some have been changed such as the navigation-wrapper changed to #navigation and ul#navigation changed to #main-menu. There a couple of others to look out for, such as moving the #page DIV (see next).

3. The themes width is controlled by #main-menu, #page, #footer - these are centered and get the width values.

4. I tried to maintain look and feel (such as padding and margins etc) but you guys who have been working with this longer will understand that more than I do, I have little familiarity with the style/design so I just did my best, tweaks will be required.

5. I have brought back the footer and highlight, not sure if we can accommodate the header, I think all standard regions are meant to be included as well as a couple of extra's, not sure what the thinking is here, I would like to see a multi-column footer arrangement like Bartik has.

6. The theme is the same width no matter what sidebars are active (85%) with min and max widths as before. I very much like this fluid width concept. The sidebars are 24.5% wide, although these could be fixed? I prefer the whole theme is fluid, since Bartik is fixed this is a nice counter point.

7. The content column always expands to fill the remaining width - there is no actual width set on it (its always 100% of the remaining width after sidebars take up their bit).

Lastly, this is a total rewrite (of the layout, nothing else is touched), however as I said earlier there are several thousand sites using this layout so its been through the mill a lot already. It works in IE6/7/8, Firefox, Safari, Opera in both LTR and RTL mode which is no triviality. As a bonus this layout can actually support any sidebar configuration, so we could write some simple docs to show user how to have a standard 3 column layout or 2 column on the left (they all work in RTL also).