Theme candidate for 7 core : 960 Grid System

dvessel's picture

This post is related to the project plan to get in a few new themes into Drupal 7 core. It will list some of the pros and cons of using the 960 Grid System. If you didn't know, it's what most might define as a "CSS framework". This specific framework was created by Nathan Smith. He states that it was started before Blueprint. I have mistaken it myself as a Blueprint derivative since it is a very similar system. But they both were inspired I believe by the same sources. You can read about the background on 960 in his journal.

Now, why would we want a CSS based framework to begin with? Well, it gives web designers and developers an easy way of constructing layouts amongst other things. It does this by having predefined class names that give positioning rules and dimensions to any block level html to which it is applied. If your familiar with the idea behind the CSS Zen Garden, it is a complete 180 from that where the markup is the expected constant and the styling rules are left up to you to change.

I believe the Zen Garden is great for what it demonstrated. That the separation from markup and presentation can be achieved but it comes at a cost. Jeff Croft explains it in a short post. Pure separation is not practical. When was the last time anyone has redesigned a site with pure CSS? Everyone can agree on semantic markup. Semantic classes on the other hand should be used within reason. It helps no one but us building our sites.

Now here's a list of the pros on 960 and frameworks in general:

  • Lightweight. A hair under 5k for all the 3 styles. 3.7k for the layout styles and the rest are for text styles and a few reset rules.
  • Easy to understand. There are a few group of class names where each increment from 1 to 16. Once you understand each group, that's all there is. .grid-[x], .prepend-[x], .append-[x]
  • Comes with templates in various formats for use while wire framing or designing. It also has a sketch sheet for print. Helps workflow big time and keeps your mind in the framework while drawing out rough drafts. An even bigger plus that comes with this is *better communication* amongst your team members. Once everyone knows what they are working with, there's no guessing on how the layout is implemented. Everyone should be able to dig in immediately.
  • Use of a common language for presentation. Related to the previous point, it can help with support if there are enough people using it.
  • Awesome for prototyping and getting something up quickly!
    –Notice what Mark Boulton is prototyping with for the drupal.org redesign? It's Blueprint and working within 960 would be just as easy.
  • Not limited to your standard 3 column layouts. You can mix and match however you want. The grid is a building block so you can mix and match for very complex layouts.
  • Very similar to Blueprint and this approach is well known by the web community.
  • Working within the framework can minimize browser quirks. Namely IE6 & 7. You won't be completely rid of them of course but it will more likely come from your own custom styles than the rules defined by the framework.
  • Automatic right to left language support. I added this myself. More on this below.
  • Makes little assumpsions on what you want for a starting point. No colors, and very minimal for typography styles.
    –Also listed as a con. Depends on your point of view.

And the cons of 960:

  • Although the layout possibilities are numerous it is still rigid. Fixed width at 960 pixels and if you're designing a complex site, you have to work within the framework closely. But if you needed it to go beyond 960 for whatever reason, you can continue the pattern where 960 leaves off. Anyone who insists on fluid widths will not be happy with the system.
  • Unsemantic class naming. But as I mentioned before, it's really not an issue. It's listed anyway because I know there are a few out there who do care more than me.
  • There could be more templates (.tpl.php) being copied over to just to sneak in classes but I don't foresee this to be a big problem. It's almost always done already. -Allowing hook classes within all templates may alleviate that. All themes based on this framework will definitely require their own page.tpl.php so it goes against the idea of pure css based themes. I already mentioned why it wasn't practical though.
  • Makes little assumpsions on what you want for a starting point. No colors, and very minimal for typography styles. I would personally like better text styles. Maybe mash-up the best of Blueprint and 960? Blueprints coloring I could do without but I do like their typography a bit more.

Here are the sample themes I promised. "ninesixty" is the base theme with 960 included. Please read the page template, the read me file and explore. I did modify the 960 styles so it conforms more to Drupal standards.

Two things I added was a .push-x & .pull-x class for custom layout ordering that's independent from source order. Also added a 960-rtl.css file. All I had to do was reverse the rules so you'll automatically get rtl support for the rules defined in the framework. The examples provided supports it so check it out.

Only local images are allowed.

"carrot" is a sample subtheme I created late last night. I don't see this as core material. It's just a sample. I went from the sketch sheet, drew out the sections on the grid I wanted the theme to fit into with a few notes on color and pulled it all together in about 4 hours from start to finish.

Please download Drupal 7.x-dev and play with them. You can also change "core = 7.x" from the .info file to "core = 6.x" to get it working on Drupal 6. There may be small issues in doing this.

Downloads: ninesixty | carrot

Ninesixty is in my sandbox on d.o under /contributions/sandbox/dvessel/ninesixty/.

<em class="tips>Consensus on a framework theme must be reached by November 14, 2008.

UPDATE 12/14/08: The base theme has been updated. The README.txt file has all the details.

UPDATE 1/31/09: There is now a project page. Any further discussion on implementation details should be done within the issue queue.

Comments

Seems interesting, the

meba's picture

Seems interesting, the carrot seemed a bit broken for me - some "Notice: in ():" and right column in the bottom...

Thanks for checking. There's

dvessel's picture

Thanks for checking. There's only so much that can be done in the few hours I messed with it. I'll look into it and update the download.

The problem i realized with

meba's picture

The problem i realized with 960gs is: it's 960px! More than 50 % of users have 1280x800 and bigger, many developers in Czech Republic are moving to this resolution, having 960px + 1 more column with non important information.

If there are 90 % of users with 1280 in 1-2 years (and there will be), we will still have 960px and a we will face a new challenge: change 960gs to XXXXgs or stick with the old or develop something absolutely new?

Yeah, but as I mentioned in

dvessel's picture

Yeah, but as I mentioned in the post, it can be extended easily. If I wanted to use the framework but extend it with 1 more column I would leave the framework alone but extend it from the theme.

Something like this for the selectors:

/* for 12 subdivisions: 960 + 80 (1 grid unit) */
.plus-1 .container-12 {
  width: 1040px;
}

/* for 16 subdivisions: 960 + 60 (1 grid unit) */
.plus-1 .container-16 {
  width: 1020px;
}

Then in your template add a "plus-1" to the body tag so you get the new overall width. You could go anyway you want with this. Add more columns or remove them.

Then a big +1 from me :-)

meba's picture

Then a big +1 from me :-)

A little demo

yoroy's picture

Quicktime movie (1.2MB)

First part with the orange backgrounds is the 960 grid highlighting itself.
Second part with firebug open, a little peek at the source.

Good to know it can be extended beyond the 960 width as well.

Looking good

jeff1970's picture

If I can find some time this weekend I'm going to have a crack at porting one of my contrib theme to this (it uses a blueprint-like framework already), but this looks better.

+1 for considering Blueprints typography, the baseline grid is perfect and would be very easy for you to port that in. I'll be doing that anyway during the port of my theme, since it has strong baseline grid also.

I'll let you know how it goes, would be another example we can stick here if I can pull off a full port - it has zillions of collapsible regions & is 4 columns so I'll need to wrap my head around this:)

some thoughts

jeff h's picture

I've played with Blueprint's typography and that alone was enough of a reason for me to base all our recent Drupal themes on 960gs. I found baseline grids really just aren't practical in the real-world of a CMS where we cannot guarantee the markup that may get given to us in $content.

Also, in a web-browser context, it's highly unlikely that any given user will see the entire web page in one go anyway, negating much of the visual balance that is intended by the vertical grid. It works well on paper, since the reader will almost certainly see the whole page at once.

Just my opinion of course :)

An exciting possibility that we are working towards is the idea of having the panels module allow admins to design their own grid-based layout. All the guts are already in that module (see the flexible layout option), it just needs modification to work with grid units instead of %, em or px. If anyone wants to help us with this effort, certainly please do get in touch :)

A 960gs-based core theme would be a fantastic starting-point for pro themers in a way that none of the other core themes really are any more. Theme config options could allow some really great admin-level control — number of columns, number of grid units each column takes, etc We'd certainly be up for helping build such a thing.

Jeff
http://marmaladesoul.com

Guys, that sounds great.

dvessel's picture

Guys, that sounds great. I'll be looking forward to your impressions jmburnz.

@jeff, I agree about the vertical baseline and maintaining vertical rhythm. There's too much going on making it hard to control so it may not be worth including. Even when it doesn't quite work out, Blueprint does look more refined but perhaps that should be left alone since it should be left to the designer.

The iPhone viewport is 960.

lee vodra's picture

The iPhone viewport is 960. Maybe that should be added to the pro column.

actually, it's 980. so that

nlindley's picture

actually, it's 980. so that leaves 20 pixels to spare! :)

another 2 cents

HansBKK's picture

I don't know whether or not vertical-grid-based typography really is irrelevant to Drupal, but I think there may well be some designs where it could work. I don't see how seeing the whole page at once would be so important, to me the main idea is that the text in the sidebars is coordinated with that in the "main" content area for a more consistent and therefore elegant design, wherever your viewport happened to be in the page.

If people are going to be looking at this area, I highly recommend taking a look at Tripoli's typography "plug-in" as an example; I'm not sure of the implementation differences compared with Blueprint, but IMO Tripoli just created sites that looked better (typographically) when I last compared the two a couple of months ago.

I'm going back and forth on

dvessel's picture

I'm going back and forth on this but yeah, we should look closely at this and dig into all the options. I'll take another look at Tripoli's typography myself. It's not like all the components will be mandatory. It's easy to override the base theme's style and swapping them in for your own so having options here would be nice.

True

jeff h's picture

It's no doubt true that some designs and contexts may find the vertical grid useful. I guess my previous comments stemmed from the pragmatic realisation that (some) clients are inevitably going to say "Why so much space under that h2? Remove it please!" Thus throwing out all that careful cross-column alignment.

The Tripoli stuff looks interesting indeed; very comprehensive.

content first?

Phillip Mc's picture

great work dvessels. Looks really interesting. quick question: can I achieve a "content first" layout easily with 960? the reason I ask is a lot of clients tend to request that now. i.e. the main content is loaded before the columns and header, so it's what google see's first and has beneits for accessibility - surfers with eye sight issues that use audio readers to go through a web page.

It's pretty easy. Lets say

dvessel's picture

It's pretty easy. Lets say this is your source order. Note the push-x and pull-x classes.

<div class="container-16">

  <div id="content" class="grid-10 push-3">
    ...
  </div>
  <div id="sidebar-a" class="grid-3 pull-10">
    ...
  </div>
  <div id="sidebar-b" class="grid-3">
    ...
  </div>

</div>

Without the push/pull-x classes it would flow like this:

[content][sidebar-a][sidebar-b]

By default it follows source order but [content] with its push class shifts its positioning by 3 grid units to the right which is the width of [sidebar-a]. And [sidebar-a] with its pull class pulls it back across the width of [content].

[< content width] [sidebar width >] [no change]
[sidebar-a]       [content]         [sidebar-b]

The 960-rtl.css takes care of reflowing for the push-x and pull-x classes too so you get what's expected in those situations where it should do the complete opposite.

This isn't part of 960. I added this and it's reliable in my testing.

Vertical ordering with the header being later in the source is a different matter. I don't see a lot of sites doing this since it can really get screwy with overlaps if not done carefully. You'd have to figure that one out yourself as it's usually very specific to each site.

Brilliant

jeff h's picture

I have to say it — this is a brilliant extension of 960gs, worthy of inclusion in 960gs v2 in my opinion :)

Cool, I'm glad you think

dvessel's picture

Cool, I'm glad you think so.

There are existing prefix and suffix classes. I wonder if we can axe those and just use the push/pull classes for the sake of simplifying. The existing classes uses padding while the new additions use the "left" positioning.

Calculating the wrong prefix or suffix would result in unintended clearing while push & pull could potentially overlap adjacent blocks. But if used correctly, the two should display it the same way. Well, unless you're using a background image.. Maybe we should leave them. :) Just thinking aloud here.

do you think that using

sonictruth's picture

do you think that using 'left' positioning might have unpredictable results in IE though? One of the reasons that I like 960.gs is because out of the box there aren't any IE problems, changing this may cause some.

Of course i assume that in order for anything to make it into core it would be tested fairly extensively (by the community ;) ).

Thankfully, the left and

dvessel's picture

Thankfully, the left and right positioning isn't a problem for IE. All it needs is "position:relative" but that's for all browsers. The 'right' positioning is used in 960-rtl.css.

If there are hidden consequences in doing this, then I hope we discover it soon. The alternative is to use margins but then the math to swap layout positioning is a little more involved. Using left and right makes it almost dead simple.

what a great idea. The

sonictruth's picture

what a great idea. The source order has been one of the only drawbacks of using 960.gs

@jeff - once we sort out the panels integration there will be no stopping us!! evil laughter

Example test theme

jeff1970's picture

Please note - I had a mare of a time with D7 bugs so I re-rolled this against D6 - so this for Drupal 6 (hope you dont mind Joon).

Ok, so I had a play around with this tonight and made an attempt to emulate the layout of one of my other themes.

I tried to approach this with the idea that I as actually building a real theme (to get a feel for the time and limitations), its pretty rough and bashed together - but you will notice I have thrown in a heap more stuff that I might throw into a theme. If we're counting hours - about 6.5, granted I had to cook dinner tonight as well:)

This is pretty close to my original themes layout, although not entirely as the original has an additional wide "column" that that appears above the 2 right columns - say for example you want to display a 300x250 ad, the narrow grid-3's ain't wide enough so I would have an optional grid-6 column I. In my original theme I have this working but it can only appear when both the right sidebars are active - I had some trouble getting this to work with this framework when I threw in the content source ordering - I think I'd actually need to speak in person to explain all this or make a video...

Anyway - this is:

4 column
content source ordered
left, right & right_2 = grid-3

Guys - realise I am not a programmer ok - so you programmers (Joon...) please take a look at what i have done, especially in template.php - this is probably not the best approach but like I say, me no programmer, I just tried to work within the framework. I think if you start looking at this stuff we can see some issues that may need to be addressed:

1) content source ordering - the classes are great, but conditionally adding them is not there, I had to build it - of course what I have done is just for this theme, not a generic solution - or am I missing something?

template.php starting around line 20 - added two new vars;

-$left_pull_classes - so $left gets pulled back the right amount depending on what sidebars are active - also see page.tpl.php line 119
-$left_push - if left is active, set a class on "main" - the wrapper around the content, line 106 page.tpl.php

2) I want to be able to stack columns on top of each other, right now how to do this is not clear to me (I am probably missing something) - such as a grid-6 on top of 2 grid-3's.

I have changed page.tpl.php out of sight to support what I want - thats a given wrt to original designs, we're going to do this always, and it was easy to make work within the ninesixty framework.

I think that given this only took a shave over 6 hours, I have never really looked at before tonight (yes I have read the online 960 docs for about an hour previously) I have to say this was very easy to work.

I give you Beetroot - my first ninesixty theme, ever.

I cant attach zip files here, sorry.

Get Beetroot

Thanks for posting this!

dvessel's picture

Thanks for posting this! Much appreciate it.

...original has an additional wide "column" that that appears above the 2 right columns - say for example you want to display a 300x250 ad, the narrow grid-3's ain't wide enough so I would have an optional grid-6 column I. In my original theme I have this working but it can only appear when both the right sidebars are active - I had some trouble getting this to work with this framework when I threw in the content source ordering - I think I'd actually need to speak in person to explain all this or make a video...

2) I want to be able to stack columns on top of each other, right now how to do this is not clear to me (I am probably missing something) - such as a grid-6 on top of 2 grid-3's.

I understand what you're saying. Whenever you have mixed columns the easiest way is to place the block with the two spans before them in the source and simply give it a grid-6. The way you altered the layout ordering with the push and pull classes doesn't complicate this since the far right columns are not affected.

This is from your page.tpl.php file.

<!--
// This will simply fill the row and the two right blocks will clear neatly under this ad block.
-->
<?php if (!empty($right) && !empty($right_2): ?>
  <div id="ad-space" class="grid-6">
    <?php print $advertisement; ?>
  </div>
<?php endif; ?>

<?php if (!empty($right)): ?>
  <div id="sidebar-right" class="column sidebar grid-3">
    <?php print $right; ?>
  </div>
<?php endif; ?>

<?php if (!empty($right_2)): ?>
  <div id="sidebar-right-2" class="column sidebar grid-3">
    <?php print $right_2; ?>
  </div>
<?php endif; ?>

You could have the class on that ad block be dynamic so it adjusts based on the right sidebars being present. For example, pushing "grid-3" when one of them isn't available.

1) content source ordering - the classes are great, but conditionally adding them is not there, I had to build it - of course what I have done is just for this theme, not a generic solution - or am I missing something?

I'm glad you brought this up. The helper function "ns_row" I included was a quick hack but I would want a helper function that's similar and as simple as possible to spit out classes depending on nearby columns. We loose the usefulness of the body class that allows us to hook different rules based on sidebars appearing or not. This new function would fill that role and it would be a lot more flexible and fine grained. I'll have to think hard on this. Simplicity is crucial. If anyone has ideas, lets talk.

D7 head headache

eigentor's picture

For anyone haveing the same problem with D7 head as me (it just did not install): dvessels sample Themes "carrot" and "960" also work fine on D6.

Life is a process

Life is a journey, not a destination

...

dvessel's picture

Thanks for the reminder. I updated the post with a note on how to get it working on 6.

Interesting post by John

dvessel's picture

Interesting post by John Resig..

http://ejohn.org/blog/css3-template-layout/

Imagine if we cracked that nut. :)

fluid?

dvessel's picture

And here's a fluid version of 960. There might be some issues with IE but it could possibly be another option. Damn, I wish I had more time with this.

demo

very nice

ka

jeff1970's picture

Drupal 7 core nor not, this is kicking ass. I would love to see this in contrib.

not an option

dvessel's picture

I was playing with this and it doesn't look like an option. IE seems to be really bad with percentages. The rounding errors are horrible. I tried fixing the double float margin bug which was occurring but it still doesn't fix it. :/

How does it compare to YUI?

Bèr Kessels's picture

Blueprint is mentioned a few times, though I fail to see why 960 is better then blueprint. And, I don' t see That Other Grid System mentioned, YUI Grids.

They both have the same pro' s and con's as 960, it seems, with one mayor difference: audience and hence support.

YUI iand Blueprint are managed and developed by Yahoo and Google. I am not saying that yahoo or Google engineers are per-se better then the others around. But I do believe that having a large organisation backing it up, means:
* continuity. I cannot see any signs that 960 will stay maintained and upgraded. OTOH I don' t see any signs why it would get deprecated or abandoned.
* Audience. YUI is used a lot more then Blueprint (no numbers to backu, bu so it seems, when reading blogs, forums etc.). And both have a lot more users, AFIAKS, then 960 has. In FLOSS, the best way to measure market-value, is to count how many developers and contributors are using a piece of software (amount of users = developers + contributors + leeches; leeches add no value all others do: or better: everyone who adds value, is no longer a leech)
* Documentaion: YUI is used a lot and therefore a lot of videocasts, fora, blogs and wikis have howtos, answers, discussions and ideas.

However, biggest downside of YUI is its licence: BSD. BSD can be double-licenced with GPL, but Drupal does not allow any other-thenGPL licenced files in its releasesystem. Even a double-licenced package is not really allowed.
Actually, any 3rdparty code is not allowed in its releasessytem: so either the policy has to change, or else 960 will not be allowed to work OOTB, it will require people to download 690 files into the theme, in order to get this working.

FWIW, I started a grids-basetheme last month; but because of abovementioned policy-issues, I decided to host elsewhere: http://sharesource.org/project/drupalyuibasetheme

B`er

http://www.webschuur.com | http://bler.webschuur.com

A few pros/cons on 960 vs.

dvessel's picture

A few pros/cons on 960 vs. Blueprint..

Blueprint's: use of one sided 10 pixel gutters. That's tiny and having it on the right side only means the left edge of the content area will touch the left edge of the window (browser chrome). This also requires a .last class to chop off the margin on right most column to fit. It has to be chopped off because the overall width is 950px. (40px * 24 = 960 - .last)

960: has 10 pixle gutters on both sides of each grid making it 20px between each column and the left edge never touches the browser chrome. Since everything is evenly distributed, no need for a .last class either. There is a .alpha & .omega class when embedding grids within grids but it would be used less often. I did remove them in the modified versions but I think that was a mistake.

--

Blueprint: Slightly more layout possibilities since the smallest unit is less than 960's smallest which is available when using the container class of 16 subdivisions. 40px vs. 60px. Basically 24 columns in Blueprint vs. 16 columns in 960.

960: Although it's a little more restrictive, the two modes of 16 and 12 subdivisions has many possibilities and they can be used in tandem for outer containers if needed. 960 can be divided by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. It does this cleanly without having to drop off the last 10 pixels like blueprint does. It's also a little more conducive to getting better proportions on your layouts when working within these limits.

--

Class naming makes more sense in 960. grid-x vs span-x. <span> is already an existing tag. Not a big deal but it's a grid system, why not name it grid-x? Also the included templates and sketch sheets is a major win. One can be created for Blueprint too though but that's a little more work.

--

However, biggest downside of YUI is its licence: BSD. BSD can be double-licenced with GPL, but Drupal does not allow any other-thenGPL licenced files in its releasesystem. Even a double-licenced package is not really allowed.
Actually, any 3rdparty code is not allowed in its releasessytem: so either the policy has to change, or else 960 will not be allowed to work OOTB, it will require people to download 690 files into the theme, in order to get this working.

That's the major reason why I didn't mention YUI. On top of that, it's more opaque in it's class naming with a steeper learning curve. The reason why I mention Blueprint in the above post is because they are so similar in their approach.

And your point about hosting double licensed code is not quite right. We have jQuery and that's MIT & GPL. I don't know the in's and out's of licensing but doesn't YUI have to be BSD/GPL to begin with to be included in d.o? Even though BSD is more permissive, we can't just take the code and slap another license on it. Or am I wrong?

--

YUI iand Blueprint are managed and developed by Yahoo and Google. I am not saying that yahoo or Google engineers are per-se better then the others around. But I do believe that having a large organisation backing it up, means:

* continuity. I cannot see any signs that 960 will stay maintained and upgraded. OTOH I don' t see any signs why it would get deprecated or abandoned.

Blueprint is managed by Google? I don't think that's true and it would be news to me.

This isn't anything like jQuery or some other complex framework. The idea behind it is sound so if 960 was dropped tomorrow it will not mean that we can't fix bugs and update them. The style rules follow a predictable pattern and it's very simple.

--

* Documentaion: YUI is used a lot and therefore a lot of videocasts, fora, blogs and wikis have howtos, answers, discussions and ideas.

YUI is more complex so it makes sense there are more howto's and everything else. The abstraction in Blueprint and 960 is very shallow. Once you know the basics, you can get straight to work. Having a few starter tutorials would definitely be needed and I would write them myself.

great riteup

bertboerland's picture

some more here
www.noupe.com

--

bert boerland

--

bert boerland

Blueprint is managed by

Bèr Kessels's picture

Blueprint is managed by Google? I don't think that's true and it would be news to me.

Woops. My wrong. It is not. It is simply hosted on google code.

http://www.webschuur.com | http://bler.webschuur.com

Consensus?

kmonty's picture

Excuse me if I'm missing something obvious (I looked in this group and drupalcore issue queue), but was a consensus ever met?

I know I didn't weight in before 11/15, but I'm not completely sold on the idea of having a css framework, at least, one that you are required to use with Drupal. Echoing what other stated on the original project plan thread,, I feel like this could make harder for people to work with, as in people have to use learn a new system. Additionally, the Drupal community is relatively very large, is there a convincing reason why we cannot make our own core framework, rather than be shackled by using another system? Maybe I'm a rigid purist because I've been doing design work for a decade now, but minimal code is beautiful code. Resets and frameworks are inherently bloated. The Flickr Code blog had a great post against using frameworks for lightweight sites. It echoes exactly how I feel--if frameworks are mandatory with Drupal, launching mobile versions (or sites that are targeted for users in third world countries without a fast connection) are basically forced to rule out d7. That would be a shame.

I recognize that one could have made the same argument against jQuery. However, based on what I have read on the framework proposals, there is no way to ignore working with (or against) the framework, whereas someone can just choose to neglect to use jQuery (even though it is bundled with core).

The discussion I have been reading thus far makes it seem like the core basetheme/framework will not be optional. In my opinion, this will scare away professional themers, especially those who need to make compact enterprise themes. Can we make it a certainty that using the startertheme + framework will be an option rather than a requisite of d7?

You are indeed missing

moshe weitzman's picture

You are indeed missing something obvious - We will still support alternative themes and theme engines and all that. This is an optional new feature. Don't use it if you prefer.

Not manditory

dvessel's picture

As moshe stated, it is supposed to be optional. I stated this above also. Frameworks are not inherently bloated but that may be relative to your frame of mind. We are talking about Drupal here and most Drupal sites are not "lightweight". It's already complex so anything that helps us manage it better is a plus.

Creating another custom framework just for Drupal makes no sense at this point. There are countless web designers with great ideas and 960 I think is one of them. Before disagreeing with it, please try it and bring up specific issues.

a couple of things

jeff h's picture

Thanks for bringing this thread back into my inbox... I don't want it to die :)

A couple of things:

  • as others have mentioned, since this would be one of several core themes, and perhaps/probably not even the default theme, you can use it or not

  • I totally agree, our whole ethos in our business is minimalism and beauty in code, but strangely that's what led us to 960gs in the first place! Which leads me to ask...

  • have you played with it? If not, I really suggest a quick play-around with 960gs — you might find it's not quite what you thought. Your example of a compact enterprise theme could hardly be better suited to a grid-based CSS framework... in my opinion of course :)

  • the three css files for 960gs come in at 437 bytes, 648 bytes and 3,791 bytes. Of course, on dialup 5kb will cause another couple of seconds wait time, but only on the very first visit. By comparison, jquery.js in core Drupal 6 is 32 KB.

Jeff

ok

EclipseGc's picture

having played with this a bit now, a BIG ++ on getting a core theme ready for D7 based on this. I've only played with the vanilla framework, so no chance to play with dvessel's specific changes. I'll be downloading that shortly to give it a real go inside of a D6 environment. All that to say, I think this could be a HUGE benefit to professional work flow, and a mix of zen or basic's abilities and a 960 gs based theme would probably minimize breakup/design ramp up time significantly. I can tell you, we'll have an internal version of this for our own use if it doesn't make it into core. It's too good to ignore.

Eclipse

PS: If I can help getting this moved along, let me know.

...

dvessel's picture

Eclipse, thanks for trying it. I'll try and get another version up before this weekend.

One thing I can't figure out is how we can add conditional classes. If you look inside the theme, you'll see the function "ns_row" within template.php. Some thoughts on how to implement it would be very helpful.

Making it simple enough to be used right inside the .tpl.php file would be ideal I think.

Holy grid

eigentor's picture

At my first glance I did not understand a thing. At the second - I second EclipseGc.
This is so well-thought-through...

One thing I did not understand first is: hey, do I have to keep the naming "grid-12" and so on, semantic naming of divs normally is "content" "header" and so on.

But then it struck me: all the 960 styles are defined by classes not by ids. So you can still use your familiar div ids (like dvessel did in his demo), and still get the goodness of the predefined grid.

The limitations of a fixed grid may seem caging as opposed to a free layout. But if you by all means need different widths for elements: It is sure doable and with a bit of experience you should be able to use search + replace to quickly tweak it in the end.

But we are talking about a framework and base themes to build opon here, and we sure will manage to fit the first subthemes into the grid and make them still look beautiful.

What I like especially is that after a short while of digging into this, you get the point of it and see the pattern. It looks light-weight and defines nothing unnecessary - I hate css bloat. You throw out everything you don't need, and here you go. This is something I find most important: to enable people to work with it, the pattern must be quickly understandable instead of hidden and twisted.

Dvessel, one question: where did you tweak the themes so that styles are in "styles" subfolder instead of the top directory level of the theme folder?

Life is a process

Life is a journey, not a destination

...

dvessel's picture

My post might have been a little misleading where I mention ID's. I'll remove that. ID's should be more stringent in having proper semantic meaning than classes.

Eclipse is dead on. The biggest thing here is workflow.

...where did you tweak the themes so that styles are in "styles" subfolder instead of the top directory level of the theme folder?

In the .info file. You can define paths along with the file name. This can apply to anything where your defining a file. ex: "screenshot = images/screenshot.png"

any order layout

dvessel's picture

I still haven't updated the Drupalized version. I've been going back and forth with Nathan Smith on the push/pull classes trying to figure out the simplest way to achieve any order layouts. He liked having the ability but we're slowly exchanging ideas on the best way to approach it.

There are three approaches being considered so far. Maybe someone here can chime in.

Here's an example to illustrate. Assume the source order is this:

[content] [sidebar-a] [sidebar-b]

"<" = negative direction
">" = positive direction

Here are the approaches to change the visual order:

position:relative; + left:x
This is what I did in the modified version. It's easy to understand but it needs a "position:relative" rule for it to work. I was stuck on where it should be applied. If placed only to the elements with a push/pull, then other blocks will not have that positioning making it inconsistent. Why does this matter? Well, this will be a containing element and how the markup within behaves can depend on that positioning. If we stuck with this approach, then I'm starting to think the relative positioning should be applied to all "grid-x" blocks.

< left position: | left position:  > | no change
   content width |  sidebar-a width  |
[   sidebar-a   ] [     content     ] [  sidebar-b   ]
positive/negative left margins
This doesn't require "position:relative" but it not as straight forward as above. You must add adjacent columns + the current column to get the block to where you want them but it's in very specific circumstances. Note the left margin for "sidebar-a". It must include itself and the "content" column to pull itself all the way through.

< left margin:      | left margin: > | no change
  content+sidebar-a |  sidebar-a   > |
[    sidebar-a     ] [   content    ] [  sidebar-b   ]

opposing floats + containers
This one is also not as straight forward but the advantage in this is that there's no need for the numerous styling rules. It keeps the style sheet lighter but your markup will need to be planed properly for this. This would be done with a "opposite" class or whatever makes the most sense to float the block in the opposite direction.

So with the above examples, you'd need a wrapper to get the same order. The wrapper will need its own grid assignment and the elements will need the .alpha and .omega class to keep everything aligned.

[ --- div wrapper (grid-x) --- ]
   float: left | float: right
[ [ sidebar-a ] [  content   ] ] [  side-b  ]

So, any thoughts on this? What do you guys prefer? Or do you have another idea?

Thoughts and comments

EclipseGc's picture

OK, so the simplest method on this is the position:relative; statement, and, barring any cross-browser compatibility issues, this is the one I'd prefer to see happen. The negative margins don't bother me as the second best choice here, but IE has issues from time to time with neg margins so... beware.

With that said, I've been playing with this theme in D6 for a while now. I have scavenged the block/view edit/configure tabs from Zen as well as the ability to turn off the theme registry (making this more a developers theme now). I also snagged the browser body classes from basic (as this is an awesome feature). Note that I'm aware of page caching issues when using this, and I will provide a method for turning it off. However it's so useful, and so few sites really need the higher level caching that I think devs will again find this quite useful.

Finally I've also added the ability to turn the grid on and off from the theme config screen. I'm intending on adding a few more features in and doing a little clean up before I drop this back to the community at large, but I'm doing some dev work with it right now, and am VERY pleased. This is going to be a great theme.

Eclipse

...

dvessel's picture

I just uploaded another update on ninesixty after you posted this so be sure to grab the newest.

Your doing all of this from a sub-theme, right? Just making sure since the base should be bare bones with some tweaks that help the framework out.

I didn't mention this but I added the ability to reorder all the framework styles above all others. This is useful especially for the reset styles. Sub-themes can swap the framework styles for their own when it's using the same file name. That's how it's usually done in core.

Also redid the ns_row() function. It's simply ns() and the notes explain its usage.

Looking forward to what you got.

another opinion

jeff h's picture

I'd have to say I usually prefer the "positive/negative left margins" approach; however if we have rules which pre-calculate all the maths, am I right thinking we'd have (roughly) 16162 number of CSS rules? If so, I agree, that's getting too heavy.

eg
.container-12 .grid-1 .push-1 {}
.container-12 .grid-1 .push-2 {}
etc
.container-16 .grid-11 .pull-1 {}

In the cause of simplicity I suppose we're left with the position:relative; + left:x version. I don't mind this, and think I agree that position relative should be on all grid-x divs. Any CSS foundation should have minimal room for inconsistent rendering behaviour — IE gives us enough of that if we want it! :)

I was thinking the only downside with this approach is that it leaves us fewer options for positioning something completely freeform using position absolute eg an alpha-transparent starburst hanging over the page margin or other such decoration. However, we can always stick this in another theme region when needed, which won't have position relative surrounding it.

Incidentally, how are you dealing with IE's inconsistent rendering of objects with multiple classes assigned? eg #myobject.grid-5.push-2 won't work reliably in IE afaik.

Jeff

position relative

EclipseGc's picture

I also agree that as long as it doesn't cause a rendering bug in IE we should position:relative; everything. This is kind of mandatory if we want to absolutely position elements within divs. If the containing div is not relative it won't work properly. dvessel, where's your newest version of this theme so I can integrate my changes?

Eclipse

...

dvessel's picture

The main download link leads to the latest files. It's also in my sandbox "/contributions/sandbox/dvessel/ninesixty" on d.o.

update

dvessel's picture

The base theme has been updated. The "README.txt" explains it all. I attached a copy here if you want to take a peek.

grid-based Panels

jeff h's picture

If it's relevant or interesting to anyone, I had some good success on Saturday creating a new panels layout module which allows grid-based layouts to be created within the panels interface, similar to the flexible layout. I think this could be really powerful!

Before I release anything I'm waiting on the outcome of the "any order layouts" discussion, so I can build this into Panels' sidebars feature. Also, my module is D5-only at the moment, since Panels isn't really stable on 6 yet, so I'll probably wait for Panels 6 to be released.

Jeff

...

dvessel's picture

We need more feedback with the any order layouts. I'm siding with "position:relative; + left: x" myself.

legal

bertboerland's picture

Just to drop in some non technical arguments, according to our legal faq, templates files and javascript are per definition GPLv2+. CSS and images can be distributed onder another license.

Blueprint uses the MIT License, YUI uses the BSD license, 960 uses both GPL and MIT.

If we want to distribute these css fles in the CVS of Drupal.org the files /have/ to be GPLv2+. This is not by any "legal law", but by our own law; only GPLv2+ code lives on drupal.org. And it is a very wise decision.

However, that would mean that we can not distribute Blueprint and YUI. Although they can legally be distributed as a package, they can not be hosted on d.o, since we canno cange the license to a GPLv2+ one. This means that we have to make a small install readme (get latest css file from here and here, place in directoy xyz, done) for blueprint and yui, making it more complex for the user.

Just to make sure what are options are (yes, IANAL)

--

bert boerland

--

bert boerland

BP is GPL

dvessel's picture

Just to be clear, Blueprint is also MIT & GPL.

correct

bertboerland's picture

their website at google code only stated MIT, the download indeed has two licenses, MIT and GPL.

--

bert boerland

--

bert boerland

Clear: License

webthingee's picture

Just to make sure... if it (BP) carries both (MIT and GPL) then is not in any way limiting either license, but actually extending both...
so a theme, based on blueprint, can be hosted in d.o. .?.

I have been playing around with both frameworks over the past few days, just listening and watching this thread, decided to jump in... I have found myself gravitating back to BP over 960 mainly because of the class naming system. I have also enjoyed dissecting the genesis theme at d.o. to see how I can mold it into some of the BP framework.

yes

bertboerland's picture

if it (BP) carries both (MIT and GPL) then is not in any way limiting either license, but actually extending both...
so a theme, based on blueprint, can be hosted in d.o. .?.

yes, you only have to accept one license (gpl in our case) and hence it can be hosted on d.o

--

bert boerland

--

bert boerland

2 is better than one

webthingee's picture

That is great clarification, thank you :)

12 hours later

webthingee's picture

after some review... 960 isn't much different, it has a few less... refinements than blueprint css (IMHO) the default style sheets in blueprint make a nice "out of the box", but as I begin to experiment with 960 I can see some advantages to the very flexible grid.

And so is BluetripCSS MIT

ineation's picture

And so is BluetripCSS MIT and GPL

Alex
www.ineation.com

...

calebgilbert's picture

Interjecting Killes' recent comment that "IMO you can relicense BSD"...

Here are my 2 cents on

yhahn's picture

Here are my 2 cents on this:

I personally do not use CSS frameworks -- I think that if you are designing on a grid you almost certainly have a stronger understanding of your rules and metrics than any set of predefined classes (or scriptable classes a la blueprint) can provide. Given that the styling you provide will itself affect your metrics, you will find yourself adjusting your framework's metrics left and right to capture your grid concept. This means you need to understand and consistently be thinking about your grid -- in which case, why did you use a framework anyway? (for example, add a 1px border underneath your list items -- suddenly aligning to your typographical grid requires an exception rule. same goes for all other box-model metrics).

Aside from this personal opinion, I would definitely not endorse the default core theme using a grid CSS framework. This is because, as dvessel pointed out, CSS frameworks encourage non-semantic class markup. Given that Drupal's markup alteration framework (theme functions and the template + preprocess stack) on a typical theme can quickly grow to be unmaintainable (too much to take care of), unupgradable (what changes in the original templates do i need to merge in?), and brittle and inflexible (can't turn that module on without adding even more theming!), I just can't endorse a framework that is only useful when markup changes are involved.

That said, I would love to see one of the alternative core themes have a CSS framework in it because I think it will be valuable for all the reasons people have been pointing out.

...

dvessel's picture

One of the ideas behind getting new themes into core is that there will be no default theme. There was talk on letting the administrator choose in the initial install pages. Garland and Minelli will be left intact while the others (Bluemarine, Pushbutton, etc.) will be moved to contrib.

Given that the styling you provide will itself affect your metrics, you will find yourself adjusting your framework's metrics left and right to capture your grid concept. This means you need to understand and consistently be thinking about your grid -- in which case, why did you use a framework anyway?

This is why it has printable sketch sheets and templates for your graphics program. It's there to keep you within its confines. At the very least, having this example in core can lead others to take a similar approach of having a consistent workflow and allowing better communication in a team environment.

current ninesixty

jeff h's picture

I have read the code in the current version of ninesixty and have to say, that ns() function makes my head spin! We've built 960-based Drupal 6 themes before without anything like this function.

Also, the current incarnation is hardcoded to a 16-column grid. Would you be open to us patching this theme so that it handles either 12 or 16 cols and uses what I feel to be a far simpler bit of code for grid-units on DIVs in the page.tpl.php?

If so, what's the general consensus for a theme like this; should such settings as the above (ie 12 vs 16 cols) be variables at the top of template.php, or should we create a theme config form allowing a non-programmer-type to make these changes at an administrator level?

Jeff

our code

jeff h's picture

Here's the essence of our code; am I missing something that ns() does? (the following would need to be extended to handle the push / pull concepts of course)

<?php
function phptemplate_preprocess_page(&$vars, $hook) {
  
// define how many 960gs grid units per column - using the 12 grid unit system
$layout = $vars['layout'];
   switch (
$layout) {
     case
'left':
        
$vars['gridunits'] = array(3,9,0);
           break;
     case
'right':
       
$vars['gridunits'] = array(0,8,4);
           break;
     case
'both':
        
$vars['gridunits'] = array(3,6,3);
           break;
     case
'none':
        
$vars['gridunits'] = array(0,12,0);
          break;
}
?>

We can then print $gridunits[x] as needed in page.tpl.php eg for the left-column

class="grid_<?php print $gridunits[0] ?>"

Schweet

webthingee's picture

I have been toying with 960 for a few days... and I used this concept on my first ever contrib theme...
Thanks :)

For my 2cents... I am really liking and will be further exploring 960.gs

...

dvessel's picture

That's not good. I was hoping ns() would be easy to get. You did read the README.txt, right?

It's set for 16 columns but it's right inside the template where the other 960 classes are present. When switching for 12 columns, it's all right there in front of you. If the theme was to get all fancy, then doing it from a preprocess function makes sense but I stayed away from that since I thought it was simpler and easier to grasp the scope of what's going on right within the template file.

This ns() function is cool and push/pull also

ineation's picture

Cool feature, a few weeks ago i did a basic implementation of a 960 grid template for my own blog and I miss this dynamic function every day now...

Idem for push and pull classes. Great for having sidebar before content w/o impacting SEO.

It gives a great additionnal interest to grids.

It's really a great work. Now I have to convert my own theme to it! Will give you some feedback.

Alex
www.ineation.com

...

dvessel's picture

Thanks Alex. I haven't really put it to the test so I'll be looking forward to your feedback.

I do want to create another sub-theme but I'm not sure when. The "Carrot" theme was a weak effort.

a few more things..

dvessel's picture

I forgot to address you other points.

Having the code at the top of the template I'm not sure about. I can't think of anything bad about it. We've been trying to move away from direct function calls from templates but I thought this was a reasonable exception. What it does I think is straight forward and it would become harder to manage for complex layouts that change on many conditions. In most cases, I think it'll just be used to change layouts based on sidebars being present.

Using a theme config form should be addressed for sub-themes IMO. Using it in a base theme will complicates it and it doesn't carry over to its sub-themes. –Nor would we want it to since these layout classes can differ drastically between themes.

I have to agree with jeff on

sonictruth's picture

I have to agree with jeff on this one. The ns() function seems a bit more complex that what is necesarry.

I also don't like unnecesary function calls in the page.tpl.php. Isn't the whole idea of template.php to be a place where we can put the more complex code so that we can keep our .tpl.php files nice and clean? Whilst it's nice to 'have it all in front of you' in the page.tpl.php file, don't you think that the grid units that your site is using is a fairly fundamental thing and won't really change that often? In our case, the number of grid units for the left/right columns is decided a long time before any coding has taken place. It has been set in place by the designer.

I think jeffs idea is a cleaner way of doing it

The ns() function itself is

dvessel's picture

The ns() function itself is too complex or it being used within the template file makes it so?

It can be moved to a preprocess function if we must and I don't have any issues with that. Someone mentioned to me on IRC a while back that having that ability would be nice so that's what I went with. We could let theme devs decide for themselves in their own projects and have all core themes work strictly from preprocessors.

The code jeff provided is specific to sidebars. If that's all that your theme needs then it's a better solution but I wanted something more flexible and generalized since it can be used in any template or preprocess function.

Something like this?

Chris Herberte's picture

Easy to read for non programmers.

What would be really cool is to have a theme settings for sidebar sizes then obviously the main//center column would fill the gap -is that doable?

<?php
function phptemplate_preprocess_page(&$vars, $hook) {
$vars['classes'] = _classes($vars['layout']);
}

function
_classes($layout) {
switch (
$layout) {
   case
'left':
    
$classes['main'] = 'grid-12 push-4';
    
$classes['left'] = 'grid-4 pull-12';
     break;
   case
'right':
    
$classes['main'] = 'grid-12';
    
$classes['right'] = 'grid-4';
     break;
   case
'both':
    
$classes['main'] = 'grid-8 push-4';
    
$classes['left'] = 'grid-4 pull-8';
    
$classes['right'] = 'grid-4';
     break;
   case
'none':
    
$classes['main'] = 'grid-16';
     break;
  }
  return
$classes;
}
?>

<div id="main" class="<?php print $classes['main']; ?>">
..etc

Sure, we can have an theme

jeff h's picture

Sure, we can have an theme config setting where an admin can set the left and right column sidebar widths, but I think dvessel is right, that's a different type of theme altogether (where non themers can configure slightly-customisable theme layouts).

If we assume for now that everything will be set in code, the answer you've provided above is really another way of doing what I proposed earlier, and as dvessel pointed out, these solutions only deal with one, two or no sidebars being present.

His solution is significantly more flexible than this, but I fear, significantly more difficult to grasp for many CSS-but-non-programmer types.

I personally lean much more strongly toward doing a simplistic set of tpl.php files to provide a good base layout for 1,2 or 3 columns, and then use the Panels module to do more sophisticated layouts on the pages that need this. Then again, you'd expect me to push the Panels route, given that we are working on the panels_flexigrid module which allows admins to define arbitrary grid-based layouts :)

Although I now see much more clearly why it's there, I suppose I still vote against the ns() thing, for the following reasons:

  • it's only going to be used by programmers. As a programmer, instead of using ns() I'd rather just stick maybe two or three IF conditions in my theme to work out grid units when something depends on something else appearing or not. Maybe my themes are more simplistic, but I can't think of a practical example where I'd have needed more complexity.

  • I think grid-based layouts are inherently great at providing variety throughout a site, and there's a great solution in place for this with the Panels module. Using this module we can do very complex grid-based layouts without needing to do any code at all, and all the theme needs to do is provide a clean container_12 or _16 to wrap the panel layout in.

Jeff

Two cents

calebgilbert's picture

As someone who made one of the first Drupal css framework themes (based on YUI, something that I may stick with after checking out the others), I have to say that it's a bit funky that a new core theme could end up being one of the most untested ones out there.

There's existing Drupal YUI themes, and existing Blueprint themes, but no 960 themes that I could find. Going with the 'maverick' choice for the CSS framework seems somewhat counter to the whole concept of using a a grid framework in the first place. ;-)

...

dvessel's picture

HI Caleb. The approach 960 takes is not new. If you look closely at both Blueprint and 960, the concept is the same. It basically works by using floats with predefined widths which is very reliable. I would agree with you if it was for something more complex.

The only thing not tested are the additions I've added but they are not major and it's included to enhance what's already there.

Your other questions have already been addressed above.

Use blueprint

newz2000's picture

Based on the above comments it seems like Blueprint is the standard that everythign else is being compared to. So why not just use blueprint? If more people know blueprint (because 960 keeps getting compared to it) and more people use blueprint (caleb mentions existing blueprint based themes), and blueprint's licensing is compatible (as discussed above) then why on earth not use blueprint?

[edit: removing snippy remark]

--
Matthew Nuzum
newz2000 on freenode

--
Matthew Nuzum
newz2000 on freenode

previous 960 themes & 960 vs blueprint

jeff h's picture

Is this proposed theme a developer-centric theme, or something that is intended to be able to look great, untouched, for an ordinary user? If the former, then Caleb G's concerns above about the theme's history seem unimportant from my point of view; almost all professional Drupal themers never contribute the vast majority of their work; I know personally over the course of the last year we've built numerous Drupal themes completely on the 960.gs foundation. We haven't contributed any of these themes because they're for client-specific projects.

I feel bad that we've not had a chance thus far to contribute a generic 960-based theme, but this discussion is all about being a part of doing just that. At the end of the day, I think all I'm trying to say is that you can't assume a theme concept (eg 960.gs) hasn't been proven in a Drupal context purely because there are no contributed themes. It's well proven and tested, albeit not publicly.

Regarding 960 vs Blueprint; it's true, Blueprint has significant "mindshare", however Microsoft have proven that this does not implicitly equal quality :p There are many solid reasons to choose 960, and the two biggest reasons as I see it are:

  • it's like the best bits of Blueprint
  • it doesn't have the worst bits of Blueprint

Trite perhaps, but true! :) Have a play with both, and see if you agree.

Jeff

Try reading the thread over

dvessel's picture

newz2000, try reading the thread over or even better, try both and comeback.

There's a common pattern in how both work. It's the detail in its implementation that makes me side with 960. I don't buy the argument that just because it's more well known, that it should be chosen by default. If you know one, it's a very easy transition to hop onto the other so lets discuss the differences if you find BP does something better. Otherwise, your just adding more noise.

960 / (1+1.6180339887) =

laura s's picture

960 / (1+1.6180339887) = 366.687383 ... Wondering if a sub-theme could handle the Golden Ratio.....

Laura Scott
PINGV | Strategy • Design • Drupal Development

also see

The closes you can get to

dvessel's picture

The closes you can get to that is a 600/360 split (1.6). The golden ratio being 593/367.

BluePrint's closest is 600/350 (1.5825).

[edit: correction]

[edit: note]

I think I came to the wrong ratio.

600 * 1.6 = 960
360 * 1+1.6 = 936

It's not perfect.

Hence the sub-theme notion

laura s's picture

Could be a subtheme sharing much of the same structure and mark-up, but replacing the actual grids with permutations on golden ratio. Might be interesting.


Laura
pingVision, LLC (we're hiring)

Laura Scott
PINGV | Strategy • Design • Drupal Development

Sub Theme

EclipseGc's picture

I've started working on a subtheme version of 960 as a starter theme. I'm using the same approach as zen, which thus far seems to be that the core theme is not meant to be used, it's just the lion share of setup for the sub themes (i.e. no styling, eliminating page caching, other extras). I'm going to finish this up on my version, and the I'll sync it with dvessels updates. Hopefully we can have something quite workable here shortly.

Eclipse

Project page?

Chris Herberte's picture

Project page?

none yet

yoroy's picture

download link is in the original post, top of the page here.

Thanks yoroy. +1 for project

Chris Herberte's picture

Thanks yoroy. +1 for project page

Some work

EclipseGc's picture

ok I've been working this through for quite a while now. What I've got is a core theme "ninesixty/ninesixty" that sets up most of what we need. There's still some legacy code in the page.tpl.php from what I copied from dvessel as I intend on getting all the stuff he had working working... but pull and push have been disabled for the moment. The reasoning for this was that with the addition of pull/push we lost alpha/omega, and I still think these two can (and should) work together. The reasoning that we can do w/o them will lead to confusion ultimately during the layout process I think. Again I've had little time to play with the two together, so I reverted to alpha/omega instead of having push/pull. I will get that working in my next version.

With that said, a starter theme has been included ala zen style. In the same way I've added an administrative theme. The administrative theme is completely screwed up in IE and I KNOW it, I'll get around to fixing this soon.

Included are some features we know and love I.E. theme cache rebuilding, block edit/configure hovers, and browser body classes. I've supplied this as a D6 ready theme since there is almost no change to get it D7 compatible.

Looking for feedback folks.

http://www.drupalworx.com/files/ninesixty.tar.gz

Eclipse

I'd also like to emphasize,

EclipseGc's picture

I'd also like to emphasize, I've not tried to clean this up much, just add functionality, so.. LOTS to be done still.

960 in Core++ as a Theme Option

quicksketch's picture

Thanks dvessel for all the great work here. To share some analogies here between CSS and JS frameworks, let's remember that jQuery was the underdog when Drupal 5 first included it. We used based on its merits over Prototype/Scriptaculous, which was much, much more popular the time. And as other people have mentioned, this is a completely optional theme, versus the sort of "universal requirement" that jQuery had.

As for the "default" core theme, 960 definitely will not be the default theme, but it would be a great boon to include 960 as a theme in core just so themers wouldn't need to download the theme separately or make their own .tpl.php files. Since D6, we've now had the ability to "inherit" from themes even if they're not in the same directory. This means that any themer could start up a new theme in sites/all/themes, and simply put:

base theme = 960

in their theme.info file. Bingo. CSS-only themes are now possible using the 960 grid system. The page.tpl.php file provided in the 960 core theme does all the work necessary for you. The 960 theme doesn't even need to be enabled and you can still inherit all of its HTML markup goodness.

Some suggestions to get this moving along:

  • We need a project page. Suggestions here are great but a project page would both add legitimacy to the project and help organize ideas. It's also really hard to contribute patches in the g.d.o setting.
  • The ns() function is pretty baffling, I have to agree. Is this meant to be a public function? A good alternative might be...
  • Use the power of info files: The 960 theme would be an awesome, awesome place to demonstrate the power of .info files. For example, we could configure the number and width of columns through the .info file.
    columns[] = 200
    columns[] = 400
    columns[] = 360

    This would make a 3 column layout with the above width columns. You can access information from the info file by checking <?php $GLOBALS['theme_info']->info ?> in the base 960 theme's template.php and adjust settings as necessary. It may be possible to modify regions this way also, but I haven't tried that one.

I'd like to add that I don't use 960 (or any other CSS frameworks), so pardon if my above example doesn't make sense within the 960 paradigms. I still see this as an extremely valuable addition to Drupal, making it more accessible to themers. A CSS framework in Drupal would be as big a jump a jump as the BlueMarine -> Garland transition, even though Garland is a horrible, horrible starting theme. This would add a lot of legitimacy to Drupal from a designer's perspective.

Different name?

Todd Nienkerk's picture

quicksketch: Thanks for the jQuery anecdote. While I certainly agree that a grid system should be chosen on merit and not popularity, it's important to be reminded of concrete examples from time to time.

I think 960.gs is an awesome framework, so long as we can modify it to allow content-first markup. (For extra credit: A theme setting that allows the user to change the width -- not just number -- of columns through the UI would be pretty neat, too. This would require more "$classes"-style variables for each column's wrapping div in page.tpl.php.)

One important note before someone creates a project page: It probably shouldn't be named "960," as there may be PHP or CSS problems with functions, classes, etc. that begin with numerals. How about "grid960"? Or "framework960"?

Todd Ross Nienkerk
Co-founder, Four Kitchens

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

The any order layout is

dvessel's picture

The any order layout is pretty much solved. See the push/pull classes.

Adjusting column widths and layout order is very doable from the UI. I've done this with BluePrint for a client. Because of grid structure, it's very easy to accomplish.

And the theme name is "ninesixty" to prevent the problems you mentioned.

I am confused, I want to

ineation's picture

I am confused, I want to conduct a test on this theme... but which file should I download : the one in the initial post or the one by EclipseGc@drupal.org.

Btw, a project page seems to be the next natural step...

Alex
www.ineation.com

@Alex

EclipseGc's picture

I would advise my version as I've done quite a bit of work to get it more "zen"ish. i.e. there's a base theme, a subtheme starter kit and a subtheme administration theme all included. Additionally I've added things like turning off theme caching, optional browser classes in the body tag, and the ability to turn the background that displays the columns on or off. In general I've tried to make it much more developer friendly.

That said I removed some of the css functionality added by dvessel (push/pull) but my next iteration will almost certainly have that added back in. (plus additional improvements to the base theme and hopefully some more/better "progressive enhancement" separations in the css)

In any event, I'd give my version a go. It's for testing on D6, as the differences between D6 and 7 are very minor, this is still super doable.

I will NOT be founding a project page till I've had the chance to talk with dvessel. He got this ball rolling to begin with, so I don't want to snipe it out from under him unless he wants me to.

Eclipse

...

dvessel's picture

Everyone, sorry for the late reply. Eclipse, I'll take a look at your work within this week. I'll also get a project page up. We can discuss the details there.

quicksketch, thanks for the supporting words. There is a little misunderstanding though. Sub-themes inheriting templates will be less likely unless the visual structure of the page is very similar. What 960 brings is a common set of classes. Any changes in the HTML is almost expected between each theme unless the sub-theme used the same header, content, two sidebars and footer which I find tiresome. –I hope that doesn't change your mind. :)

The ns() function might make a little more sense when working with the frame work. Here's an simple example to illustrate.

Assuming we want $main to fill the full width when $sidebar is empty:

<div class="<?php print ns('grid-16', $sidebar, 4); ?>">
  <?php print $main; ?>
</div>

<?php if ($sidebar): ?>
<div class="grid-4">
  <?php print $sidebar; ?>
</div>
<?php endif; ?>

VS..

<div class="<?php print empty($sidebar) ? 'grid-16' : 'grid-12'; ?>">
  <?php print $main; ?>
</div>

<?php if ($sidebar): ?>
<div class="grid-4">
  <?php print $sidebar; ?>
</div>
<?php endif; ?>

The difference here isn't too bad but have more than one sidebar and the second ternary example would be more difficult while ns() would just need two extra parameters. example. ns('grid-16', $sidebar1, 4, $sidebar2, 3). It's helpful as it gets more complicated. For simple cases, it isn't necessary. I'm looking at it from the perspective of allowing complex news paper style layouts and dynamic regions. I hope to test its usage further.

I'm hoping to see the base theme as simple as possible. The only thing that's needed are the framework styles, sketch sheets and graphic templates. I believe sub-themes can take care of building on top of the base to allow whatever behavior it needs.

When I have time, I want to get a detailed write-up on how this may be done from start to finish emphasizing workflow.

you live!

EclipseGc's picture

good to hear from you. Wanted to toss out some thoughts on the ns_row function...

This is problematic in its current state as it's static for the base theme (i.e. you set it once, and since we're inheriting template.php and all it's functions into the subtheme's it's impossible (currently) for ns_row to be subtheme sensative). This needs to change so that we can have a function that fulfills our needs on a subtheme by subtheme basis. I like the general idea of ns_row, but as it stands right now, the sub themes basically have to do their own logic in the tpl files if they aren't using the same dimensions as ns_row.

If you don't change it I have some ideas on how I would, and I'll hopefully get that implemented before my next release as well.

Discussing making things as simple as possible... I've done some more work since I released this, and the base theme is essentially the following in my current version:

dir: extras
dir: images
dir: styles
logo.png
ninesixty.info
page.tpl.php
README.txt
template.block-editing.inc
template.php
theme-settings.php

This is pretty darn clean, gives us most of the niceties of zen, and allows subtheme starterkits to look like this out of the box:

dir: styles
mytheme.info *
favicon.ico
logo.png
screenshot.png
template.php *
theme-settings.php *

I've starred the important ones. :-) This is essentially 3 files, plus copy our base styles from the base theme and we're done. I'm thinking that there's a way to inherit the style sheets from the base theme, but thus far, no dice... maybe I need to remove entries in the info file? Will try shortly to see how to do this if it's possible. (Nate's post makes me think it is)

Nate, however, brings up a really good point. If all I need to do is create a .info file with base:ninesixty in it, I'll miss out on the template.php provided by that base theme, which if the base page.tpl.php is making use of ns_row() will REALLY send people for a loop. thoughts?

Thanks

Eclipse

Base theme as a Drupal-oriented template

Todd Nienkerk's picture

dvessel: How do you feel about simplifying the ninesixty theme to be simply a port of 960.gs to Drupal, including ns() and other Drupal-specific functionality? Perhaps ninesixty shouldn't have any styling at all; rather, a subtheme or two could be included that illustrates how to use ninesixty as a Zen-ish base theme.

Perhaps this is already what's being discussed. If that's the case, I apologize for the redundancy. (This thread is getting almost too big to remember! But that's a good thing.)

Todd Ross Nienkerk
Co-founder, Four Kitchens

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

That's exactly what I want

dvessel's picture

That's exactly what I want for ninesixty. :) There's some custom code in there to set the framework styles above all others but that will also be removed as soon as we get weighted styles in core. It would be even smaller.

I like the idea of a starter

dvessel's picture

I like the idea of a starter kit. Not sure yet of what should be included. theme-settings.php for example, I'm not sure about. Not all themes will need it.

Just to clear this up, defining a base theme will inherit the base template.php file and all its preprocessors and functions.

And did you work from the most recent version of ninesixty? ns_row was changed a while back to ns.

ahh, my initial work was too

EclipseGc's picture

ahh, my initial work was too far along to quickly switch. I'll try to update mine with all the details you've added.

theme-settings is great for the starter theme as we need this to turn off theme caching (if I recall correctly), which is one of the features that makes zen's starter kit so freaking awesome. Zen also manually invokes all of the core theme's template functions if I recall correctly too, which is what's confused me... perhaps I should try scaling back what I've seen Zen do, and see where (if) it breaks.

Will try this soon.

Eclipse

My apologies, I haven't

dvessel's picture

My apologies, I haven't looked at your work yet. Should I wait for your next version or is the current one similar enough where it wouldn't matter.

Please give the current

EclipseGc's picture

Please give the current version a go, some things to watch out for:

the starter theme will wsod your install. Please copy/paste the directory and change all the function names (similar to zen).
I am still learning about sub themes so I know I implemented a few things incorrectly, however, I think this is looking pretty good as a first go, so please fire away.

Danke sir.

cvs gives me headaches.

dvessel's picture

Here's the project page. http://drupal.org/project/ninesixty

I screwed up the initial commit though so the files won't show.

http://cvs.drupal.org/viewvc.py/drupal/contributions/themes/ninesixty/

I checked out the parent directory with this:

cvs checkout -r HEAD -l contributions/themes

The "-r HEAD" screwed up something. I couldn't add any files. Folders did go in and being silly I commited anyway. Because of this, it's stuck in an odd state.

Checked out the parent folder again without the HEAD tag. Added the files again and recommitted. My local copy seems fine doing a status check but it's still not showing in the repository. I should have read the guide. That was stupid of me.

Any ideas to get this in order?

Use cvs update -A rather

merlinofchaos's picture

Use cvs update -A rather than -r HEAD. HEAD is, unfortunately, a 'sticky tag' and not a branch, and it's automatically moved when things are checked in. It's totaly non-intuitive.

-A tells it to use no tag at all, which is, in fact, what you want.

Your files do not appear to actually be checked in, so I recommend trying again. =)

...

dvessel's picture

merlinofchaos, this is very strange.

This works:

cvs checkout themes/ninesixty contributions/themes/ninesixty

All the files are there so it was checked in. I tried updating with -A but it didn't allow me to commit since it saw no changes.

[edit: okay, this was just a fluke. I shouldn't be able to checkout like that without the -d option but it works.]

And this just gives me empty directories:

cvs checkout contributions/themes/ninesixty

Exactly as it shows in the repo site. Updating here has no effect. I tried to add the files again but it's already in the repo so it's a no go.

And here's the commit history.
http://drupal.org/project/cvs/364543

[edit: Attached status output.]
http://groups.drupal.org/files/ninesixty_cvs_status.txt

A Detailed Look at the 960 CSS Framework

jwolf's picture

For anyone interested, here's an In-depth video screencast from the editor of Nettuts.com, Jeffrey Way.

http://nettuts.com/videos/screencasts/a-detailed-look-at-the-960-css-fra...

Edited: Oops, looks like the link was already posted. Sorry.

ninesixty for Drupal.org?

ugerhard's picture

From Mark Boulton's Drupal.org website style guide (http://infrastructure.drupal.org/drupal.org-style-guide/grid.html):

The design grid consists of 12 columns, each 60 pixels wide with a 20 pixel gutter space between them giving a total of 960px wide.

This seems like a perfect fit for ninesixty / 960.gs.

Yeah, I'm having that

EclipseGc's picture

Yeah, I'm having that conversation here: http://groups.drupal.org/node/18560

12 + 16 ?

elv's picture

Ok I'm slowly catching up with this topic, so pardon me if I missed something. But the way the Drupal port works, do we have to choose between 12 or 16 cols? I mean use only one in a given page.

You can use both if your

dvessel's picture

You can use both if your theme needs it. There's a lot of overlapping rules for the 12 column layout and 16. I thought about separating them out but it wouldn't shave much off the grid styles. It would instead grow the styles a lot more if a theme needed both.

Just use what your theme needs, the left over styling rules have little effect.

But why?

elv's picture

Great then, because having to choose only one would be quite limiting!

By the way I've always wondered why theses two sets were initially chosen by 960's author.
12 can divided by 2 3 4 6
16 can be divided by 2 4 8
There's some overlap but it's quite flexible.

But, 24 can also be divided by all the numbers above + 12, offering more possibilities in a single set. No wonder it's a frequently used number of cols in various CSS frameworks. So why use two width sets in the first place? Using a single 24 cols set would be easier, and would solve the ns() issues too.
I think it's my major gripe against 960.

I think the two modes are

dvessel's picture

I think the two modes are there since 24 columns are often overkill. 12 and 16 columns still allows a lot of flexibility while cutting down on the rule sets. Flexibility is always a plus but how many columns do most sites really need?

BTW, I updated the original post. I fixed the CVS issues and the project page has been updated. A dev snapshot should be up shortly.

Well

elv's picture

You never need 24 real columns of course. Or even 16. It's just handy when you want to divide them into halves or thirds. It gives more push/pull possibilities.

And regarding the number of rules sets, 12 + 16 rules = 28, which is more than 24 ^_^

12+16 may be 28, which is

EclipseGc's picture

12+16 may be 28, which is more than 24, however it doesn't work this way, as any time width definitions are the same, they're stated together i.e.

container-12 grid-3,
container-61 grid-4 {
width:240px;
}

There are a number of places these will overlap... specifically 3/4, 6/8, 9/12, 12/16 which is 28-4 = 24 :-p

Granted, there'll be a few more lines of code, here, but the flexibility really doesn't cost us much of anything... so I don't see a point in really bringing it up.

Eclipse

960 and panels

webthingee's picture

I was working on a site using Panels yesterday when I realized the potential benefits of 960.gs to Panels and Views-Grid. In addition to allowing for some great layout possibilities... this might open the door for a theme to package in a panel template, or to use grid values (via some interface) in Panels.

Just a thought...

Sure, the possibilities are

dvessel's picture

Sure, the possibilities are pretty big. I like to see it as a standard way of "chunking" the layout. Very easy to describe and piece together. Although it make it easy to fit grid classes manually to get the layout, it also makes it very easy to programatically push in classes for configurable themes from the UI. I've done this with BluePrint and it didn't take much. Simple math from grade school is all that's needed. ;)

panels_flexigrid.module

jeff h's picture

Indeed! This is exactly what we have implemented in our panels_flexigrid.module. It is similar to Panels' inbuilt flexible layout, but uses grid-units instead. It also allows you to choose a 12 or 16 column layout for your panel.

There's a small problem to work out yet which is how to know when to wrap the panel in a container_ div. At the moment we're thinking of a simple checkbox in the config interface -- would have been nice to be automatic but I can't think how.

Anyway, I put the module in the wrong place and it's been awaiting a CVS maintainer to move it for over two weeks now :( As soon as they do that I can get a beta release out.

Jeff

Hi, I made 960.gs

Nathan Smith's picture

I feel as though I'm treading into waters above my head here (not being a hardcore Drupal-er). But, as the guy who made 960.gs, I was encouraged by Nick Lewis (nicklewis.org) to chime in here. I would have done so sooner, but I wasn't sure if it was only for core Drupal people. That and, I've been contending with a one-month old (fatherhood is awesome, but I'm still getting the hang of it), and just started a new job this past December.

I've traded emails with Dvessel and Eclipse, about possible ways to account for source-order while maintaining a consistent layout. I guess I should've put more thought into that up-front. But, I thought I was building a prototyping framework. Y'all are just taking and running with it, which is awesome. :)

Anyway, aside from just a "Hello {Drupal} World" post, I wanted to address a few questions:

1. Why 960? Why 12 columns, why 16 columns? Why not 24 columns / Blueprint?

When I first started 960 (before it had a catchy name), I did so to have a consistent starting point, for personal and work projects. It's funny that Dvessel said "chunk" out the layout, because initially my class names were (lamely) named class="chunk_1" etc. At first, there was just a 16 column layout, without any concept of a parent container specifying the number of chunks wide, since only sixteen could ever exist.

Then it dawned on me one day, when I needed to have a layout with 3 evenly sized columns that 16 by itself simply wouldn't do. Somewhere along the lines, Blueprint was released (though, the beginnings of 960 had already started taking shape). I even did a few projects using Blueprint, where a pre-defined codebase was a project requirement. However, I kept getting push-back from the client about the text touching the browser chrome (even though 1024 was deemed acceptable, they wanted it to be readable for 800x600 people willing to scroll). That, and with 10px gutters, it was difficult to tell if sentences were line-wrapping, or if they continued on to the sidebar (10px = roughly the size of a double space). So, I ended up hacking in a bunch of inelegant vertical borders, extra padding, etc.

Anyway, I decided that it would probably be best for me to stick to what I knew (the starter CSS codebase I was starting to grow), and that if another project came along which required a pre-defined codebase, that I ought to just go ahead and make one, since I was mostly there already. I was working as an IA at the time, so I also made sure to throw a little bit in the mix for everyone (IA, designer, developer): Visio / OmniGraffle, Fireworks (my fav) / Photoshop, and HTML / CSS. If Blueprint is a "vertical" market (to use business terms) of CSS: grid, typography, forms, etc. then 960 is a "horizontal" market - only grids - but exists in printable PDF, design template, and code permutations.

2. Isn't 960 "limited" in its application?

That's the elephant in the room, for sure. The same could be said of any fixed-width framework. But people have already made both em-based and fluid versions of it, so I don't see that aspect as being a problem. Though, yeah, with the name "960" I sort of painted mysef into a corner. Yet, I think of it more in terms of a design philosophy, than in raw pixels. Here's a brief breakdown (using pseudo variables)...

$pixels = Pixel width of container
$gutter = Pixel width of gutter
$one_col = Pixel width of 1 column
$num_cols = # of Columns

($pixels - ($num_cols x $gutter)) / $num_cols = $one_col

So, for 960 pixels wide, 20px gutters, 12 columns and 16 columns (respectively):

(960 - (12 x 20)) / 12 = 60

(960 - (16 x 20)) / 16 = 40

That's another reason I chose 12 and 16 columns, because they both sub-divided neatly into multiples of 10px. I couldn't bring myself to design based on something like a 15 column grid, because I didn't want to do multiples of fourty-four.

(960 - (15 x 20)) / 15 = 44

(Though, I did roll a custom 15-col version for a large PC manufacturer's use on their intranet. *shudders*)

I digress. My intention is to revisit the standardized width at some point down the road, when some other popular base-width becomes the heir apparent to 1024px. I figure, at that point, the same logic can be applied to whatever that eventual container's width might be. For now, that's 960. It's not set it stone for all time, despite the dorky numerical name of the framework.

For example, let's say that 1280 ends up becoming the next step-up from 1024. Let's say we want to leave a bit of room on each side for centering / auto margin. For the sake of easy math, I'll assume that 1200 will be our usable width. The same formula could apply for 1200.css:

class="container_20"

(1200 - (20 x 20)) / 20 = 50

-or-

class="container_24"

(1200 - (24 x 20)) / 24 = 30

Anyway, that illustrates my goal wasn't to permanently tie anyone to any particular pixel width. Plus, down the road there could always be em-based and/or fluid versions of whatever the new cool "960" number ends up being. If I've done anything right with 960.gs, hopefully it's to inspire others to take those principles and extend them well beyond the initial grid.

Without making this post too lengthy, let me just say the Drupal community seems like a great group of people, and it's been cool watching from the sidelines as you guys do all the hard work of integrating 960 into the CMS. I'm a lurker, and install Drupal on localhost with every major release. It's definitely become a lot more user-friendly. I can still remember being intimidated when I first heard about it, having to manually insert MySQL tables. Installers, FTW!

I guess that wraps up all I wanted to say for now. I look forward to a continued dialog, and to see how version 7 shapes up.

----------

P.S. -- The link to Nettuts is broken on this page (the URL has a [br/] tag at the end)...

http://drupal.org/project/ninesixty

-and-

There's a typo on this page. The graphic showing 6 columns is labeled as "5 columns"...

http://infrastructure.drupal.org/drupal.org-style-guide/grid.html

Welcome Nathan! Everyone is

dvessel's picture

Welcome Nathan! Everyone is welcome here and I'm especially glad you posted. And congratulations on being a father. :)

The 12 vs. 16 columns, I forgot to bring up that 3 cleanly divides into 12. The 16 sub-divisions are more useful when there's more columns with more variations on width. One thing I couldn't understand is how it can be sub-divided by 5. It's listed on the 960.gs site, was that a typo?

You mentioning 960 as a "horizontal" system is interesting. Drupal itself would be in the vertical category and piling on another vertical system is something I believe we should avoid even for a simple css framework. Thinking outside of just the styles, bringing everyone together seems like a better goal when many people will be involved and projects involving Drupal often involves more than just the visual designer. I believe limits can actually help bring forth better designs. I always blank out when I have a completely clean canvas but that's just me. :) Working around known parameters always works out better.

I've looked at the fluid version. Sadly, the rounding errors in IE6 is a major problem. I don't think there's a way around it. The day it falls off the face of this earth, we'll have more options. It's still great for sites where IE6 is not a concern but most in the Drupal community wouldn't go for that. I haven't seen the em version. Could you point us to that?

As far as being confined to 960, I personally don't see it as a big problem. I've mentioned it before but it can be extended without affecting 960.css file through body classes and continuing the numeric patterns. I had to do this with blueprint so the administration area had plenty of room to breathe. The neat convergence between the two different modes (12 vs. 16) may fall apart but designs using one mode will have no issues.

/* for 12 subdivisions: 960 + 80 (1 grid unit including gutters) /
.plus-1 .container-12 {
  width: 1040px;
}

/
for 16 subdivisions: 960 + 60 (1 grid unit including gutters) */
.plus-1 .container-16 {
  width: 1020px;
}

And the rest of the grid classes.. Another option may be to parse the CSS file to dynamically get at the the dimensions. Maybe even add the ability to do CSS constants to satisfy the individuals who have issues with unsemantic class names. color.module in core rewrites the styles for re-coloring the styling rules but I'm getting ahead of myself.

Thanks for dropping by. I hope to hear more from you soon.

Regarding dividing 960 by 5:

Nathan Smith's picture

Regarding dividing 960 by 5: That was a quote from Cameron Moll's site (via his article "Gridding the 960" which pre-dates 960gs), simply meaning that the number 960 (not necessarily the system) is divisible by 5. Sorry if it seemed misleading.

http://www.cameronmoll.com/archives/2006/12/gridding_the_960/

As for the em-based version, here it is. (Note: different class names, but he says he used 960gs as a starting point)

http://csswizardry.com/typogridphy/

By the way: I too "blank out" when staring at a blank canvas, which is why I like grids as a starting point. And, I share your sentiments about IE6. The sooner it declines in usage altogether, the better.

Fluid Grid theme

mdroste's picture

Maybe it's not well known, because it's very new: Drupal has a Grid theme which allows configurable fixed width Layouts and fluid Layouts. And one can choose the numbers of cols to work with. From 12 to 24.
http://drupal.org/project/fluidgrid

No, not from me, but I like it very much.

Installed

Warren-M's picture

960 Grid System (Zen sub theme)
A blank base Zen sub theme using the 960 Grid

Now, how do I do fill in the blanks?

I have a griddemo.html file from the "prototyping-with-grid-960" guide that has an extensive 12 col grid design. If I edit this for my use:

  1. Where do I place it?
  2. What do I name it?
  3. How does it identify with the theme?

Thanks, Warren

Warren-m, this is not the

yoroy's picture

Warren-m, this is not the best place to ask, try the drupal forums or the issue queue for the theme you are using. http://drupal.org/theme-guide has the basics to get you started with theming in general

Installed

Warren-M's picture

Thanks. It never occured to me that this could be an issue. I spent two days trying to find where to post it and got here from the forums.

how to mixture of 12 and 16

adrianmak's picture

how to mixture of 12 and 16 cols ?

See "Accelerated grid theming using NineSixty"

Todd Nienkerk's picture

We discuss this on slide 45 of Accelerated grid theming using NineSixty, a presentation Nathan Smith (creator of 960.gs) and I gave at DrupalCamp Dallas last summer.

Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross

Great Theme

kirei's picture

Thanks for making this. I got a crash course this past weekend in Drupal theming and WOW did this make it easy for me. On top of my crash course, I'm not great with PHP yet and found it fairly easy to play with this anyway. Thanks again!

-Dani

Theme development

Group organizers

Group notifications

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

Hot content this week