I’ve been asked lately to code Web sites for people who apparently cannot afford my services. Rather than working out a budget with me, they hire another coder (usually for less than what I charge) who screws everything up (and I do mean everything) and then they come back to me asking for help.

It’s one thing to go to a public forum (like SitePoint, DigitalPoint, or WebDeveloper.com) and ask for help because you’re having a problem with your code or with a site your boss assigned you to maintain. That’s acceptable, and is considered part of the learning process (which is why I spend so much of my free time on these forums helping others so they can learn how to do things the right way). It’s another thing entirely for a prospective client to come to me after saying “I can’t afford you” asking for my help because the person s/he hired coded a Web site that doesn’t work in more than one browser (if at all).

Ok, sorry about the rant, but I had to get that off my chest.

So if you’re an HTML/CSS coder who wants to learn how to code the right way (or you hired one who could benefit from some free knowledge), then this upcoming mini-series will be perfect for you (and your Web designer).

I will be covering just about everything over the next few weeks, but I will do my best to keep the articles short (the browser series I’m working on is a behemoth already, and I just started that). To kick things off though, I’m going to talk about document structure. After you have built a few Web sites you will notice that (almost) every site follows a surprisingly simple structure: a header, menu (either along the top directly below the header, or along one of the sides as a column), main content area, a sidebar containing additional information (on occasion), and a footer. Maybe it’s just my Western bias kicking in here (reading from left to right), but since I read pages this way, it’s also how I tend to code them (unless circumstances dictate otherwise).

The header most often contains the logo, which may or may not be a link to the home page. Sometimes it’s small, spanning only a few hundred pixels in width (usually around 250 or so). Other times the header will span the entire width of the Web page. Either way is fine, as long as it fits in with the site’s overall look and feel.

Sometimes the menu will appear to be in the header, along with a search form and (possibly) other helpful links, such as a help/FAQ page, an about page, or a contact page. Other times, the menu will appear to be directly below the header, running from side to side, or will even be placed on one of the sides, usually the left, but occasionally on the right.

After the menu is the page content. This will of course change from page to page, but the overall size of the container will stay the same. What goes in here will depend on the page; some pages will have forms, others will have regular text (like what you’re struggling to stay awake to read right now). I’m sure you get the idea.

In some cases, you’ll have a sidebar which will contain additional information, or even advertisements (possibly both). A lot of people think you have to code this before the content, but I’m going to show you how to code the sidebar to come AFTER the content in the HTML source code while having it appear on one of the sides without using absolute positioning. It will involve the use of CSS (Cascading Style Sheets), and thus will be saved for another article.

Last, but most definitely not least, we have the footer. In most cases, the footer just contains the copyright notice (or other legal mumbo jumbo gobbledygook) and possibly some “helpful” links, such as the ever-present help/FAQ, contact page and about page. A recent trend, however, has the footer containing other links. Yahoo! Sports is an excellent example of this, using it as a secondary means of navigating a Web page. Personally, I don’t care for it, since if I want to go to another page, I’d just use the main menu – after all, that’s what it’s there for.

Next week, I’ll share with you the HTML I will be using. Unlike many other examples, mine will be bare-bones (written with clean, semantic, and valid code), and when I get to the CSS the week after, I’ll show you what you can do with that bare-bones HTML code. After all, a Web page should be coded with the bare minimum of markup necessary, with a clear separation of the structure from the presentation of the page. It also helps to code the CSS to work with the HTML, rather than to code the HTML to work with the CSS (which is why I use the bare minimum of HTML code necessary for the job). Join me (and possibly a special guest, if I can convince him to set some time aside) and I’ll show you and your designer how to do just that.

Be Sociable, Share!

•