Skip navigation

Harald Markus Wirth


Page Content:

Yet Another Guide to Web Design

Summary

Generic hints, stumbling blocks, tips for exercises. Helping others on IRC. Putting test cases online.

See also the associated Link Collection.

Page Contents

  1. Yet Another Guide to Web Design
  2. Introduction to Web Design
    1. Stumbling Blocks
      1. Divitis: Too many <div> tags
      2. Positionitis: Too Much Use of position:absolute
      3. Work Clean and Systematically
      4. Clean Source Code
      5. Being Very Strict Is a Good Idea
  3. Support on IRC
    1. Getting Help on IRC
    2. Common Mistakes, Hints
    3. Web page related questions
    4. Unsorted Links
    5. Supporting Others on IRC
  4. Creating Test Cases on webdevout.net/test

Introduction to Web Design

While getting help on IRC and also supporting others, I saw a lot of people asking the same questions over and over again. Many beginners also expressed certain (sometimes deadly wrong) beliefs, so I decided to extend my Web-Design related link collection into a Beginner's Tutorial. To our bad luck, the area is quite complex and a lot of reading is necessary in order to master this craft. This guide tries to tell you the most important things, but you will benefit from reading the many pages, I linked for you.

Stumbling Blocks

A common problem for newbies using CSS is to overdo certain things. I am talking about two main issues here:

Divitis: Too many <div> tags

Many people use a lot of <div> tags in order to position the elements of their page. This has some disadvantages:

Try to avoid too many <div>s, instead apply your styles to the really needed elements. You may put a margin to a <h3> instead of wrapping it. This needs some practice of course. Also read up on separating content from style, this will improve your skill of avoiding superfluous tags.

Let me try to illustrate the idea with a little example: Your HTML should not contain things like <div id="topmenu">. Instead use a semantic description of the element, like <div class="mainmenu">. You never know, if your client will ask you to move the menu to the left side tomorrow. You also don't know, if you have to put the same menu to the footer of the page later, so using a class instead of an ID might be a good idea.

My tip: Do research on semantic markup and why to separate content from style. Start your page without design in your head and structure your HTML well - this will almost automatically help you avoid catching a severe Divitis.

Positionitis: Too Much Use of position:absolute

This problem often goes hand in hand with the Divitis problem. Beginners often try to position their elements, but don't know how the document flow works or how to use floats, margins and paddings effectively. They usually start to use position:absolute and position:relative heavily and end up with a totally broken page layout.

My tip: For practicing, don't use position at all until you gain some confidence with CSS in order to get used to other means of placing your stuff on the page. You will be amazed, how much you can do with just some borders, margins, paddings and floats! Also read up on the Box Model.

Work Clean and Systematically

When styling your markup, work yourself from the outside to the inside, start with the BODY and check if everything is OK. Then add style to the header and check for correctness, and so on. Check, how your changes affected the surrounding neighbors of the regarding element.

My tip: Try to get a feeling for the document flow. Practice to make pages, that automatically adapt to the browser's window size - this is sometimes called Fluid Design. Work in small steps and create test cases for individual problems - create your own template collection.

Clean Source Code

On production servers, you could remove the indentation (perhaps automatically) in order to improve download speed, but while developing, using indentation helps greatly navigating within the code. I don't use the TAB character for indentation, because my browser can't be configured to indent it with anything other than 8 chars per TAB. (Actually, I am using tabs, but my CMS replaces them with 2 space chars before sending the source for better debugging.) Using some empty lines every now and then can improve readability as well (of course they should carry a meaning). For certain blocks, I use comments to declare, what opening <div> the closing one is related to. Let me show you an example:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
  <head>
    <title>Web Design (Guide) - Self-PC</title>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <meta http-equiv="content-language" content="en">
    <meta name="description" content="Small guide to web design; A few hints and links you might find interesting.">

    <link rel="shortcut icon" href="/favicon.ico">
    <link rel="stylesheet" type="text/css" href="/.template/layout.css">
    <link rel="stylesheet" type="text/css" href="/.template/content.css">
  </head>

  <body>
    <div id="top"></div>

    <p class="nocss"><a href="#page_caption">Skip to Content</a></p>


    <div id="header">

      <h1><big><tt><a title="Go to the home page" href="/">self-pc</a></tt></big></h1>
      <h2>Harald's Knowledge Base</h2>
      <blockquote>
        <p>Like a man says, <q>There are no problems, only solutions.</q></p>
      </blockquote>

      <div id="search">
        <h3 class="nocss">Site Search</h3>
        <form name="search" action="/about/search.html" method="get" accept-charset="utf-8">
          <p>
            <input accesskey="s" id="idHeaderKeySearchTerm" class="term" name="keyword" type="text"
            ><input id="idHeaderKeySearchSubmit" class="submit" type="submit" value="Search">
          </p>
        </form>
      </div><!-- /search -->

    </div><!-- /header -->


    <div id="page_content">
...and so on

Being Very Strict Is a Good Idea

Some people think, I am crazy, but I really try to get my code perfectly formatted. Ideally, every indentation, empty line(s), and even wrong formatting, carry a meaning. (Wrong formatting in my code usually means TODO.) I even remove unneeded white space at the end of lines, because it reduces transfer amount and having perfect code just feels better.

Making it a habit to format your code perfectly will safe you from troubles in the future. Once it has become a routine, you will also notice, that you can spot errors more easily.

Always sorting attributes in HTML and CSS settings in the same order has advantages, too. In CSS, I am usually sorting the settings from the outside to the inside - position, width come first, followed by margin, border, padding and finally color and font settings.

The benefits are:

ToDo in this section:

Support on IRC

Getting Help on IRC

Common Mistakes, Hints

There are quite a lot of reasons, why these things matter. Read the excellent article about How To Ask Questions The Smart Way in order to find out why. Please do not ask the folks there for support - they are not a help desk, they just published a good article!

Web page related questions

When you ask #css something, then we often have to ask:

Supporting Others on IRC

Bot Codes

If you are supporting others on freenode's #css channel, you might find _ZofBot4 useful. Just type the codes shown in the boxes to make the bot display the according links/information.

You should include the nickname of the user, you are sending the message to, for having their client notify them about the incoming message:

]<botcode> @<nickname>

Validating

Sometimes, people will ask to look at their web site. Trying to fix a page with broken markup is futile, tell them to fix their code and tell them about the w3-validator. Check the last link in the channel with @, this will make the bot validate the linked page and display the result. If someone posted another link meanwhile, you can have the bot skip the new link. If only one new link is to be skipped, use:

@-2

You can also let it validate a certain URI:

@<uri>

If the validation fails, gently ask the user to repair their code first; You might send them to #html. Sometimes users can't repair the output of their CMS. In such cases you might point them to the appropriate forums or try to help them solve their CSS problem, disregarding the futility of debugging invalid markup.

Creating Test Cases on webdevout.net/test

It is a lot easier to debug a living page rather than just reading the source code, because one can use FireBug on a real page. You might ask people to put a test case on webdevout instead of using a normal pastebin with their HTML/CSS.

Firefox does not display "broken images", unless you tell it to with a non-compliant css setting. Besides this fact, test pages are easier to understand, if they actually contain an image (assumed, your test is related to images somehow). I found two cool pages, that let you simply link in dummy images, which might also be useful, when creating a new page:



Content Management:

μCMS α1.6