Standards Within Standards

Doug recently touched on the difficulties slight inconsistencies in a valid documents’ structure introduce when working with CSS. I’ve had two similar realizations in the past week at work. One occurred while attempting to help a coworker solve a float issue with a sidebar. A problem arose when familiar—similar or the same—ids were used but the structure/nesting differed from my existing mental model of those elements in my own work.

I remember thinking “Oh, how easy this would be if we were nesting tables.” I could just open up my trusty—now dusty—WYSIWYG editor and have at the problem. But the problem we were addressing wouldn’t even exist because a table cell in one row would never drop below the preceding cell in the same row. Right?

Get your head back in the game Inman!

That distinction is irrelevant. What we’re working towards is the separation of presentation and content. Making our content accessible to as many people and devices as possible without the redundancy of multiple versions of said content. Our goal is to simplify the integration of a standardized CMS—be it Movable Type or a custom-built alternative—and custom design.

That said, this post becomes just a round about way for me to formalize and share my typical if not ideal document structure.

<div id="container">
    <div id="content">

        <div id="header">
            <div id="masthead"></div> <!-- MASTHEAD -->
            <div id="nav">
                <div id="nav-util"></div> <!-- NAV-UTIL -->
                <div id="nav-main"></div> <!-- NAV-MAIN -->
            </div> <!-- NAV -->
            <div id="breadcrumbs"></div> <!-- BREADCRUMBS -->
        </div> <!-- HEADER -->

        <div id="nav-sect"></div> <!-- NAV-SECT -->

        <div id="inner-container">
            <div id="primary-content"></div> <!-- PRIMARY-CONTENT -->
            <div id="secondary-content"></div> <!-- SECONDARY-CONTENT -->
        </div> <!-- INNER-CONTAINER -->

        <div id="footer">
            <div id="nav-foot"></div> <!-- NAV-FOOT -->
        </div> <!-- FOOTER -->
    </div> <!-- CONTENT -->
</div> <!-- CONTAINER -->

No surprises here, I’m sure.

How it breaks down

There’s a container for positioning and inside that content for, um, content. header, nav-sect for the optional section navigation, an inner-container to facilitate a 3-column layout (vertical navigation / main content / sidebar) and the footer all reside in content peppered with empty divs whose sole purpose is to clear the necessary sections (is there a better way to do this?).

I know a number of people who use banner in place of where I go with masthead. I’ve encountered problems with ad-blocking software that kills images with “banner” in the file name so I try to avoid it. My CSS reflects this aversion for the sake of consistency.

Navigation, if multiple levels deep is comprised of nested unordered lists. I’ve cooked up a custom script that augments CSS drop-downs in Mozilla (links “remember” that they are the parent of the active menu and retain their :hover state when the mouse is over the menu) as well as enables them to work in IE. Hmm, I guess li:hover a could be covered when defining li a:hover and Mozilla wouldn’t even need the augmentation…I might need to revisit that script. The script also hides all <select> tags when a menu is expanded in IE PC to avoid a nasty, unaccommodating z-index conflict. I might want to share that sometime, no?

Inside primary- and secondary-content, related info is grouped in <div class="module">s with multiple classes applied where necessary to differentiate between sections. secondary-content is typically a sidebar but doesn’t need to be. Recently, I’ve found myself classing <div id="content"> to indicate how the content should be laid out. I’ve been usingone-column or two-column but I’ve also considered classing it by the page’s depth in the site.

My footer usually contains an <address> in addition to the nav-foot container and possibly another <div> for copyright info. Also the footer has a tendency to bounce back and forth between the container and inner-container.

I’d be interested in hearing how others’ “standardized” structures compare to my own. Maybe learn a thing or two from each other. (If you’d like to post code samples I would recommend checking out the last section of the Markdown Basics syntax page for an easy way to include both inline and pre-formatted code.)

Previous
End of Line
Next
Page 23
Author
Shaun Inman
Posted
April 15th, 2004 at 7:46 am
Categories
CSS
Web
Comments
012 (Now closed)

012 Comments

001

I’ve noticed a lot of people are moving towards classing or IDing the body tag to tie pages to different styles depending on where they are in the hierarchy of the site. (Rather than as you suggest using the content div. Either way works just fine.)

Personally, I name the container between header and footer ‘content’ because I don’t think of the navigation and such and site branding to be content. I also have just one overall container div before getting to the header/content/footer sections. If I need two divs for design purposes, I’ll use them, but I try to avoid nesting that isn’t semantically necessary if I possibly can.

Overall, though, the structure is very similar to what I generally use.

Author
Ste Grainer
Posted
Apr 15th, 2004 4:35 am
002

Funny you mention that. I’ve been iding the <body> to identify the site section. If each section is associated with its own color scheme it becomes easy to define the colors relative to that id.

Your other suggestion makes sense too. I could easily swap inner-container and content without changing the nature of the nest but improving the semantic structure.

So the revised document would look like:

<div id="container">
    <div id="inner-container">

        <div id="header">
            <div id="masthead"></div> <!-- MASTHEAD -->
            <div id="nav">
                <div id="nav-util"></div> <!-- NAV-UTIL -->
                <div id="nav-main"></div> <!-- NAV-MAIN -->
            </div> <!-- NAV
            <div id="breadcrumbs"></div> <!-- BREADCRUMBS -->
        </div> <!-- HEADER -->

        <div id="nav-sect"></div> <!-- NAV-SECT -->

        <div id="content">
            <div id="primary-content"></div> <!-- PRIMARY-CONTENT -->
            <div id="secondary-content"></div> <!-- SECONDARY-CONTENT -->
        </div> <!-- CONTENT -->

        <div id="footer">
            <div id="nav-foot"></div> <!-- NAV-FOOT -->
        </div> <!-- FOOTER -->
    </div> <!-- INNER-CONTAINER -->
</div> <!-- CONTAINER -->
Author
Shaun Inman
Posted
Apr 15th, 2004 4:53 am
003

I like the way you comment code. Very readable. You wouldn’t mind if I borrowed your style?

Author
Funkatron
Posted
Apr 15th, 2004 7:13 am
004

Nah man, go ahead. It’s not so much of a style as it is a technique. A programmer friend of mine taught me to close everything as I open it and then populate it—whether its a tag or quotes in HTML, parenths/curly brackets in JavaScript, or colon/semi-colon pairs in CSS. That way there’s no potential for forgotten closing tags. Since <div>s are a dime a dozen in today’s code I’ve started adding a comment with the id so I could tell where each <div> was being closed.

Author
Shaun Inman
Posted
Apr 15th, 2004 7:26 am
005

Hey, I had trouble on my site in IE displaying the background water stain on the right. I removed the comments from my page and now it works. Every hear of that mr. comment? Funkatron is a great name.

Author
Jason Santa Maria
Posted
Apr 15th, 2004 7:50 am
006

The closing the tag thing is something I need to get back in the habit of doing. Saves a lot of hassles. I’m sorta new at the standards game, but sites like yours makes it a lot easier.

And yes, Funkatron is a nice name; looks even cooler in that flash dealio of this site :p

Author
Funkatron
Posted
Apr 15th, 2004 8:09 am
007

Jason, you have a website? How’s it look in NS 4?

Author
Shaun Inman
Posted
Apr 15th, 2004 11:04 am
008

haha! clever lad! I don’t even have a computer I can throw n4 on anymore. I would love to see a screenshot of it.

My website is just a boring old place, no intelligent people would ever go there.

Author
Jason Santa Maria
Posted
Apr 15th, 2004 11:21 am
009

“I don’t even have a computer I can throw n4 on anymore.”

Which would explain why it’s sleeping on your couch.

Author
Shaun Inman
Posted
Apr 15th, 2004 5:08 pm
010

shhhh! He might hear you!

Author
Jason Santa Maria
Posted
Apr 17th, 2004 11:14 am
011

I usually like to start off with a div for the header with an h1 in it. Then, we go to to a div for the navigation, with a UL in it. (Sometimes, I will not use a div for the navigation and just put the navigation list in the header div).

<div id="header">
    <h1>Some Super Header</h1>
</div>
<div id="navigation">

Next, depending on what I need, I will wrap the content area in an id=”container” div and slap a div for the sidebar and a div for the main content area.

In the main content areas, each “article” is wrapped in a class=”article” div with an h2 for the title and some p’s for the text. (maybe an h3 for the date)

Next, I’ll put in a footer there at the end in a div, smacking an address tag in it.

Sometimes, I will put an id=”shell” div around the whole thing if I need it. Also, sometimes I won’t put the sidebar and main content area in a div of id=”container.” I really like including the article div.

<div class="article">
    <h2>Title</h2>
    This is some conmtent


    This is some other content


</div>

That is pretty much what I go about when I create a site, and then change it to what I specifically need for each project.

Author
Danny Cohen
Posted
Apr 17th, 2004 1:17 pm
012

First you have to confess that the id ‘content’ is directly related to the fact that you cannot have 2 background definitions per element, so you introduce new hooks. This is also a standard in a way - 2 containers and nothing on the body because IE’s are incapable of treating body appearance consistently. Double struggle, I really wouldn’t mind many background per element, each with it’s own position etc. And the best criteria of markup quality (at least for HTML for me) is if your co-worker or successor can read it and understand the structure. Complete structure, in contrast, is available only when you have a relational datastore. Otherwise it’s only commonsense.

Author
Julik
Posted
Apr 20th, 2004 6:29 am