Add a "stripped down" CSS theme to core

Here's a proper patch. My that is stark. (see Picture 6). That menu css seems to ruin the point of the patch. Stark needs to kill system css then?

Menu styles removed too (without messing anything else up at least).
[enough gotchas there that it should be gotten out of the way]

Subscribe. I am the wrong person to be doing heavy work on this (my CSS and designery skills are even rustier than eaton claims his are), but I'll sit back with pom-poms and cheer while others do so. :-)

If we remove system-menu.css, then we should *only* do so if we move it to a core base theme as menu.css. That is, I should still be able to get all of that CSS inherited in my own themes from "core", even if not from modules.

What about CSS that is is related to functionality, such as the autocomplete throbber and drop-down? Doesn't some functionality break badly if that's missing?

Here's my take:
1. Drupal markup arguably comes with a lot of *crap*. Personally, I don't mind the crap -- but I've got 3 years of writing around it under my belt.
2. The knee-jerk reaction is *clean up core* (I think, maybe, who knows... ?), but lets be real, we can't just yank all that css out from under the rug of 3rd party contribs.

Just for the menus, we themers have to work around these kind of pitfalls.

/* not to be confused with .menu ul li.expanded ,  or ul li li.collapsed of course */
ul.menu ul.menu li.leaf a {

}

Vs.

ul ul li a {

}

You can work around it, and understand it, but its not really *stark* clean. I don't know that just the *themes* are the problem. Hints the compromise of using the template.php file.

Here's how we get rid of system css (so you don't have to look at the patch):

function stark_preprocess_page(&$vars) {
  unset($vars['css']['all']['module']['modules/system/system-menus.css']);
  $vars['styles'] = drupal_get_css($vars['css']);
}

I agree with Eaton, let's leave removing core CSS files to another issue - nothing stops us adding this pretty much as is, then we can add a 'stark' component to core and argue about specifics once it's in.

Patch just needs re-rolling without template.php IMO. And we probably need a screenshot.png for the themes page no?

Is there a reason for naming the css file layout.css as opposed to style.css? As soon as we stray from style.css there will be confusion for noobs in the info file because drupal will no longer 'autorecognize' style.css (like it normally would) without it being added to the .info. I realize you may have done this, organizationally, so people can add another stylesheet and keep the 'core theme' intact...but I think this may cause more confusion than benefit. Thoughts on why this choice was made?

The idea was to have a single entry in the theme's info file..

For demonstration purposes? (ie. in order to show someone how to add a stylesheet?) Different themers are bound to have different approaches than I do, but I think understanding that style.css is autorecognized is much more important than seeing how to add a stylesheet to the theme. Most themers will most likely use that single stylesheet anyway. I guess my concern is for a noob themer grasping the basics ("style.css is autorecognized") before the slightly more advanced ("style.css is autorecognized unless you add another stylesheet to the .info, in which case it's not autorecognized...but here's how you add another stylesheet, etc...") Just my 2 cents.

but I think if the layout is in the theme rather than core...

Are you suggesting that a page.tpl.php would be added to the theme? That's what I assume you mean by layout, but I must be wrong since the whole point of this (in my understanding) is to use the core page.tpl.php...can you clarify?

BTW: As a themer, it's exciting to actually have a place to give input on something related to core...that's a rare occurrence :)

Screenshot.png for current state of the theme created per theme guide specs and attached. I don't know if it's a D7 thing, but the default logo isn't showing on my install, hence the "home" in the upper left.

As a themer, I'll say (with all my being) that the stylesheet should go in the stark theme, not in core, if at all possible. Literally 80% of the theming work I do in Drupal is overriding (sometimes dumb) core CSS. What we don't need, for sure, is MORE css to override in core, especially when it comes to actual layout and regions. It makes sense to have some core CSS for modules, but I don't think it makes sense to have page-layout in core.

A case in point: Right now, let's say I don't know there's something called #sidebar-left in the core page.tpl.php, so I name a div in MY page.tpl.php #sidebar-left. If there's no layout.css in core, that's no big deal since there's no predefined styles for #sidebar-left. However, as soon as there's a layout.css in core, I'm suddenly confused as to why "my div id" has styles attached to it. With no layout.css in core, this isn't an issue with major layout divs..."my ids" will never have predefined styles.

Basically, it avoids still more core overriding and only enables layout styles for those that click the "on button" (which will be relatively few).

As mentioned in #13 we either need to include a logo.png in the theme or, probably better, disable that feature in the info file. Right now, it's looking for a logo.png in the theme folder which doesn't exist.

The styles.css auto-default is a bug, not a feature, and there's an open issue to remove it. It wrecks havoc with theme inheritance.

#351487: Remove default values for stylesheet and scripts includes from system module

So with that going away, layout.css makes a lot more sense. With the CSS compressor putting everything into one CSS file anyway and the ease of adding additional CSS files via the info file, dumping all of your CSS into one file makes less and less sense. Zen is in the process of breaking up its stylesheets even further to make them *easier* to keep track of.

OK, this is uber-exciting.

A couple things:

1.) The idea for layout.css was that we might start observing some "Progressive Enhancement" ideals and including theme here (that was my purpose)
2.) I would argue it's MUCH more important that themers understand that how to add their own css files, and it is QUITE common to see text.css, layout.css, reset.css etc these days in themes. A simple note in the .info file explaining how to use style.css (so that they aren't baffled by the black magic) seems like a MUCH better idea to me. This goes back to the "Give a man a fish, teach a man to fish" philosophy. I'd rather we do a few things more manually (especially when it is SO easy) and convey how it works, than locking every themer to ever use our system into the idea that they can only add one stylesheet and it HAS to be named style.css
3.) which brings me to my next point. We should NOT (in my vehement opinion) exclude core stylesheets under ANY circumstances. What we should do instead is provide a drupal-reset.css that resets anything that drupal themes that we find problematic (perhaps EVERYTHING). This is kind of contrary to Eaton's desire to keep this as small as possible, however the utility of such a stylesheet would be invaluable... I don't think that it's an issue for this first commit, but if we can get such a thing under way, we could have a nicely documented css sheet that shows any themer on the planet what our default classes, etc are for all the core css stuff that they might not like, how to over-ride it, and ultimately, if they choose to use it that way, give them exactly the selectors they need to rebuild any of that css as desired. Again I think that's WAY out of scope for THIS issue, but since it was touched on, I thought I'd give my opinion.
4.) the backup to number 3 is just leave it all alone, and let the themer deal with it. Themer's are very good at altering css as desired, and this is something they WILL figure out. hijacking it so that the css isn't there is again a potential point of confusion, and I say we "kiss" method here.

Eclipse

With Crell pointing out that autorecognition of style.css and script.js is actually a bug, I completely change my previous opposition to layout.css. I think if no stylesheet is auto-recognized, then we should absolutely 'teach a man to fish" by adding layout.css and some comments in the info file.

However, in regards to the core reset, I think I'd suggest that there needs to be some clarity on what THIS theme ("stark") is trying to accomplish. I think, to take the proper direction, it should be determined whether this is a 'starter' theme or an 'example' theme. It seems like the original intent is an 'example' theme, just to see how easy theming the core html is.

If it were a starter theme, reset CSS makes alot of sense, but my suggestion would be that it would be done in a separate place, instead of in this basic layout theme, which really isn't intended to be built upon (is it?).

It's a whole other conversation, but something I've been thinking about since Drupal 4.7 is a single checkbox in the GUI that would disable all core styles...a 'from scratch' themer's dream come true.

I definitely agree that we need to more clearly define what we're doing if pursuing a drupal-reset.css file is within the confines of what we might consider here, then in a lot of ways we're really enabling people to say "This is the starting point." If that's not our objective here, then the entire conversation (excluding core themes, drupal-reset.css, GUI updates to eliminate css sheets) needs to be completely ignored.

In any event they're all out of scope for this issue. But we might be well advised as Rob_Feature mentions to more clearly define what we're doing here. Is this an example? or a starter?

And for reference, I was proposing a separate style sheet for the reset. it should not be included in the layout.

@Nick: The proper way to remove a stylesheet provided by a module is to include a "stylesheets[all][] = system-menus.css" line in your theme and NOT provide a copy of that file in your theme directory. But Stark should show all of core's stylesheets, warts and all. If system-menus.css is "screwing something up" in Stark, its a bug in the stylesheet.

I've cleaned up the layout.css. (And, OMG, I had forgotten #main-squeeze is in core's page.tpl.php! The horror!)

I've also included a logo.png and modified Nick's README.txt.

BTW, the layout.css needs to be tested cross browser. Because we can't “won’t fix” a bug report related to Stark's layout method. If its there, people WILL use it as their layout method in their own theme.

Related: #293540: New theme to include for core, where webchick proposed bringing a CSS Framework into core. Should this thread become a duplicate? Also note her notes in the Drupal 7 theme project plan.

Um, testbot? “Failed: Invalid PHP syntax.” What PHP?!?

John,

Can you explain the reasoning for putting your margins on the main-squeeze id instead of on the content class? My reasoning for putting it on the content class was that I'd like to (in another issue) have a knock down-drag out bikeshed event for all ages over what our default html output should be. And while I don't specifically see any markup "going" I definitely figured we'd end up keeping the content classes for blocks and content area. Let me know the rationale, I just wanted to hear it is all.

That aside, I think we've established that there will be no reset, no exclusion of core style sheets, or anything else of that sort here. Eaton, can we just get a final affirmation that that is the plan?

Thanks,

Eclipse

I used the #main-squeeze because that's the markup we have right now. I hate that markup, but this is the wrong issue to change it in.

The .content class doesn't wrap around everything that is inside the #sidebar-left, #sidebar-right, or #main. So tabs, titles, etc would still be bumping up against the columns next to them. I mean, that was the purpose of that style, right? Just to push each of the 3 columns away from each other slightly.

That was absolutely the intent. Thanks for covering my mistake.

Next order of business is to break this and contribute code as necessary to fix it to be as solid a layout as possible. This should NOT have a heavy price in css lines but, I've been wrong before, so all designers following this, let's try to see what extreme situations break this layout, what browsers do it wrong, and what our options are. (and whether we should fix them)

Eclipse

As talked about in IRC, anything wider than the percentage allowed in the sidebars (as an extreme example, a 500px wide image on a 1024x768 dispaly) is going to break this in IE. It causes the body to dump below the sidebar. This actually SHOULD break it everywhere, but it doesn't because Firefox is nice enough to let it slide, and it just allows the image to slip behind the body content (which isn't proper, but whatever).

Also, if you go for a very small screensize (less than 800x600) it's gonna break too (body drops below sidebar).

Now, I don't think either of these are really a concern because they're not unique to this layout. The only real fix is to use an overflow: scroll or something lame, which probably is dumb for this.. Also, I'll point out that we need to make the purpose of this theme explicit in the .info file's description:

"this theme is simply a demonstration of simple layout using Drupal's core template files. it's not intended as a starter theme."...

or whatever. By doing that, I don't think we have to worry about situations where people are doign crazy stuff with content...it's just not intended to work in that situation.

Yes, this absolutely SHOULD break. As long as intended content works in all situations, I'm fine with this particular "break". The only semi-legitimate solution would be an "overflow:hidden;" and I don't particularly like that approach either. Does anyone have a problem with leaving this this way?

Eclipse

I did my best to break this theme today and really couldn't. Tested and working in FF3, Safari, IE6, IE7 with a basic D7 install. (and to be honest I'm surprised how very usable it is without the pretty parts).

I think the only thing that is possibly worth considering is, visually, fixing the logo section. See the attached screenshot...there's a crazy amount of space at the top of this layout since nothing in the header is inline (it's all stacked, leaving alot of white space). It would totally be 'styling' (which we weren't doing) but cleaning that up and compacting it a little bit might be worth it if we wanted to give a more sane looking output. But, again, maybe that's not the purpose.

Wow, lots of great comments/reviews in this patch!

@Rob Feature: Nope. The purpose of this is to show off Drupal's default markup/styling, warts and all. :) But I'm totally cool with follow-up patches that make said default markup/styling less stupid. :)

Installing and playing around with this now.

Review:

1. README.txt and stark.info need an $Id$ line.
2. There was a lot of helpful discussion in this issue about the pros/cons to the layout approach chosen for layout.css. I'd like to see some of this captured as block of comments in the file, so that people understand when they might and might not want to use this as a starting point.
3. Could someone make a black and white version of Druplicon for the logo? PLLLEEEAASSEE? :)

Other than that, I'm fine committing this, as long as we have general consensus that this is the way to go. I feel like there are still a few people who need to be convinced here? Or is that feeling based on the fact that we definitely have follow-up patches to do to clean up the default markup?

I love this idea. I was totally surprised when I first discovered the tpl files in the system module directory. And doubly surprised that they seem more semantically worked up than any of the actual D6 themes.

Resetting status. :)

As requested in #36: Logo in black & white and grayscale, use which ever one you prefer.

Hey BrightLoudNoise! I like the gray scale logo, has some shadow bringing out the awesomeness.

I concur. :)

I was just playing with the levels in Photoshop; these 3 choices are all darker than the grayscale version above.

[Edit: For the record, I prefer a darker logo, but am fine with anything. Also, I'm hating on upload.module for flipping the display order of these attached files; you’re ruining my movie homage!!! :-p ]

my vote would be for logo-darker.png of JohnAblin's

logo-darker.png looks fine to me

Blech. Can't get D7 installed right now. So I didn't get a chance yet to aggregate the discussion and stick it into the README and the layout.css file.

Here's the theme's screenshot. I built it by taking an actual screenshot and scaling it down to 150x90 as per http://drupal.org/node/11637. But I think we should re-do it and make it like the "screenshot" Garland has.

Two new patches for the readme and the info file here. The info file simply has the ; $Id$ added, while the readme has the ; $Id$ and the following information. I'd reccomend that somehow (if not as proposed here) we tell people which are the major files that this is using to determine layout:

Unlike more robust themes, Stark uses Drupal's default templates to provide the html
layout. Some of the major layout templates can be found at:
modules/system/block.tpl.php
modules/system/box.tpl.php
modules/system/page.tpl.php
modules/comment/comment.tpl.php
modules/node/node.tpl.php

I considered adding a line about overriding, not modifying these files, but figured I'd start the discussion first to see if you all agreed that this was good for folks who would be looking at this theme.

I think this patch will do a world of good for new themers - great work, everyone!

In my experience, one of the first mistakes that most neophyte themers (and more so developers) will make is to somehow modify core, so I think that line about copying the template files to this theme would certainly be appropriate. I suppose you'll have to mention clearing the theme registry, too.

I think, as Steven mentions in #47, this can clear up some confusion about template files. However, I think we have to go back to the purpose of this Stark theme: Is it a starting point (in which we'd encourage and instruct people how to modify it) or is it a demonstration theme (where mentioning 'how to modify it' encourages people in the wrong direction)?

I thought this even with the line in John's README.txt file:

Designers wishing to use Stark as a starting point for their own Drupal theme
can add a line to their theme's .info file:
base theme = stark

This single line changes the purpose to "modify this theme". I think that line in the sand between "demo" and "starter" possibly needs to be drawn clearly in everything about this theme.

I like all of this, but the problem I see is this: This feels like it's too good of an opportunity to let slip by. :-S We have this chance to put a tiny theme that can easily double as a starting theme, and we're using it as an example, instead of giving docs on how to make it a "starter" for people.

With that in mind, can we perhaps make an informal agreement to add a few extra lines to the readme at some point in the future that will direct people to a handbook page on using stark like a starter theme? I think this would make all parties happy, and allow us to stop revisiting this particular issue. I know for me it is SOOOO tempting. :-) This way we can say exactly what we want in the README and then just have a commitment to a single line patch later that will direct users towards d.o for more information on extending it.

Anyone have a problem with this proposal? I think it would put all our minds at ease. (mine at least)

Eclipse

How about we push the "Can Stark be a starter theme?" discussion off to a follow-up issue?

For now, we can go with wording that describes Stark's current purpose (demonstration) and points people towards the Theme Guide without saying they should use Stark as a starter theme. Sound good?

New patch attached. Note: I also changed the theme description for admin/build/themes and added a new screenshot.

other than the "’"s in the patch, I am cool with this. I'll try to apply the patch later today to RTBC it.

Eclipse

I think Eclipse's approach to the starter theme issue is a good one. Maybe in the readme somewhere saying "this theme is intended as a demonstration theme, but if you want to use it as a starter theme, see http://drupal.org/xxx for a tutorial."

Might suggest again (as in my previous patch to the readme) that we include the location of the template files and their names, though. This isn't in the latest version of the readme.txt and I think it's a crucial piece to new themers to understanding WHAT template files it's using.

(funny how the CSS has only had one patch while the readme/info have been the center of discussion...to me, that means this theme idea is doing it's job)

@eclipse: That's not “’”. Its the UTF-8 character for a curly apostrophe (’). I don’t know what core’s official policy regarding typography; but its really easy to type them in Mac OS X, so my fingers naturally do them. :-p

Starter theme VS. Demo theme

In the scope of this issue, we should NOT tell people to use Stark as a starter theme. Because its layout method is only passable; and its really easy to break. Therefor, people would expecting us to fix the “bugs” when it breaks. Which I, for one, am not willing to do. Especially when there are so many more tested methods available.

In my opinion, the only thing preventing Stark form being an acceptable starter theme is a super-tested layout method.

So, let me suggest again… How about we push the "Can Stark be a starter theme?" discussion off to a follow-up issue?

@Rob: If Stark is just a demo theme (in the scope of this issue), I don’t think anyone will read any of its README.txt or layout.css stuff; they’re just going to look at the front-end in Firebug. But once we get Stark to “starter theme” level, it would be natural to have tips or “how to” info comments. And we can add the pointers to the template files then. Definitely.

Eaton: Jinx. You owe me a coke.

So, if I read this right, we've officially agreed, to unofficially agree, to consider doing work at a later time to make stark a starter theme as well through minor README.txt changes and external documentation as deemed necessary. :-)

Until such time, we will continue forward with the intent to make it the simplest "demo" theme possible.

OK, that glad that's out of the way.

I'll test this patch out in a minute here and hopefully we can RTBC this before the day's out.

:-D

Eclipse

#51 looks fine to me.

Instead of ’, could we use the HTML hex value (& #039;) or the single quote ' character?

Although I haven't had the chance to test this yet, I'd be interested in knowing how this reacts when more regions are introduced in stark.info.

Whoops! patch in #51 was incomplete. I forgot to follow all the steps in http://drupal.org/patch/create :-p

Re-rolled. Also changed ’ to ' because Firefox doesn't show patch files in UTF-8. Stupid fox.

The images in #51 are still good to go.

I dunno why this failed patching, it worked great for me.

Testing on IE6, IE7, Safari and Firefox.

Only issue I can see is an IE6 issue on the block page. All appears to work, but the block name fields are rendered incorrectly, which has nothing to do with this patch. Thus I'm marking this as RTBC it looks good to me.

Great job everyone, I'll be glad to see this make it in.

Eclipse

It might just be me, but I can't really see this being used as a subtheme as it's so stripped down. It's so stripped down to the point of being almost useless. Zen is on the right track as it's stripped to being almost useless, but gives you so much to make it a perfect subtheme. Is the point of Stark just to show you what default Drupal markup looks like with pretty much no CSS?

eaton, I was wondering... :-)

There IS NO php in this... help?

Hm. Just a thought, but perhaps it's getting gunked up on the $Id$ in the README.txt? Try prefacing it with // like we have in http://cvs.drupal.org/viewvc.py/drupal/drupal/INSTALL.txt?revision=1.71&.... I hope that's it, because unfortunately if testing bot chokes on this, I can't commit it or ALL subsequent patches would get marked code needs work.

It might also be that this gets fixed when #366193: Testbed: Deploy syntax checking fix gets deployed.

But while we're at it, could we format this README.txt like INSTALL.txt, with the CONTENTS OF THIS FILE and underlines under the headings, for consistency?

Also, there's an instance of "Javascript" that should be "JavaScript'.

I've got the patch that fixes #71 & #72 sitting on my laptop. But O'hare's wifi is demanding $7 for me to post it. And I haven't figured out how to post patches from my iPhone. :-p So you'll have to wait until I get back to Phoenix.

Wow, a $7 patch?! This better be good.

The logo.png and screenshot.png in #51 are still good to go.

I added the // before the $Id$ in the .txt file. So what else could be causing a non-PHP patch to report "Invalid PHP syntax"? http://testing.drupal.org/pifr/file/1/drupal-stark-171205-75.patch

Just so my opinion is noted, I am not fond of poor Druplicon discolored like that.

To clarify, that's my opinion and dont be bother by it, feel free to commit this.

I still like the gray scale one that BrightLoudNoise uploaded at #39 more. Has some shadow to it.

Looks like we can't commit until this is done: http://drupal.org/node/366193 :-(

Woo-hoo. chx found the problem with my patch. Missing binary files in a patch file make testbots explode!

Re-rolled.

I've updated http://drupal.org/patch/create to prevent others from trying to be tricky/dumb like me. :-p

Also, I slightly prefer the images in #51. But have no problem with the lighter grayscale logo provided by BrightLoudNoise. However, the one in #39 is too big.

Here's #39 updated to be smaller and with a matching screenshot.png.

So the minor bikeshed issue is: Do we use the images in #51 or in #84?

#51   VS.   #84

I'd prefer not altering the design of druplicon (changed contrast), but use the straigh-to-grayscale one in #84.

SWEET!, soon as this is in, let's get a bikeshed going on markup. I want to see our momentum keep us moving.

Eclipse

I asked for a big cage-match bikeshed argument in #drupal about which logo. yoroy gave the compelling argument that any of the other logos other than #84 dilute the design, and at least 3 other people agreed. And so it was done.

Committed to HEAD. Yay! :)

Sweet...I find this more of a 'watermark' of the direction Drupal is headed than anything else. Thanks for the work everyone put into this. I think this will be an outward show of support to new themers in the community when D7 is released.

FYI: This (minorly) "broke" update.module: #490562: Hard-coded list of core themes for update module is now stale (and yes, I know, #253501: Tests for update.module would be nice). ;) Just something to keep in mind when folks are adding/removing core themes. Thanks.