Update and polish default page.tpl.php and associated css

Summary of chat with EclipseGc and JohnAlbin in #drupal. We want to:

1. switch class name .clear-block to .clearfix for semantic purposes (in Drupal "block" connotes many things!)
2. remove #main-squeeze from page.tpl.php and use a standard .inner class that we can place in #page, #main, .node (maybe), etc.;
3. standardize the use and naming of three classes that any theme will need: .column, .inner, .content (.content in particular is useful for nodes and blocks)
4. make sure a .inner inside another .inner doesn't inherit too much garbage (like #page > .inner > ... > #main > .inner)

To further clarify point #4, here's an example where nested .inner divs could cause a problem:

<div id="page"><div class="inner">
  I am the page! My inner div provides some padding.

  <div id="main"><div class="inner">
    The main body of the page goes here (nodes, tabs, etc.).

    This area can be a problem because it's inheriting properties from both #page .inner AND #main .inner. Why? Because the "#page .inner" selector means "any .inner class inside #page," which applies to #main .inner as well because #main .inner is inside #page.

  </div></div><!-- /.inner /#main -->
</div></div><!-- /.inner /#page -->

yes, the nested .inner classes could be a real headache.

Its too bad we can't use the first-child pseudo-class. :-( Stupid IE. Wait, a sec… It's only IE6 (and below) that doesn't support :first-child. And, we may be dropping IE6 support in Drupal 7…

What do you think? or are #page>.inner:first-child and #main>.inner:first-child too hard to grok?

Actually, I'm going to answer my own question as well. IE7 does support :first-child, but #page>.inner:first-child is too hard to grok. Its elegant, but non-intuitive.

Also, what are the chances you'll want to put the exact same padding/styles on the #page's inner as on the #main's inner. It seems more likely you would want the same styles on each of the columns. So, can we do #page, #page-inner and then have #left-sidebar.column, #left-sidebar.column-inner?

Crap, plus we forgot about the content-first bikeshed. ok. let me start that one rolling: Content-first is better semantically and better for the SEO-inclined. etc. etc. sigh. Ah, man, I think I need some tea before defending that position. :-p

This patch adds a wrapper div around the page div, which is common practice for *many* websites that want to simply center their content in a way compatible with IE, FF, Safari, etc.; it also allows for things like adding a shadow effect to the sides of the page area...

As a CSS-only kind of guy, this would be quite helpful for making an amazing CSS-only theme.

I'm assigning "patch (code needs work)" because there will be a few other changes before page.tpl.php is put to rest, I am sure.

Fixed the spacing issue on the patch (silly me... first time ever patching something!):

I made a few more changes in this patch to page.tpl.php, incorporating some of the suggestions above, which I'll outline below:

1. Still have the page-wrapper div in from earlier patch.

2. Put content div before navigation, search, etc., and after title (SEO lovers, rejoice!). IMO, it's best practice to have content > nav/sidebars.

3. I took out the main-squeeze div. Not only have I never heard of this 'squeeze' thing (I always wondered why it was called main-squeeze anyways), but I agree with Todd's reasoning above. Plus, for the people that use inner divs (I think they're fewer than those who don't), they can make their own inner div naming system ;-)

4. I changed the .clear-block's to .clearfix (3 occurrences), to follow common CSS standards. I think the clearfix is probably the simplest way to clear divs for now, because of that evil browser known as IE.

If we aren't dropping IE 6 support, that means we can't do the .inner class, because the child selector is not existant.

The details of good classnames are a little over my head, but would something like #left-inner be preferable to #left > .inner? Feel free to say no. Just considering...

My only concern with that is that while it works for left/center/right, it won't work for block and node templates down the line - because then we're back to nested .inner. So my vote would be for page-inner, left-inner, right-inner, block-inner even if that means slightly more CSS up front - much better than people having to do.

#sidebar_right .block .inner {
  margin: 0;
}

to remove inherited stuff later on.

.region-inner, .block-inner, and .node-inner sound great to me. What about pages that are not node pages, such as user profiles, administrative pages, etc? Just #content .region-inner ?

I also like .region-inner .block-inner and .node-inner. Good plan.

@ EclipseGc - I really wish the breadcrumb function was just a block, that you could stick anywhere you darn well please. Half the sites I make don't use breadcrumbs, and the other half I have to move it to another region anyways... But your way would probably work fine.

@ EclipseGc: I agree with moving breadcrumb and messages outside of #content -- maybe mission, too?

@ All: I love the .divtype-inner approach. To further bikeshed -- :) -- how do we feel about the .content class? Will nesting work here (.block .content, .node .content), or do we want some .divtype-content action?

I'd agree with moving breadcrumbs, et al. out of the content div and I think the *-inner class approach is really sane. I'll have to ponder the *-content class a bit. I'm mostly replying right now to subscribe without being completely annoying. :-p

I'd go with main + main-inner. (Main squeeze has got to go!). I like main, instead of content... but with 'content', it would seem logical to include the breadcrumb and such other pieces of information besides nodes...

@Eclipse: I like the -inner and -content combo you outline in #21. I think they serve very different purposes in terms of both styling/CSS (generating padding using -inner, etc.) and division of output (-content wraps the actual output of nodes, blocks, etc.).

I also like the idea of striking the .region class. I never understood the point, either. Who needs to style *regions* in a universal way?! :P I think .column and .sidebar suffice.

I further agree that "-region" should be added to #left, #right, and #content. After all, we have both #header and #header-region. #header-region looks like an oddball because it's the only "-region," but it's important to distinguish it from #header.

And while we're messing with "-region" divs, let's wrap $footer in #footer-region. It should be separated from $footer-message, which is often just a line of text with no wrapping markup. (At least the two are no longer concatenated! That probably annoyed me more than anything else in page.tpl.)

@ EclipseGc - could we possibly wrap #page in a #wrapper or .wrapper div?

Also, What are your thoughts on moving the content div above the left region, for SEO? It should probably stay below the messages and such, but I would love for content to be represented first... one of the primary reasons for separating form (CSS) from content is so that we can optimize the hell out of the content, then make it look pretty with CSS (by moving the columns where we need them).

I'd like to suggest some changes to #header-region and #footer-region.

First, the header. I think the entire header should be #header, and the wrapper around the region inside the header be called #header-region. (Also, I don't think the site name should be an h1 element for document hierarchy/SEO purposes. As I understand it, each page should only have one h1. The most appropriate h1 on a given page is #page-title.)

Current header area:

    <div id="header-region">
      <div class="region-inner">
      <?php if (!empty($logo)): ?>
        <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home" id="logo">
          <img src="<?php print $logo; ?>" alt="<?php print t('Home'); ?>" />
        </a>
      <?php endif; ?>
      <?php if (!empty($site_name)): ?>
        <h1 id="site-name">
          <a href="<?php print $front_page ?>" title="<?php print t('Home'); ?>" rel="home"><span><?php print $site_name; ?></span></a>
        </h1>
      <?php endif; ?>
      <?php if (!empty($site_slogan)): ?>
        <div id="site-slogan"><?php print $site_slogan; ?></div>
      <?php endif; ?>
      <?php if (!empty($search_box)): ?>
        <div id="search-box"><?php print $search_box; ?></div>
      <?php endif; ?>
      <?php print $header; ?>
      </div> <!-- /region-inner -->
    </div> <!-- /header-region -->

My suggested header area:

    <div id="header">
      <?php if (!empty($logo)): ?>
        <a href="<?php print $front_page; ?>" title="<?php print t('Home'); ?>" rel="home" id="logo">
          <img src="<?php print $logo; ?>" alt="<?php print t('Home'); ?>" />
        </a>
      <?php endif; ?>
      <?php if (!empty($site_name)): ?>
        <div id="site-name">
          <a href="<?php print $front_page ?>" title="<?php print t('Home'); ?>" rel="home"><span><?php print $site_name; ?></span></a>
        </div>
      <?php endif; ?>
      <?php if (!empty($site_slogan)): ?>
        <div id="site-slogan"><?php print $site_slogan; ?></div>
      <?php endif; ?>
      <?php if (!empty($search_box)): ?>
        <div id="search-box"><?php print $search_box; ?></div>
      <?php endif; ?>
      <div id="header-region">
        <div class="region-inner">
          <?php print $header; ?>
        </div> <!-- /region-inner -->
      </div> <!-- /header-region -->
    </div> <!-- /header -->

Second, the footer. Similar comments apply.

Current footer area:

    <?php if ($footer_message || $footer): ?>
    <div id="footer-region">
      <div class="region-inner">
        <?php print $footer_message; ?>
        <?php if (!empty($footer)): print $footer; endif; ?>
      </div> <!-- /region-inner -->
    </div> <!-- /footer-region -->
    <?php endif; ?>

My suggested footer area:

    <?php if ($footer_message || $footer): ?>
    <div id="footer">
        <?php print $footer_message; ?>
        <?php if (!empty($footer)): ?>
          <div id="footer-region">
            <div class="region-inner">
              <?php print $footer; ?>
            </div> <!-- /region-inner -->
          </div> <!-- /footer-region -->
        <?php endif; ?>
    </div> <!-- /footer -->
    <?php endif; ?>

Perhaps .region-inner isn't the best solution for regions. After all, the entire header isn't really a region -- it's contains a region, but it also contains the logo, site name, and slogan. The ".THING-inner" naming convention works for nodes and blocks. Headers and footers are more like "areas" than "regions" as Drupal defines them.

@EclipseGc: I definitely think we're getting there! I suppose I want to take a step back and ask: What would .region-inner achieve? Is there common styling or placement attributes that would be used across all regions? My gut reaction is no. My gut also tells me that anything ID'd as #foo-region should contain only region output. (My gut says a lot of things!)

I think it would be useful to discuss rationales for .region-inner and #foo-region. What do you find useful about .region-inner and wrapping the header and footer in "region" IDs?

Regarding the #site-name h1: I think we should change this to a div or span. Admittedly, there is some contention about whether search engines really prefer only one h1 per document. Search marketing professions (like my wife) feel very strongly that only one h1 should be allowed; W3C documentation, however, is vague on the subject.

Here's an interesting post that discusses the h1 debate and links to some other resources: Headings and Hierarchy: is More Than One H1 a Crowd?.

@EclipseGc: I absolutely understand -- and agree with -- the need for inner divs inside the left, right, and content regions as well as the header and footer. I'm just not sure that *region*-inner is the best way to do that. It feels like we're calling the header and footer "regions" just because, due to a lack of options, we're putting a *region*-inner div inside them (node-inner or block-inner certainly not appropriate here). There are regions inside header and footer, of course, but they are not entirely regions.

What do you think about making .header-inner and .footer-inner divs and leaving the "region" terminology to the divs surrounding actual region output?

@Todd Nienkerk: I agree with EclipseGc in post #34 - I think it would be less confusing to have all the inner 'regions' be "region-inner," as I, too, consider the header and footer to be 'regions,' just like the others. They're kind of like the roof and foundation on a house, which, imo, are 'regions' still...

I moved the "clear-block to clearfix" change to a new issue because it touches a lot of files all by itself. #371231: Rename clear-block CSS class to clearfix

I promised webchick to post my wishlist/proposal for the page.tpl.php. Finally got time this week to do it.

1. <h1 id="site-name"> You can use multple H1s on a page, but using an H1 on the site name is a waste of our SEO juice. The only page where an h1 for the site name might make sense is on the homepage. Over in the Zen theme issue queue, we discussed this and came up with code that only wraps the site name with an H1 after checking if $title (the content title) is empty. Also, interestingly, this same question is one that has been debated in the CSS community. http://h1debate.com And it appears to have been decided 2-to-1 in favor of no H1 around the site name/logo.
2. The repeated use of !empty(). Why do we have these? All of the page.tpl.php's variables are being set inside template_preprocess_page(). Wrapping all these in empty is just noise when a simple if ($varname): works just as well.
3. Related to the previous note, why do we have <?php if (!empty($messages)): print $messages; endif; ?>? The if statements in the tpl are used to prevent an empty wrapper div from being printed. If the variable is empty and doesn't have a wrapper div, printing it is the same as not printing it. So, again, this is clutter. Just replace those with <?php print $messages; ?>
4. #container, #main, #main-squeeze, #content, #content-content, what? This nest of divs is poorly named and arbitrarily nested.
5. Content first. For sure. Non-content-first themes/layout methods can override our default page.tpl.php.
6. $messages before $tabs. Why bury important messages? Move them just below the $title, so we can see them.
7. $secondary_menu: There are no themes in D6 that get this right because $secondary_menu is TOO flexible. It can be either the second-level of links from the main menu or a completely separate menu. By default it is configured to be a completely separate menu. And most websites stick separate, secondary links in the footer or as itty-bitty links at the top of the header. I say we stick them in the footer.
8. $closure: This is a bunch of javascript/debugging stuff. Is there a reason we need it inside the #page div? Let's just stick it before the closing body tag so that it doesn't screw up any #page styling.

@JohnAlbin: Your list in #38 is excellent. You've pointed out several things I hadn't even considered but now seem commonsense.

I'm not sure I completely agree with bullet #7, though. I've witnessed first-hand how many people don't realize the secondary menu can be contextual -- that is, is can display different child menus depending on the active parent page -- so know it's often used as a second menu instead of a secondary one. But is this a lack of demand for the feature, or is it simply a lack of awareness? Would more people use the powerful secondary feature if they knew about it -- or if it were named differently? If so, I'd think it would be better to stack them in page.tpl.

Ok. Here's a patch that does everything I mentioned in #38 and many other items mentioned above.

Things it doesn't do:

1. The main wrapper goes around content, navigation, left and right divs. Which works great for Zen layout method, but probably not so well for other layout methods. So we may want to move the navigation div above the main wrapper (just below the header). BTW, I haven't seen Zen's neat navigation-after-content-in-html-but-above-visually thingie in any other layout method, so while this is an awesome SEO feat, making it the default html order in Drupal might be a bit too much for people to handle.
2. Doesn't move $breadcrumb and $mission out of the content div. Where would we put it? Inside the navigation div (if we moved it per the previous comment)?
3. Doesn't move the $messages out of the content div. According to the Garland-based eye tracking graph at the UofMN usability testing, the eyes started looking at the page directly at the content's $title and then moved down. And then went wandering around to other items. So I feel that putting the $messages directly under the $title would give it the most visibility. (Also, #193482: Styling status messages in system.css)

Also, regarding the #page wrapper. I think 99% of sites are fixed width, centered sites. And the easiest way to do cool styling on it is with a page wrapper div. So I'm a +1 on geelingguy's #5 comment.

@Todd Nienkerk: I think a lack of awareness is a big problem with the secondary menu. However, secondary-as-separate is the default (as opposed to what D5 $secondary_links meant). The biggest problem isn't awareness, its that main and secondary links are way too limiting; they're not configurable enough to show 3+ levels of navigation. Until I re-write Menu Block (#342727: Optimize tree building code) and then get parts of it into core, we're stuck with what we have. And I think that the secondary links are most useful as a separate menu in the footer. And it would be hard for the default page.tpl.php to check the menu settings to see how the secondary links were used and then place them differently based on context. :-p

@ JohnAlbin:

Just three points:

1. I think that having the navigation before content makes sense; most sites have it that way anyways, and IMO this affects SEO much, much less than having one or both sidebars before the content. Having the nav links front and center can be a benefit for SEO, on some sites. From a designer's perspective, I like having navigation come structurally before the content.

2. I like $breadcrumb and $mission where they are. I haven't done a site yet where I've moved the breadcrumb to a different area (just above content title, below navigation/header), and I've only had a couple cases where I moved the mission statement into a sidebar (which can be quickly/easily accomplished with a block).

3. I kind of like the idea of messages after tabs... but could go either way on the issue. Having tabs at the top, in some ways, seems more logical; if you were using a file folder, the tab is always above everything that's inside...

Just throwing that out there. Otherwise I'm liking your patch!

(Prays for the day when node.tpl.php is finished, so I can get cranking on a CSS-only theme!).

P.S. I'm all for a #wrapper div. I LOVE styling with a wrapper, and I haven't done a fluid-width site since three years ago (had bad experiences... I'm a designer, not a programmer, and I like my designs to be as I intended them to be!). I would vote for the name #page-wrapper... because that's what it would be doing. (Also, a wrapper can help fluid layouts by allowing the designer to set a max-width and min-width on the whole page...).

I kind of like the idea of messages after tabs... but could go either way on the issue. Having tabs at the top, in some ways, seems more logical; if you were using a file folder, the tab is always above everything that's inside...

Except that messages aren't the contents of the tab. For example, if you go to the Add block tab and submit the form, it brings you back to the List tab and displays a message about the form you just submitted. Obviously, that message isn't related to the current tab.

Here's a new patch. It simplifies some of the divs inside #content, updates the comments at the top, and updates the Stark layout.css to accommodate the content-first order (using a simplified, non-bullet-proof version of the Zen layout method.)

I just took it for a spin in stark, and I think the new page structure is refreshingly consistent. Agreed that the 'navigation visually above but structurally below' might be a bit voodooish for most.

The only other question is why there isn't a #navigation-inner -- is it because navigation isn't a proper region?

I'm really, really liking it.

Subscribing.

Just tested it. I like it a lot! I can't find any real problems with it. I have some fun ideas that I'll be working on once we finish node.tpl.php :-)

The only other question is why there isn't a #navigation-inner -- is it because navigation isn't a proper region?

Actually, yes. I originally had a <div id="navigation-inner" class="region-inner"> in there, but the "region-inner" class was just wrong.

So, we have 3 choices on that point:

1. do NOT include an inner div like <div id="navigation-inner" class="region-inner">
2. include an inner div like <div id="navigation-inner"> but with no "region-inner" class
3. Add a $navigation region and include an inner div like <div id="navigation-inner" class="region-inner">

The Zen theme actually uses a #3 approach. But that also opens the floor to this question: What (if any) additional regions do we want in the default page.tpl.php?

What (if any) additional regions do we want in the default page.tpl.php?

"above content" plzkthxbi.

The "Content" region is about the most confusing frigging thing in the world.

@ webchick: I don't know why I didn't think of that, but yes, an 'above content' region would be immensely useful. Especially if one of the objectives of this ordeal is to make it so advanced theme designs can be solely CSS; a lot of sites I work on end up having something or another above the content section.

"above content" region++ :-)

We should also rename the "content" region to be "below content". In addition, I think we should make that a separate variable from $content so that it is similar to how $footer and $footer_message got split out in D6. $content_above and $content_below variable names? or $above_content and $below_content variables?

any others? navigation region? closure region? nether region?

content_top and content_bottom?

I like content_top and content_bottom. I don't know about any others, though... If someone wants to go region-crazy, they can make their own template files. While we want to make the theming able to be quite advanced, we don't want to overwhelm newcomers with too many regions or options.

In CSS, I'd much rather see content-top and content-bottom than content_top and content_bottom. Just my 2c. :)

As per #53, yes, I too would like to stick to dashes (-) rather than underscores (_) for CSS. Underscores seem to be used only for PHP normally, so this would seem to be a good idea to me.

@dbabbage: That's fine. They can be wrapped in divs with IDs of content-bottom/content-top. But PHP variables (print $content_top / $content_bottom) cannot contain hyphens; only underscores.

@EclipseGC: Re: the logo-title divs. I didn't see that change in your patch. That was an unintentional omission. I agree empty divs are annoying. Also, “nitpicky” comments are fine if they are married with “useful”, which yours totally are. :-)

For reference, the last major revision to the page.tpl.php was here: #163723: Fix default page.tpl markup. Funnily enough, they used the (as my co-workers refer to it) “Pre-JohnAlbin version of Zen” as the basis for those changes. :-)

I have a much longer response I need to write, but I won't have time until tonight to write it. I sold all my TVs yesterday, so Drupal will be my sole entertainment tonight.

Just talked geerlingguy in IRC a bit. Can't help out here, but I'm confident you're all doing good things here :)

I have only one request:

Please, please, please move the $help variable to the bottom of the page.
We have so much blabla keeping people away from the actual functionality (block admin page, anyone?), it's just plain impolite and unhelpful and has been observed being a true usability issue. People don't read manuals, really, they don't. Shoving it them in the face constantly is not the way to handle this.

Even if all those help text get transformed into a little clickable help icon when the new help system gets in, it should still be placed below the actual 'content' of the page: Let me try and figure it out first, if that didn't work, I probably scrolled down to the bottom of the page, hey look: Help…

Thank you!

A summary, then, since the patch in #43, along with a couple comments of mine:

1. (#47): I like approach 3, "Add a $navigation region and include an inner div" ... but as per #56, it might not be necessary. I'd like it for consistency's sake, though.

2. (#48-55) Include $content_top and $content_bottom (CSS: .content-top and .content-bottom) regions.

3. (#56) Fix up the #logo/#title section a bit. Make it have conditional PHP statements?

4. (#56) Perhaps move messages either completely out of the $content region, or into the new $content-top region.

5. (#58) JohnAlbin sold all his TVs. That's dedication!

6. (#59) Change the logo/header title to a <div> instead of <h1>.

7. (#60) (Possibly) move the $help section below the main content... and possibly even make it so it's not visible unless the user clicks a 'help' button. (I would be happy with having it be a help button, like a little question mark icon).

@yoroy: I think that particular proposal needs a wider discussion (including what this help looks like when it's eventually added), and is out of scope for a relatively simple issue of re-naming and re-ordering some HTML tags. Could you start a thread on the usability group and post back here? Whatever the consensus is, we can then implement it in a follow-up issue.

So, one of the fundamental questions about the markup in page.tpl.php is “Who will be using the default page.tpl.php?” I think the answer to that will be people who know CSS, but don’t know how to or don’t want to change the markup. So a super-lite html markup with no wrapper divs won't serve them well. I think we should strive to implement the minimal number of divs that will be necessary to complete a task.

If we look at the logo, site name, slogan section of the page from that perspective, it seems clear to me why we have so much markup. Since the logo will be some unknown size and will often be floated left, we are forced to have a div around site name and slogan; otherwise its difficult to guarantee the slogan will be aligned properly with the site name. So how about we nix the #logo-title div, but leave the #name-and-slogan div?

Re: navigation region: Including a navigation region for the sole reason of having consistency is probably a bad idea. I included a navigation region in Zen because I think the primary links list is pretty limiting and I often need more complex navigation. However, since Drupal core doesn't yet have a way to do more complex navigation (think “Menu block” module in core), I'm fine with that being a separate issue. For now, let's leave navigation the way it appears in #43.

I've included “Content top” ($content_top) and “Content bottom” ($content_bottom) regions. I think I would prefer text descriptions of “Above content” and “Below content”, but I’m unsure what the corresponding php variables should be called if we used those descriptions. Are top/bottom sufficient? If above/below is better, what var names?

But now… we have a serious semantic failure of the .region-inner class. The #navigation div has no region. The #header div contains much more than the header region. The #content div has 2 regions. Even #footer has more than just the footer region in it. Those “things” aren’t regions. Having spent maybe 60 minutes total looking at HTML 5, I see that HTML 5 would define those “things” as Sections. So I propose using .section classes. What say you?

Re: #foo-inner vs. .region-inner: Ok, here's a 90° turn, if we rename .region-inner to .section. How about we get rid of those #*-inner ids that are also sections. That would leave just #page-inner and #main-inner. The one conceptual problem I've seen in Zen is occasionally I'll have people ask “What are all those inner divs? I dont't get it.” And when I say that just how we named our wrapper divs, they go “oh! I understand now.” If you do a google search, I think "wrapper divs" is used 5 times more than "inner divs". So we could also rename the #page, #page-inner to #page-wrapper, #page and #main, #main-inner to #main-wrapper, #main. And that would align the markup with CSS terminology.

@EclipseGc: Dude, I got up early too! Here's a patch to make up for your "lost" hour.

Whoops!

Notice: Undefined variable: content in include() (line 56 of themes/garland/page.tpl.php).

Crap. The new regions are screwing things up. Looks like the $content variable is not generated if there is no $content region. :-\ I don't have time to look at this now.

Anyways, the page.tpl.php's HTML still needs review and feedback.

This re-rolled patch now renders $content if it's not a region.

H1 discussion over here too: http://groups.drupal.org/node/18956

Test failed: ah, bugger. I should have known messing with the regions would cause the block tests to fail.

Now that the #371231: Rename clear-block CSS class to clearfix issue has been committed, here's a re-roll. This also patches the block.test.

testbot please.

subscribe

Ok. I just had a very good chat with EclipseGc in IRC where I more fully explained the motivation for the classes and IDs in the last patch. And, I figured, hey, I haven't said enough in this issue already, so… ;-)

I prefer simple IDs for the "section" divs. I've never liked *-wrapper IDs because it makes the positioning rulesets longer. And *-inner IDs are just marginally better. But I also see the necessity for 2 divs around each positioned section, so what are you gonna do? Zen has been using *-inner IDs but that does cause occasional wtf?'s from people until they realize they are just wrapper divs by another name.

EclipseGc made a good argument (in a previous comment above) that <div id="ID"><div id="class"> makes higher specificity rulesets of #ID .class. The only problem with that argument was that we were (at the time) using "inner" as the class name. And its easy to get nested "inner" classes. And then the #ID .inner ruleset becomes problematic. But, IMO, a .section class seems unlikely to result in nested .section classes. And, presto! the original class-only-inner-div solution makes a lot sense.

That still leaves the #page and #main which are pure wrappers and not even page sections. And here I can't think of a solution different than the <div id="ID1"><div id="ID2"> solution. So, I resigned myself to using -wrapper IDs since "wrapper" is used much more than "inner" in the CSS community. And its only in two places.

I'm also fine with putting a "region" class around the immediate div parent of each region. I just noticed I missed a couple of those in the most recent patch.

Tonight, I'll try fixing that block.test failure. And if I can't do it, I'll move "split $content into $content_top and $content_bottom" to its own issue. Then re-roll with the missing "region" classes. And… be done?

Actually, .section might be used in content as an interim solution until html5 will finally introduce full <section> elements. Moreover .section is quite misleading.

http://www.mozilla.org/contribute/writing/markup#section

@tomamic: How is a section class “quite misleading”? We're trying to use .section in the same way HTML5 uses <section>. I don't see how that is misleading.

Anyone know what the purpose is of that Mozilla.org document? Is it a style guide for Mozilla.org documentation? It appears to be an orphan page with an AWOL parent. Is it a failed "let's create and organize some semantic classes" effort?

Putting aside Mozilla.org for a moment, should we be concerned about possible .section classes in content? There won't be any .section classes in any other tpl files.

Agreed with EclipseGc on #74 - and @ JohnAlbin: I like your idea with the sections - following an HTML5 mindset is a step in the right direction, and the .sections sections seem logical to me.

Ok. Figured out the block.test failure. Simple tests use Garland when running, so I had to update all the core themes that had content regions as well (garland, bluemarine, pushbutton).

I think I have all the IDs and CLASSes correct. But please triple-check; I already double-checked. ;-)

Also, you should eyeball the new regions over on admin/build/block. To reiterate, $content is no longer a region. $content_top and $content_bottom are the regions.

Hrm. I'd kind of rather not make this a core-wide change. But if we DO do that, then we need to write an upgrade path as well to move peoples' blocks that were formerly in the content region over to content_bottom.

What's the deal with the failing tests?

The failing block tests were because I assumed Simpletest was using the default page.tpl.php, buts its using Garland. And after I modified the default regions in system_theme_default() there was a region mis-match between the default and what Garland was expecting. I know what's going on now, so I can make sure the block.tests don't fail no matter what direction we take.

And, if you don't want it to be a core-wide change, I will revert the changes I made to those other page.tpl.php and modify their .info files so that they continue to use their old regions. That would eliminate the need for an upgrade path for blocks.

New patch does this.

Well, I'm open to discussion/debate. I think content_top/content_bottom is a good improvement, just I envisioned making any kind of sweeping changes to other themes/template files in a separate issue, *after* we get the default markup of page.tpl.php solved. It's also not clear to me why we'd want to change Garland's default regions, but not its default containing divs and stuff to match what we're doing here.

No, the test tests the default installation profile, which means it will use garland, unless we want all Drupal sites out there to ship with stark by default. ;)

As discussed in IRC, we'll move the content region discussion to a separate issue (i believe there is one already).

Wow! I really broke stuff. I was just running the block test on my system before and they all passed. Now I'm getting: 189 fails, 8319 exceptions. :-p

Ok, agreed. Lets move "split $content into 2 separate regions" to a follow-up issue; its causing too many cascading issues for this patch. We can add the markup for those regions’ divs into page.tpl.php in that issue. Its only 3 lines of HTML anyway.

Re: #86 - Love it, love it, love it!

I'm happy with the way things are now. Will go over it with a more fine-toothed comb later this weekend, but from a quick run-through, it looks mighty fine to me.

The content_top/content_bottom thing would be nice to get, so hopefully the other thread will result in a spiffy patch/upgrade.

Here's some follow-up issues to pursue after this issue is resolved.

#378916: Split content region into content_above and content_below
#378948: Make left and right sidebars more RTL friendly

They might be duplicates since Advanced Search isn't working on the issue queue right now. :-p

To any designers interested in diving in to the #86 patch without having to get their hands gooky in the patching process... attached is a patched page.tpl.php file (NOTE: If you're using the Stark theme with this modified page.tpl.php file, some of the layout will be changed... but at least you can see what the new template file does).

To use the file:

1. Download the attached file.
2. Rename the downloaded file to page.tpl.php.
3. Copy this file into /modules/system in the root of your drupal 7 installation.

.section is currently padding, and I think I'd prefer to see that as margin.

Yay! A bikeshed. Let’s compromise by putting padding on the left and top and margin on the right and bottom. k? ;-)

The rationale for moving secondary menu into the footer was:

1. Moving it was in my initial to-do list in #38 above (point 7).
2. Then Todd Nienkerk brought up a good point in #39
3. and I responded in #41

And that was the sum total of the discussion.

Also, only appears to be 2 closing divs for 3 opens

Can haz validz HTML? FAIL.

Ok, this new patch just changes the stuff around the main and secondary links. Rather than have a

@ John Albin RE: The secondary menu thing...

Typically, I just use the secondary menu as another set of links... however, there are projects where I like putting it just below the primary and using it as a second level primary links block. I didn't even know how to do this until a week or two ago, because documentation of the secondary links menu is poor at best.

Whatever the case, maybe we could make a point to document this change somewhere in the handbook, and explain to themers how to take control of their secondary links? (I don't really know where, because I haven't even seen a page on primary/secondary links in the Drupal 6 handbook...).

Review!

My stamp of approval is given. Can't find something to hate about the markup, either PHP or HTML. I've looked through it three times now; the only thing I didn't do is put it up on a live site and validate it, or test in IE 6. Maybe EclipseGc can do that ;-)

(As an aside, I have chosen this year (a "New Year's Resolution") to stop developing for IE 6. I'll only fix major bugs, but not minor layout problems. If one of my clients has a problem with that, well fuggedaboutit!).

Just installed it and poked around: I really, really like this.

It gets my thumbs up; unless JohnAlbin has objections to it, I know *I* would be thrilled. ;-)

Ok. geerlingguy and Eaton have thumbs up'ed it. In IRC, EclipseGC RTBC'ed the part of the patch I rolled. And I'm RTBC'ing the part of the patch he rolled.

I think we're good!

Commmmmmmmmmmmmiiittttttteeeeeeeeeeeddddddd! Yay!! :D

Thanks so much for all your hard work, folks! :D

Please ping back here with follow-up issues.

Wow this is great. Pure CSS Themes and standards-compliant, neat and clean...
Well actually this is a disguised subsribe post. Hope you forgive me.

Also related:
#370835: Improve password checker in the Stark theme.

Follow-up issue to fix: #387218: Default page.tpl.php needs to print RDF variables

adding a tag to group tpl stuff

Hello. I see there are patches here, but my download of Stark didn't come with a page.tpl.php file in it. Is there a simple download I can use to place in my modified Stark theme? I'd like to move my breadcrumbs somewhere else without having to use jQuery to do it.

Edit: never mind. I figured out where the default one was (in /modules/system/).