Web Tips for Webmasters

Rule#1: Be Standard

Many web sites make use of non-standard features, such as JavaScript or Flash, when they are not necessary. Remember that there are more than two browsers in the world, so you're excluding viewers when you do this.

• Use standard HTML unless the content requires otherwise.
  I could write a book on this one rule. The key word here is "standard". The more standard your code is, the more people will be able to see our site.

  To break it down:
  

  • Do not use Flash or Javascript unless required (i.e. the site is a cartoon site and you can't do the animation without it).
    My biggest pet peeve is when a perfectly good link is done in JavaScript. If you need to open a new window, use "target": <A HREF="mypage.html" TARGET="NewWindow"></A>
    Target pops up a new browser window and puts your linked-to page in it. It's not as clean as a window you can open with JavaScript, but your window will actually open, in ANY browser.
  • Use broken-up images, not image maps, when possible.
  • Refrain from using frames unless necessary.

Rule#2: Don't Try To Force The Browser

I see a lot of web sites that lock their content into a neat little width-restricted table. While trying to control your layout is an amicable persuit, it's a fight against the fundamentals of the web, and you end up constraining your content. I espouse what we call "Dynamic Document Layout". (No, I don't call it DDL for short).

When you're programming HTML for a web site, you're not laying out a page - you're explaining to a browser what the content of the page is and how you'd like that content arranged on the page. Many webmasters are trying to layout their web page as a graphic artist would. Traditional graphic artists are trained to work in a fixed-space medium. That is, you've got a page with a certain width and height. Hence, a lot of webmasters will create a table and fix its width (the height is pretty-much dictated by the content). Unfortunately, this forces people with small screens, or who don't want to maximize their browser window, to scroll back and forth to see the whole page. With Dynamic Document Layout, you're formatting your page to work in a Dynamically-Sized medium (a browser window). In HTML you can actually format a page to look good no matter what size the viewer sets his window to. Also remember that the viewer can change their colors, fonts, etc, so your level of "control" is even more limited.

Instead of trying to layout the page yourself, imagine as though you're explaining to a graphic designer how you'd like things laid out.

"I'd like this to be a heading, and it should be centered. Underneath that, on the left side we'll put a navigation bar with links to the other pages on the site, and on the right we'll put the content."

That would look something like this:

    <H1>My Great Heading</H1>
    (The heading - we're telling the browser this is a level one heading.
    Different browsers will format this in different ways)

    <P>  (Start a new paragraph)

    <TABLE ROWS=1 COLS=2> (Begin our table - it has one row and two columns)
      <TR>  (First row)
        <TD>  (Start first column)
          <A HREF="index.html">Home</A><BR>
          <A HREF="apage.html">A Page</A><BR>
          ...
        </TD>  (End of first column - our nav bar)
        <TD>
  
          Body text goes here...
  
        </TD> (End of second column)
      </TR>   (End of first row)
    </TABLE>  (End of table)
    

HTML is not for the control freak. You have very little control over how a browser will choose to layout your page. The best you can do is to give it clear directions. You can test your page in IE and in Netscape, but then you're not testing it in AOL or any of the many other browsers that are out there.

Rule#3: Be Careful

Cookies can be used to track basic user data for shopping carts, etc. But if you're not careful, hackers can use your well-intentioned pages for more malicious purposes. Imagine a site that stores a simple cookie called (for simplicity) COOKIE with a user id or some sort of ID to identify the user to the site owner (ie. for repeat visits). Now when a user visits, a feature of the website could be to track where the person previously visited, store this information in an SQL database, and give them a small "history" of their most requested pages to make it easier for them to find something. For the most part, this could be a simple SQL lookup "SELECT pages FROM database WHERE user=${COOKIE}." Simple enough? Well let's just say that Joe Hacker comes and visits your website and "supplies his own cookie" to your webserver with his own malicious content... can you see where this is going? Many sites have been compromised and a lot of extra data gleaned by hackers "rewriting" SQL statements through the addition of their own code and values. In short, if you need to use them, make sure that they are done in such a way that someone can't hand you <any> unexpected values. (imagine what would happen if someone handed your script a cookie that, instead of containing just a user id contained something like the user id followed by ";SELECT * from database;" -- think they have a chance at getting a little more info than other visitors, here?

This problem is true of any CGI script that uses input from the browser, whether it's in a POSTed form, a URL, a cookie, or even an environment variable. Make sure you carefully screen any browser- or user-supplied data!

Summary

It isn't difficult to code a page well. Just remember the fundamental rules:

• Do it in standard HTML unless the content requires something else.
  
• Explain the content to the browser, don't try to force it to lay the page out your way.
• Be really careful with CGI.

Web Tips is written by Grant Grueninger, President of Commercial Systems Corporation. Grant has over 22 years programming experience, and has been working in the computer industry since 1979.
Web Tips © 2001 Grant Grueninger, Commercial Systems Corporation. Security Tip (Rule#3) by Russell VanTassell, Commercial Systems Corporation.