Last updated March 21, 2011. Created by JohnAlbin on December 16, 2007.
Edited by Christopher Jam..., ronald_istos. Log in to edit this page.

The CSS layout method used in the core Zen theme is based on the mostly undocumented “Zen Columns” layout method. The theme developer can use a liquid layout or fixed-width layout that is extremely flexible and has source-ordered XHTML, meaning the main content comes before anything else in the XHTML source, but does not necessarily come first in the visual display of the page.

The parts of the page are placed in the XHTML in the following order:

  1. Header
  2. Content
  3. Navbar
  4. Left sidebar
  5. Right sidebar
  6. Footer

But the page will visually appear to be presented to the user in the following order:

  1. Header
  2. Navbar
  3. Left sidebar
  4. Content
  5. Right sidebar
  6. Footer

Since the content is placed near the top of the XHTML source, both accessibility and search engine optimization will be greatly improved.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

I thought I'd explain how this is accomplished, in case it helps anyone...

The basics are simple. 4 elements, #content, #navbar, #sidebar-left & #sidebar-right are contained (in that order) within an element called #main. All 4 are left-floated, so they begin rendering in a horizontal line across (and beyond) the canvas.

#content has a right margin with a NEGATIVE value equal to its width and left-margin. This effectively 'pulls' the other elements across to the left by that amount, so that the next element left in the left-to-right sequence of floats moves to the very left of the stage, where #content's left-margin starts. The next element is #navbar, so it goes to its correct position at the top left of the screen. Because all elements but #navbar have a margin-top of the #navbar's height, they are all below #navbar.

#navbar has a width of 100%, and a margin-right of the same. This has the same effect of 'pulling' the remaining elements across to the left by that amount, so that the next element left in the left-to-right sequence of floats moves to the very left of the stage. The next element in the left-to-right sequence of floats is #sidebar-left. So it's where it needs to be.

Finally, #sidebar-left pulls the same trick - it also has a right margin with a NEGATIVE value equal to its width and left-margin. This effectively 'pulls' the final element remaining after it - #sidebar-right - to the very left of the stage. #sidebar-right has a left margin equal to the width (including padding and margins) of #sidebar-left and #content, so after its margin it's immediately to the right of #content. Thus it's where it needs to be, too.

Thanks, Thomas! Very helpful overview of the layout.

Yes, Very helpful. Much appreciated.

I have to confess that this is one of the most confusing things which I've come across in a while. In my layout I have 2 columns with the sidebar being on the right. #sidebar-right has a left margin of 690px, which is sensible, but it also has a right margin of -960px. What purpose does this serve? In fact, if I set this right margin to zero it seems to have no affect on the layout at all.

Also, you mention above that rendering begins with all elements in a line across and beyond the canvas. Why is this? They are contained within the page which has a fixed width so surely they should drop down. Clearly I'm missing something here but I'd like to know why this would be the case.

Thanks, Rich

I tried to explain the purpose of the negative right margin - take another look at what I wrote. As for the elements being 'in a line', perhaps what I should have said is that being left-floated they 'want' to be on the same line unless they find that other elements earlier in the source have pushed them off it, which thanks to the negative margins the elements here don't do.

I've just re-read your post and I can't find where you've mentioned sidebar right's right margin.

Yep, the elements do want to be on the same line. In fact, they do drift beyond the canvas if you mess with the figures. I just can't understand why because they should surely drop down due to running out of room.

I attempted to illustrate the concept in a post below. Unfortunately I can't delete that post and move it here where I wanted it.

... I pretty much understand how it works now, but still have to ask - why? What's the point of all this? Why do we declare elements in on order and then use negative margins to reposition them in the sequence? I realise that there must be a valid reason and I'd love to know what it is.

The brief answer is that the order in which elements appear in the source is the order they appear to some agents, such as search engine crawlers and people using certain sorts of web browsers for the visually impaired. (Some search engines apparently give greater weight to text which comes higher in the source order.)

Thanks, this really helped me to understand the structure! If I am not mistaken, I think #sidebar-right should be floated right.

Because all elements but #navbar have a margin-top of the #navbar's height, they are all below #navbar.

why?

on my site,
on firefox my right side bar has the same height as the nav bar thus occluding part of it. and on IE it gets worse because the content is vertically on top of the navbar...

If i specify navbar height and then specify all the margin tops manually it begins to behave. You talk about it as if this is meant to be automatic and you must be right becuase the zen theme doesnt specify any of these... and automatically all the columns assume their position below the navbar....

so what triggers this automatic behavior?

EDIT:Ignore this, they are specified even on zen... woops

the zen CSS was driving me up the wall with all the math. after thinking about it for a while, i've found that i can use absolute positioning to eliminate ALL the math. here's how:

#main is the parent element of #content, #navbar, #sidebar-left and #sidebar-right. #main has its position set to relative; this means absolutely positioned child elements will be positioned relative to the top/right/left/bottom of #main and not relative to edges of the browser. by using absolute positioning for #navbar and the sidebars i've found that i don't need to do any math at all. check out my code and tell me what you think:

#main
{
   position: relative;  /*absolutely positioned child elements will be positioned relative to parent and not to the browser*/
}
#navbar {
   height: 50px;
   position: absolute;
   top: 0px; /* place 0px from the top edge of #main */
   left: 0px; /* place 0px from the left edge of #main */
}
#sidebar-left {
   width: 200px;
   position: absolute;
   top: 50px; /* set to height of navbar - 50px from the top edge of #main is right below the navbar*/
   left: 0px; /* place 0px from the left edge of #main */
}
#sidebar-right {
   width: 200px;
   position: absolute;
   top: 50px; /*set to height of navbar */
   right: 0px; /* place 0px from the right edge of #main */
}
#content, .no-sidebars #content {
   margin-left: 0;
   margin-right: 0;
   margin-top: 50px /*set to height of navbar */
   padding: 0;
}
.sidebar-left #content {
   margin-left: 200px; /* width of #sidebar-left */
}
.sidebar-right #content {
   margin-right: 200px; /* width of #sidebar-right */
}
.two-sidebars #content {
   margin-left: 200px; /* The width of #sidebar-left */
   margin-right: 200px; /* The width of #sidebar-right */
}

this is working great for me and it requires no math at all.

thoughts?

If you've found that a layout using absolute positioning and precise pixel margins works for you then that's great, that means it is probably the best solution for your site.

However, there are a variety of features that the Zen system has that are not easily met, or in some cases simply cannot be met, using your method, for e.g.:

  • ability to function in either fluid or fixed designs (with only minor CSS changes required)
  • ability to re-order the columns and to deal well with missing columns by dynamically filling available space
  • renders well when a user-agent attempts to linearize the content - through a crappy cell phone browser, for example
  • deals well with the full set of methods users may employ to increase text size for readability/accessibility

The Zen layout method has been designed for maximum flexibility across a wide range of different design needs. Granted, absolute positioning would make the code simpler, but such an approach would only meet the needs of a particular subset of the wide range of sites that the Zen layout currently serves.

Phil.

why not just float sidebar-right to the right? if you do that, you don't need to worry #sidebar-right's margins at all (they're set to 0). you also don't need to worry about #sidebar-left's margins since it's not pulling #sidebar-right around the screen. the only margins you really need to worry about then are #content's margins.

i'm just not seeing why we're complicating the layout when there are easier ways to accomplish the same thing.

thoughts?

This is all related to the ordering of the columns and the desire to retain the ability for the middle column to expand and contract depending on the dimensions of the viewport. You can't simply float the left-sidebar "left" and the right-sidebar "right" and expect the middle column to behave by expanding and contracting through the middle. If your source order were sidebar-left, middle-column, sidebar-right, then you might be able to get away with it, as long as you knew that every page on your site was going to include all three columns. But as soon as you want to have your middle column appear first in the source order, or to deal with different numbers of columns using the same template, then things quickly become complicated.

There are dozens, perhaps hundreds, of different techniques for trying to achieve the perfect 3-column layout. Some of them use pared down CSS like you are suggesting. But the most flexible ones (i.e. the ones that provide the best range of options for dealing with different source column ordering and for effectively expanding and contracting depending on the presence of columns or on viewport width, and which are cross-browser compatible) are invariably fairly complex affairs.

Phil.

I understand how and why you've laid out the elements as you have. It's brilliantly sleek, searchable, accessible CSS.

However, since all the elements are floated left and since the negative right-margins in effect "pull" each subsequent element to the very left of the "stage" (the container element, #main), won't those elements with a left margin not equal to zero be vulnerable to the infamous IE6 Doubled Float-Margin Bug -- which will mysteriously double the left-margin of an element floated to the left that butts up against the inner-left of its container element: http://www.positioniseverything.net/explorer/doubled-margin.html

Will that bug apply to just the first element floated? Or will it apply to each of the left-floated elements with non-zero left margins, each pulled up against the left side of #main?

In the Zen layout-fixed.css, .sidebar-first #content and .two-sidebars #content each have a non-zero margin-left (each equal to "The width of .region-sidebar-first"), as does .region-sidebar-second (equal to the "Width of content + sidebar-first").

The problem does not occur in the Zen layout-liquid.css, in which the left-floated elements (#content, #navigation, and .region-sidebar-first) have margin-left equal to zero, and in which the right-floated element (.region-sidebar-second) has a margin-right equal to zero.

Fortunately, if the IE6 Doubled Float-Margin Bug is an issue for Zen layout-fixed.css, then there is an easy fix: Simply place {display: inline;} on each of the floats in question. According to that Position Is Everything article:

{display: inline;} on a float should be no different than using {display: block;} (or no display value at all), and indeed all browsers follow this specification, including IE. But, this does somehow trigger IE to stop doubling the float's margin. Thus, this fix can be applied straight, without any fussy hiding methods.

Unfortunately (Fortunately?), I do not have access to IE6, so I do not know if the problem actually arises (I tried an online emulator; but it had other issues, of its own). But this infamous IE bug is worth considering, particularly since the fix is so easy (and reportedly harmless).

Zen 2 deals with the ie 6 double margin float bug in the conditionally included ie6.css

However, if you are using panels and utilise the zen themed panel layouts you may hit this bug in .zen-one-sidebar-second .panel-sidebar-first

The solution is to add the following to ie6.css

.zen-one-sidebar-second .panel-sidebar-first {
display: inline; /* double float margin bugfix */
}

never mind...

This should go into the Docu, very helpfull info!!

Assume we're floating all column elements left, starting from the leftmost pixel on the browser screen; we'll call this our zero point: x=0.

Let's suppose our content column has a left margin of 20px and width of 60px, therefore it's right edge winds up at x=80.

Now let's consider how setting the right margin of the content column affects the positioning of the next column element:

If we gave the content column a right margin of 10px, the next element would be positioned from x=90, right?

If instead we gave it a right margin of 0px, the next element would be positioned from x=80.

Now consider this: if we gave the content column a right margin of -10px, the next element would be positioned from x=70. (The first element overlaps with the left margin of the next element.)

And finally, if we give the content column a right margin of -80px, which is the negative of the sum of it's left margin plus width, then the next element is positioned from x=0 -- i.e., the same point that the content column was positioned from. (The left edges of the left margins of both elements are co-incident at x=0.)

So it follows that, if we're floating elements left starting from any arbitrary point, and if we give each element a right margin equal to the negative of the sum of it's left margin plus it's width, then each succeeding element winds up positioned from that same initial point.

Knowing that, all you need to do is:
1) assume that all elements are being positioned, horizonally and vertically, from the same point
2) figure each element's left and top margins so that the visible portions are positioned correctly with respect to each other
3) force the initial assumption (1) to be true: float each element left, and for each element calculate a right margin = -(left margin + width).

I hope that's clear.

Thanks for clarifying the role of margin-right. After reading your post and rereading Thomas', everything made sense.

Does anyone know if my description + Simplicus' are still valid for Zen 2.x ? I haven't looked at this yet, but was thinking of contributing, perhaps including some documentation...

A good visual analogy would be to consider each column being printed on a separate transparency (like in the good old days before computers, when you would put printable elements on separate transparent overlays--actual pieces of mylar--to create a composite image).

On each transparency, you would locate the column a certain distance from the left edge, such that when you overlay (i.e., stack) all the transparencies on top of one another with their left edges co-incident, all columns will appear in the correct locations with respect to each other.

Well, here we're basically doing the same thing, but in a non-physical domain.

Each column has a certain width and is laid out a certain distance from a "left-edge", just like on a physical transparency.

Question: But now how can we overlay these "virtual transparencies" on top of one another, with their left-edges co-incident?

Answer: By using something that wouldn't make sense in the physical "mylar" world, but makes excellent sense in our virtual "html" world: a negative right margin.

For each column, we make the right margin = -(left margin + width), which has the effect of overlapping these "virtual transparencies" on top of each other with their left edges co-incident, and voila!--all the columns fall into place (assuming all your margin calculations are correct).

Finally, it should be apparent that just like with physical transparencies, the order in which we overlay (i.e., stack) our "virtual transparencies" does not change the look of the composite layout (as long as all left edges are co-incident), so we might as well order our "virtual transparencies" in a way that maximizes our search engine rankings--content first, navigation later, etc.

I read the whole way down to your post and didn't quite get it. However your post was just what I needed! I guess that means I grew up in a world of light tables and projectors.

This is a wonderful way to explain margins and the impetus for stacking things in a way that enhances SEO. Thanks.

Thank you so much! In just a minute I understood it! Exactly what I needed.

i think this could be better communicated with a flash movie, so if anyone wants me to make one say so (i know flash pretty good)

need 4 things though, in order to do it...

  1. a quick but decent explanation of why the zen people do it this way (i don't like making stuff if i can't say why something is like it is - that's where i get my motivation from). i mean, are there other ways? (such as using CSS positioning) is this better than them? is this approach a robust one? is it possible to get a little elaboration on the beef screenreaders & search engines have with the more (visually) to-be-expected source order?
  2. somewhere reliable to host it, so the link isn't gonna go dead. drupal.org perhaps???
  3. [ i don't know if you can upload swf movies to drupal.org. or, in case you can't, are there any rules for what kind of external links are allowed (ie: recommended locations for uploading files to, allowed filetypes, etc) ]

  4. an explanation of the how the footer works (its not covered by anyone as far as i can see)
  5. someone to check the flash movie when i've made a first draft (for the purposes of saying what's right & wrong) cos my understanding of the whole thing is still pretty shaky (i'm not as smart as loopduplicate)
  6. anyway, if anyones got anything to say u can email me at davidsmith20@hotmail.com. or obviously just reply

hey david,
check out my post above. i really don't see why we need to mess with margins at all when we can just use absolute positioning. i'd love to know if my code works for anyone else.

thanks!

Absolute positioning is not used because it does not respond to variable content well. That is the entire argument. You could use it deal with the SEO issues, and keep the structure seperate, but the idea is that you want as much of the page as possible to be fluid, not static, allowing the code to adapt the style to the content.
Absolute is too static for a generalized system like drupal. That's the theory, anyway.

Check out my post about Zen positioning of columns. Some of you have done your best to explain how Zen columns work but as a graphic designer I need some visual reference (thought I got it at first) and I thought other people may need a visual guide as well.

Post is here: http://choosecircle.com/blog/understanding-zen-theme-content-management-...

You can see the Zen layout used for this website here: http://www.mommyshares.com

As a newbie to drupal and to zen, I'm struggling with the huge number of css style sheets and confused by the duplication (and nomenclature - why html reset?) of css elements. I've been working with css for 3.5 years and thought I knew a thing or two until I encountered drupal/zen. The following site is my first attempt http://www.fofumrecords.com - don't laugh (out loud).
It's lacking in all sorts of ways, but one thing really bugs me and that is the (my) inability to range the header section right of the left sidebar - or to put it another way - the header runs across the top of the page and the left sidebar hangs beneath. Well suppose I want the sidebar to run from top to bottom 100%? From my twiddling it seems that the navbar is "captured" by the main div - which sits directly underneath the header/navbar...it does seem an inordinately complex system - (particularly for those of us numerically challenged...). As such I find it difficult not to regard the structure as inflexible - am I wrong...?

ps the above article looks like it might explain a few things to my poor old brain - thanks...

(54 years old and struggling)...

angstman, I think this kind of post is better dealt with in the Zen issue queue as a support request rather than as a post here in the Zen documentation. The quick answer is that you are right that the Zen layout is not set up to adjust this easily. What you want to do in principle is to move the header section inside the main content section where you normally find the "top" content section. Which is really like getting rid of the header altogether and having a two column layout with no header. That would require some significant edits to the CSS. Try posting in the issue queue and maybe you'll get more detailed suggestions/instructions.

Phil.

Thanks for the advice Phil, although I've just discovered the Zen page template, which makes things a little clearer. However tinkering with the page structure will require a better understanding of the css...

Your explanation works the best for me, especially in combination with the image. http://choosecircle.com/sites/choosecircle.com/files/understanding-zen.jpg.

Zen Documentation needs to be better, so that we don't have to bury our heads in a comment list to find explanations. They say zen documentation is fantastic, but only at a very basic level. Your kind of explanation in combination with something visual is what zen theme documentation needs.

Thanks again

Okay...I am a newby. How in GOD's name do u change a simple CSS file in Zen? All I want to do is change a simple color and I have been at this for 48 hours. I am ready to go back to simple HTML/CSS structure via Dreamweaver and to toss the CMS.

HELP please...

Dear Zen...your dead. Fusion is SO MUCH easier.

My reaction is exactly opposite. I switched from fusion to zen because with zen I was able to achieve exactly what I needed relatively quickly, which would not have been possible with fusion no matter how much time I spent wading though tons of confusing code. Not to knock fusion, but it has its limitations.

So Dear Zen...you're still alive and well. Thanks guys, for a great job!

If you understand html and css then changing a simple colour should have taken no time whatsoever. Just use firebug to figure out where the colour is specified for a start. It's actually very easy...from starting with Zen I had my entire theme going within a few days, and that was with almost no css or html experience.

Still, the negative margins are still as confusing as hell.

I didn't understand it either at first, which is what led me to this article. I thought Thomas Ash explained it very well in comment #1. I don't get what all the confusion is about. The negative right margin pulls the next block over to the left edge, so that it can be positioned from there. It works beautifully. It's just simple arithmetic.

Could someone please explain to a noob how to change the width of the page from 960px to a smaller lets say 725px in layout-fixed.css? Thanks!!

Greetings from [url=http://maytoursbeijing.info/]May Tours[/url].

Hey chiappa, this should help you set column widths in Zen http://vimeo.com/36738541

I posted a visual guide to doing the math on layout-fixed.css for Drupal 6. It's definitely geared toward newbies, but I think it might help people who have the same questions that many of my teammates did when starting to work with this file. It helped them, so I thought I'd pass it along.
Working with Zen's Layout Fixed CSS

Hi All
Thomas, after reading your explanation I altered the figures in the layout-fixed.css of my sub-theme and my page layouts immediately fell into correct position on both IE and Firefox, something I had been struggling with for a while, for a while Firefox was rendering it correctly even though my figures were apparently out and IE always showed the elements as a bit of a mish mash - it was very untidy. Now they are in the correct place, so thank you very much for your explanaion Thomas. You can view my site here: www.jbmjk.com

The Stylesheets I have are layout-fixed.css and my cusotm one jens2.css more for the appearance than the layout.

Can anybody help me to tweak the code to perfection. Although everything is now where it should be position wise - Left, right sidebar and content are all pushed up into the navbar with no margins showing between the elements and for some reason navbar is slightly mis-aligned from everything else, off to the right.

I'm a wee bit scared to touch anything now all the elements are being rendered in the correct position on the screen. :-/

Many Thanks

This seems to me to be the most ridiculous method to set the layout. Why don't you try to make it a little more confusing? My comment to others is to stay away from this theme and try to use a real theme like Adaptive or Omega.

For those who come across markusa's comments here in the documentation section of Zen, I would note that Zen layout options and methods have moved along quite a ways since this page was created and since the initial comments in this thread appeared. The comments on this page address issues related primarily to "fluid" layout options for Zen 6.x-1.x and 6.x-2.x. The fluid layout CSS structure in the 7.x-3.x and earlier versions of Zen was inherited from the 6.x versions that were also written with XHTML in mind.

However, before dismissing Zen as an option, it is worth evaluating the current version 7.x-5.x written for HTML5. Layouts are achieved differently now, and several new features and configuration methods are available, including a robust system for achieving responsive designs and the introduction of Zen grids, which leverages the power SASS for CSS:
http://zengrids.com/

And of course, Zen has always offered one or more fixed-width layout options, which have always been configured more simply.

The Adaptive and Omega themes mentioned by markusa above are both also great, popular them choices, and they may indeed be better choices for some users or some use cases. But I would encourage users to compare current versions of themes when evaluating options. The Adaptive Theme, for example, no longer has a supported version for Drupal 6.x, so it would probably not be the best option for those people still running Drupal 6. Likewise, the Omega theme was still in its infancy in its 6.x-1.0 version (the final version produced for Drupal 6.x), and some users may very well find that version as challenging as Zen when attempting to configure it for Drupal 6.x.

Phil.

truly pkiff is right. Really I shouldn't have flamed Zen in general. I was trying to adapt a theme that was done several years ago in an old 6.x zen version. Things have changed quite a bit on the theme scene and to be fair, although I don't prefer Zen the current version is a fully capable, modern theme.
I still prefer Adaptive, not only for its advanced configuration UI, but just for its general structure and the fact that out of the box all the stylesheet files are set to them for smartphones, tablets, and desktops. Not to mention GPanel templates.
So to all Zen lovers out there, my humblest apologies for flaming your theme.....