As discussed in this blog post and the community initiatives page on d.o., this patch implements an ultra-minimal theme using Drupal's default markup and a bare bones .css file for positioning. Its purpose is NOT to serve as a production theme, obviously, but to demonstrate the core markup and provide a simple starting point for standards-compliant layout.

The breadcrumbs/primary/secondary links are a bit funky looking at the moment, but the layout.css file provided by EclipseGC is promising. We're hoping that the css file can be kept under 30-40 lines.

Files: 
CommentFileSizeAuthor
#84 logo.png4.26 KBJohnAlbin
#84 screenshot.png6.18 KBJohnAlbin
#83 drupal-stark-364777-82.patch3.19 KBJohnAlbin
Passed: 9326 passes, 0 fails, 0 exceptions
[ View ]
#82 logo.png2.5 KBeaton
#75 drupal-stark-171205-75.patch3.62 KBJohnAlbin
Failed: Invalid PHP syntax.
[ View ]
#61 drupal-stark-171205-61.patch3.58 KBJohnAlbin
Failed: Invalid PHP syntax.
[ View ]
#51 drupal-stark-171205-51.patch3.59 KBJohnAlbin
Passed on all environments.
[ View ]
#51 logo.png2.1 KBJohnAlbin
#51 screenshot.png5.83 KBJohnAlbin
#46 readme.patch1.08 KBRob_Feature
#46 stark_info.patch411 bytesRob_Feature
Unable to apply patch stark_info.patch
[ View ]
#45 screenshot.png5.86 KBJohnAlbin
#42 logo-dark.png3.4 KBJohnAlbin
#42 logo-darker.png2.1 KBJohnAlbin
#42 logo-darko.png1.64 KBJohnAlbin
#39 logo_bw.png864 bytesBrightLoudNoise
#39 logo_gray.png1.11 KBBrightLoudNoise
#34 Picture 1.png57.74 KBRob_Feature
#22 logo.png4.44 KBJohnAlbin
#22 drupal-stark-171205-22.patch2.15 KBJohnAlbin
Failed: Invalid PHP syntax.
[ View ]
#13 screenshot.png3.32 KBRob_Feature
#2 stark.patch2.39 KBNick Lewis
Failed: 9236 passes, 1 fail, 0 exceptions
[ View ]
#1 stark.patch1.94 KBNick Lewis
Unable to apply patch stark.patch
[ View ]
#1 Picture 6.png30.15 KBNick Lewis
layout.css_.txt324 byteseaton
README.txt527 byteseaton
stark.info219 byteseaton

Comments

Nick Lewis’s picture

StatusFileSize
new30.15 KB
new1.94 KB
Unable to apply patch stark.patch
[ View ]

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?

Nick Lewis’s picture

StatusFileSize
new2.39 KB
Failed: 9236 passes, 1 fail, 0 exceptions
[ View ]

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

eaton’s picture

That's a good question, actually. One of the ideas behind this theme is to show what you get 'out of the gate' with Drupal -- adding only a tiny bit of positioning CSS to make the sidebars fill their actual purpose.

If the system-menus.css code gets in the way... perhaps we should strip it out entirely, and leave that work up to the themes themselves?

To some extent, I'm hoping that this theme can hilight some of those kinds of issues. We've never had a way to judge the 'default' css and markup that Drupal provides, as most bugs get logged against Garland and ripple to the other themes...

Crell’s picture

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?

eaton’s picture

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?

If -- and I stress IF -- we start pulling out CSS from core modules, I agree that it should be moved to another core themes so that it can still be found by designers wanting to update their themes. In addition, I think that functionality related CSS (like throbbers, utility css for the 'draggable' UI elements, and so on) should absolutely stay in core. One of the biggest difficulties for designers I talk to is that getting rid of the nonessential stuff in Drupal's standard CSS files also nukes those really useful styles.

I'm hoping that this proposed theme can go in bare-bones, and serve as a focal point for future bikeshed discussions rather than generating one of its own. ;-) One of the toughest problems we have in pruning Drupal's CSS and markup today is that we don't really have a way to look at it "cleanly"... something like would give us a way to evaluate it without the noise, IMO.

Nick Lewis’s picture

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):

<?php
function stark_preprocess_page(&$vars) {
  unset(
$vars['css']['all']['module']['modules/system/system-menus.css']);
 
$vars['styles'] = drupal_get_css($vars['css']);
}
?>
eaton’s picture

I'd oppose including template.php overrides and similar stuff in this; the idea behind Stark isn't to provide a 'minimalist design,' but to give designers a quick ad very simple tour of what they're working with before they add their own work onto core. If there is CSS Drupal core will insert unless they override it, I think it should show up here.

I think there's absolutely a call for some 'carefully designe'd CSS only themes in core that override the messier CSS and do their own thing. I wanted stark to not even include any css files when I first suggested it... ;-)

catch’s picture

Status:Needs work» Needs review

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?

Rob_Feature’s picture

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?

eaton’s picture

Good question. The idea was to have a single entry in the theme's info file, but I think if the layout is in the theme rather than core, naming it style.css may well make sense... EcllipseGC, any thoughts?

Rob_Feature’s picture

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 :)

Status:Needs review» Needs work

The last submitted patch failed testing.

Rob_Feature’s picture

StatusFileSize
new3.32 KB

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.

eaton’s picture

Status:Needs work» Needs review

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?

Ah, no, sorry for the ambiguity. I meant that our plan was to name the file layout.css and include it in system.module. When it became clear that it would be better to put it in the Stark theme instead, style.css started making sense...

The idea is still to have NO tpl.php files, no template.php file, no images save the screenshot.

Rob_Feature’s picture

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).

eaton’s picture

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.

Yep -- I agree. Laura of PingVision argued persuasively for this and I've come to agree. 'Stark' is an info file with basic positioning in its style.css file. Does that sound good?

Rob_Feature’s picture

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.

Crell’s picture

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.

EclipseGc’s picture

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

Rob_Feature’s picture

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.

EclipseGc’s picture

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.

JohnAlbin’s picture

StatusFileSize
new2.15 KB
Failed: Invalid PHP syntax.
[ View ]
new4.44 KB

@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.

eaton’s picture

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.

It's worth noting that this 'switch' would have to disable all JS and all module JS as well, since a lot of our draggable and other progressive enhancement JS relies on styles.

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.

In my opinion, its purpose is to display the core markup and css, with as little additional styling as possible, so that designers evaluating Drupal can easily study and identify its default markup and styling. In addition, it gives people working on core a much better way to examine and analyze the 'default output' without additional theme tweaks getting in the way.

Status:Needs review» Needs work

The last submitted patch failed testing.

RobLoach’s picture

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.

eaton’s picture

This is not a proposal for a CSS framework in core, nor is it a proposal for a new default theme, so I don't think this is a duplicate. It's a specific theme with a purpose different than either of those threads.

JohnAlbin’s picture

Status:Needs work» Needs review

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

EclipseGc’s picture

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

JohnAlbin’s picture

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.

eaton’s picture

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?

I would agree. This is the "No special handling" theme, IMO, and if it is painful and ugly to deal with, it just means we need to suck it up and admit that Drupal's default HTML/CSS is painful and ugly ;)

EclipseGc’s picture

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

Rob_Feature’s picture

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.

EclipseGc’s picture

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

Rob_Feature’s picture

StatusFileSize
new57.74 KB

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.

webchick’s picture

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.

webchick’s picture

Status:Needs review» Needs work

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?

starbow’s picture

Status:Needs work» Needs review

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.

webchick’s picture

Status:Needs review» Needs work

Resetting status. :)

BrightLoudNoise’s picture

StatusFileSize
new1.11 KB
new864 bytes

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

RobLoach’s picture

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

webchick’s picture

I concur. :)

JohnAlbin’s picture

StatusFileSize
new1.64 KB
new2.1 KB
new3.4 KB

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 ]

EclipseGc’s picture

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

BrightLoudNoise’s picture

logo-darker.png looks fine to me

JohnAlbin’s picture

StatusFileSize
new5.86 KB

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.

Rob_Feature’s picture

StatusFileSize
new411 bytes
Unable to apply patch stark_info.patch
[ View ]
new1.08 KB

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.

Steven Merrill’s picture

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.

Rob_Feature’s picture

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.

eaton’s picture

I think you're right, Rob. Perhaps something along the lines of:

The Stark theme is intended to demonstrate the default HTML markup generated by Drupal core. It can be used as a troubleshooting tool to determine whether module-related CSS and Javascript are interfering with a more complex theme, and can be used by designers interested in studying Drupal's default markup without the interference of changes commonly made by more complex themes.

To avoid obscuring CSS added to the page by Drupal core and third party modules, Stark's layout.css file is minimal: at only 30 lines, it does nothing but position the default page regions properly.

EclipseGc’s picture

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

JohnAlbin’s picture

Status:Needs work» Needs review
StatusFileSize
new5.83 KB
new2.1 KB
new3.59 KB
Passed on all environments.
[ View ]

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.

EclipseGc’s picture

Status:Needs review» Needs work

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

Rob_Feature’s picture

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)

JohnAlbin’s picture

Status:Needs work» Needs review

@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’s picture

Status:Needs review» Needs work

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'm in favor of this.

That's the trick, really -- using Stark as a 'starter' theme isn't much easier than just making an .info file from scratch; its utility lies in demonstrating how little actually IS needed to start customizing things. Explaining its purpose as a demonstration, and pointing to a handbook page for more information about building a theme from scratch or adding to Stark, strikes me as an excellent compromise.

Perhaps we can get this theme and the basic README in place, and refine the mention of the handbook page/pointer to tpl.php files, and so on in subsequent patches as Eclipse mentions?

JohnAlbin’s picture

Status:Needs work» Needs review

Eaton: Jinx. You owe me a coke.

EclipseGc’s picture

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

catch’s picture

#51 looks fine to me.

eaton’s picture

I would be bold enough to set this to reviewed & tested, given its zero impact on existing code and the consensus on Stark as a first step towards future refinement. Anyone willing to set the flag?

RobLoach’s picture

Status:Needs review» Needs work

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.

JohnAlbin’s picture

Status:Needs work» Needs review
StatusFileSize
new3.58 KB
Failed: Invalid PHP syntax.
[ View ]

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.

Status:Needs review» Needs work

The last submitted patch failed testing.

EclipseGc’s picture

Status:Needs work» Reviewed & tested by the community

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

RobLoach’s picture

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’s picture

Status:Reviewed & tested by the community» Needs work

Is the point of Stark just to show you what default Drupal markup looks like with pretty much no CSS?

Yep, and it says that in the README and the Description that appears on admin/build/themes. :)

eaton’s picture

Status:Needs work» Reviewed & tested by the community

OK, this "Eaton accidentally marking things code needs work" thing is getting stupid. Sorry, that was accidental.

EclipseGc’s picture

eaton, I was wondering... :-)

Status:Reviewed & tested by the community» Needs work

The last submitted patch failed testing.

catch’s picture

Status:Needs work» Reviewed & tested by the community
EclipseGc’s picture

There IS NO php in this... help?

webchick’s picture

Status:Reviewed & tested by the community» Needs work

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?

keith.smith’s picture

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

JohnAlbin’s picture

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.

RobLoach’s picture

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

JohnAlbin’s picture

Status:Needs work» Needs review
StatusFileSize
new3.62 KB
Failed: Invalid PHP syntax.
[ View ]

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

Status:Needs review» Needs work

The last submitted patch failed testing.

JohnAlbin’s picture

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

chx’s picture

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

chx’s picture

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

RobLoach’s picture

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

EclipseGc’s picture

Status:Needs work» Reviewed & tested by the community

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

eaton’s picture

Status:Reviewed & tested by the community» Needs work
StatusFileSize
new2.5 KB

Or, just to shake things up while we wait for the patch to be committed... a MONOCHROME druplicon!

JohnAlbin’s picture

Status:Needs work» Needs review
StatusFileSize
new3.19 KB
Passed: 9326 passes, 0 fails, 0 exceptions
[ View ]

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

Re-rolled.

JohnAlbin’s picture

StatusFileSize
new6.18 KB
new4.26 KB

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

yoroy’s picture

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

eaton’s picture

Status:Needs review» Reviewed & tested by the community

I say we go with the straight-to-greyscale version (#84) and bikeshed it at a later date if we want to tweak the theme a touch. For now, that logo and the files as they stand accomplish all we've set out to do in this patch!

Changing this back to reviewed & tested to reflect the testbot's joy.

EclipseGc’s picture

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

Eclipse

webchick’s picture

Status:Reviewed & tested by the community» Fixed

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! :)

Rob_Feature’s picture

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.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dww’s picture

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.