View full size »

I decided to do this with Javascript, but the question was:

• Should I dynamically generate the extra form fields with Javascript before stuffing them into the DOM,

or

• Should I have a separate page, containing the form fields written in plain HTML, that I dynamically insert into the form page via an AJAX call?

Contemplating the idea, I decided the best route would be to use AJAX. Here are some guidelines for making such a choice, based on the logic I used:

Are you generating a lot of code?

If you’re going to be generating a lot of code each time, like in my example, the AJAX route makes more sense because you can have a separate page (PHP for me, but you could use a straight HTML page) to write that content in HTML, then use an AJAX call to include that page in your main page. See, if you were to use Javascript for dynamically creating elements (document.createElement() and element.appendChild() are your friends here), you’re going to write a lot more code in Javascript than the straight HTML it takes to create various elements and their attributes. In my case, with Javascript I would be generating li’s, span’s, fieldset’s, input’s, and legend’s, then several of those had the attributes rel and class, not to mention the normal attributes associated with input. It’s simpler to write out the HTML for this in a separate page, rather than have lots of Javascript functions for creating those elements, applying attributes to them, assembling them together, then stuffing the result somewhere in the existing page.

Does the dynamically added code replicate content already in the main page?

In my example, the main form page started out with one course section already showing up. If I were to use straight Javascript DOM manipulation to allow the user to insert extra course sections, I would be replicating the same content in two ways: in the main HTML page, and in the Javascript necessary to generate a new course section. Being a Ruby girl at heart and a big supporter of the DRY principle (Don’t Repeat Yourself), it hurts something deep inside of me to duplicate that much functionality in my application. Well, maybe I’m exaggerating a bit, but I gotta stress this, because such replication leads to harder-to-maintain code. Any time you want to change the teensiest thing, you have two places in which you need to change it: the original HTML, and the Javascript that creates the same chunk of HTML before inserting it into your page. Going the AJAX way here would be best.

Are you adding only a small piece of HTML?

If you want the user to be able to dynamically add a single link or something equally trivial to your existing page, the AJAX route might be overkill. The Javascript necessary to generate one or a couple HTML elements isn’t overly complex or lengthy, and so it makes sense to use Javascript element generation followed by DOM manipulation to add your new content. I think it would be more trouble than it’s worth to have a separate page containing just a link or two, and then use AJAX calls to stuff that snippet page into your main page.

If your dynamic content isn’t complex now, do you foresee it becoming so in the future?

Maybe for the time being, the user only needs to insert a couple of elements into the page at his or her whim, but in the future, you think your application will expand such that large chunks of HTML will need to be added at a time. In this case, you might start off with the AJAX route just for your future convenience (or the convenience of another developer—be considerate of the next guy, right?). It’ll make your page easier to expand in the future, since you won’t have to remove all the Javascript content generation code, create a separate page to hold the content to be dynamically added, then write the AJAX calls to include that content as the user desires.

Are you using a PHP (or similar server-side language) back end?

The site I was creating my example form for uses PHP, so the AJAX route especially makes sense here, since I can make the dynamic addition of content be available for the user even if they have Javascript disabled. I’ll just use PHP to parse a POST request and decide how many course sections to include (using a loop and PHP’s include on the separate snippet page of content), based on how many they currently have and how many extra they want to add. With the Javascript content generation route, this sort of thing is impossible, because Javascript is entirely client-side, and if the user doesn’t have it enabled or their browser doesn’t support it at all, they’re up a creek. Oh sure, you could have the non-AJAX version for those with Javascript, then write functionality in a server-side language to allow the user the same functionality without Javascript enabled, but there you go again with the replication of functionality—bad programmer! If you’re stuck with just HTML, though—which I have to guess is unlikely in this day and age, what with every Tom, Dick, and Harry of hosts supporting PHP, Perl, JSP, and Ruby—you’ll need to determine whether to go AJAX or Javascript-content-generation based on the other questions raised above.

View PDF »

This is a very basic introduction on how to go about creating a web page. It was to last for about ten minutes and given to an audience of middle schoolers. See also the handout I made for them containing links to various resources.

View PDF »

This lasted about an hour, if I remember correctly, and skimmed over HTML and CSS basics before delving into guidelines for improving a web page’s appearance through CSS. The audience was my fellow college students who may have had some knowledge of HTML and CSS, but no background in professional web design.

First, we need some Javascript to go through our page and add a CSS class to every link that we want to differentiate.

Now we can style the links based on their class names. You could do whatever you wanted to with them, maybe make all outgoing links bold, whatever. For me, I like having little icons next to outgoing links or other special links. If it's a PDF document, maybe use an Adobe logo. If it's an MP3, a little music note. Get creative! Anywho, here's some CSS for sticking such little logos in after the text of a link:

I set the right padding to be the width of the icon plus 1, so that the icon wouldn't be pressed right against the text.

Things You'll Need

• Prototype for its Ajax.Updater, which will be used to update an element in the current page without reloading the page.
• You'll need PHP in order to write the script to parse URL parameters and display an image.

Image Displayer

If you try to load an image in the middle of an HTML page, your browser is going to lug along before displaying a whole bunch of crap that is the actual image source. That is, you won't see your pretty image. Instead, you need to load another HTML page that has the image in it. Instead of having a separate page for every image in your gallery, we're just going to have one boilerplate PHP script that will take parameters in the URL and display an image:

What this script is doing is checking to see if any of our desired parameters (e.g. width, alt) were passed in the URL, which is stored in PHP's $_GET superglobal. If they were, then the function calls to array_key_exists() will return TRUE, and a variable will be set for each of our attributes. The calls to htmlspecialchars() is a safety check to turn any code, such as malicious Javascript, into harmless ASCII entities (e.g. it replaces < and > with &lt; and &gt;). The calls to stripslashes() is to ensure any added \'s before quotes are removed before the text gets printed out.

After the data is gathered in this script, it is then printed out in appropriate HTML tags. The image is stuffed into an img tag, the description is printed out, etc. Now we can link to this script, which I named image_displayer.php, and pass in the appropriate values in the URL with this format: image_displayer.php?key_1=value_1&key_2=value_2 and so on with as many values as we want to define. In PHP, if a variable is not initialized to some value, if it is later printed, it just doesn't print anything at all, rather than giving an error.

Javascript

Make sure you've included the Prototype Javascript library. Then, you'll need to create some HTML element, probably a div, and give it a unique ID. E.g. <div id="gallery_photo"></div>--note that we're leaving it empty. Now, outside of that div, you can make the links to your images:

<a href="/wp-content/da/blobs1.jpg" title="Prisms" onclick="new Ajax.Updater('photo_display', '/wp-content/image_displayer.php?max_width=700&width=700&height=662&alt=Prisms&src=/wp-content/da/blobs1.jpg', {asynchronous:true, method:'get'}); return false;">
<img src="/wp-content/da/thumb/blobs1.jpg" alt="Prisms" style="width: 40px; height: 40px; border: none;"/>
</a>

To break it down, we include the image URL in the regular href section so that if Javascript is not enabled, the user will be taken to the image directly. The onclick section is where the magic happens. We're making a call to Ajax.Updater and telling it 1) the ID of the HTML element that we want to stick the result of our request, 2) the URL to our image_displayer.php to have our image displayed, and 3) that we want the request to happen asynchronously and we want to use the GET method as opposed to POST, which is typically used for form submissions.

And there you are. :) You can see this in action in my Graphic design section.

1. Javascript – It’s awesome and has led to some great web technologies. It can greatly increase the convenience of a web site. It can make fun toys and pretty navigation effects. Despite this, not everyone uses Javascript. They turn it off in their browsers because they’re on a slow connection, they’re sick of the annoyances that some developers create with Javascript, their browser doesn’t support it, it makes things choppy on the computer they’re on, or another reason entirely. Whatever the reason for not having Javascript support, if you exclude visitors by making your site very inconvenient to use without Javascript, or if your site doesn’t work at all, you’re being a snob. Stop going for the gusto with those nifty Javascript effects and just give us a plain text link, darn it.
2. Flash – The benefits and problems with Flash are pretty much the same as above. Offer some text-based site that doesn’t require the Flash plugin and be considerate of your visitors. I myself have all Flash animations hidden by default because so many sites use Flash for annoying, flashy ads.
3. Specific browser – This one is a classic because it’s been around forever, but it still persists today. Don’t assume that your visitors are going to all be using Firefox or Internet Explorer. Don’t assume those using IE will be using the latest version. Don’t assume you won’t have a few Mac users that prefer Safari. It’s safest to test your site in all the major browsers because you’re bound to have a few visitors using each.
4. Specific operating system – This isn’t typically a problem but it can still be an issue. My university’s College of Pharmacy site is a prime example. When I view the site in Firefox in Ubuntu Linux with Flash and Javascript enabled, I get no main content. I see the sidebars, the pretty header, but a big blank space where the content should be. When I view the site on my Powerbook running OS X, I get the sidebars and main content, but no header. Todd, who is a web developer for the College of Pharmacy, said this wasn’t a big concern for their designer because the majority of their visitors use Internet Explorer in Windows. That just smacks of elitism to me. I’ve often seen Linux being excluded because people think its users are a minority, but Mac users with Firefox? Come on.
5. Limiting design choices – This is a big hunk of a problem that’s very common. All too often I see sites that choose a tiny font, colors that are unreadable, background patterns that cause reading the text difficult, etc. Sometimes there’s the added problem where, if I increase the font size through my browser, the layout gets messed up. As a designer, you have to accommodate your users as well as realize that they’re lazy. They aren’t going to want to do a whole lot in their browser to be able to read your content. Increasing the font size is about as far as they’re going to go. Don’t cause them to turn off stylesheets so they can read plain text, turn off their speakers because your site plays annoying music, or take some other extra step in order to make use of your content.

You may be wondering what the big deal is. So a few users see a wonky layout, can’t navigate, or otherwise have a problem with your site, so what? Well, you made your site for a reason, be it to share your blog posts with the world, sell a product, get people involved in a project, or something else. If I go to a site and it looks bad or doesn’t work for me, I don’t have much faith in the owner. If that owner is trying to get me to read blog posts, I don’t really want to. What do I care about what this person has to say? I can’t read the fonts they chose, the words are all covered up with the sidebar that’s positioned differently in my browser, the Flash navigation has rendered it so that I can’t get to a blog post to even read it, etc. To me as a user, these problems would come across as a message from the owner telling me that they don’t really care about me as a visitor. If they don’t care about me, why should I care about them? I’ll just go read one of the other millions of blogs out there. The same goes for sites that are selling something, only it’s even worse for them because my leaving their site means that I won’t be spending my money there. It might even go so far as to mean that I’ll spend my money at one of their competitor’s sites.

The bottom line is: make your visitors happy or they’ll leave. That means accommodate them by supporting as many browsers as possible, as well as different browser configurations. If your site makes a visitor happy when they’re viewing it in IE 7 on Windows XP with Flash, Javascript, Java, and a 1600×1200 resolution, great; if your site makes a visitor happy when they’re viewing it in lynx (a text-only browser) on FreeBSD in a 80×20 terminal, great. With that said, I want to emphasize that I’m not suggesting you cow to every demand of your users. It’s not a problem if your actual content upsets everyone and makes the Pope curse your name, but it is a problem if the manner in which your content is displayed does.

This article is an extension to Clichés of a Crappy Site that I wrote in December of 2005.

[Thu Mar 22 10:55:17 2007] [error] [client 127.0.0.1] Options ExecCGI is off in this directory: /Users/sarah/Sites/test.cgi

I thought to myself, “B.S.! ExecCGI is on for that directory!” Sure enough, in my httpd.conf file, I had:

<Directory /Users/*/Sites>
    AllowOverride FileInfo AuthConfig Limit
    Options ExecCGI MultiViews Indexes SymLinksIfOwnerMatch Includes
    DirectoryIndex index.htm index.html index.cgi
    <Limit GET POST OPTIONS PROPFIND>
        Order allow,deny
        Allow from all
    </Limit>
    <LimitExcept GET POST OPTIONS PROPFIND>
        Order deny,allow
        Deny from all
    </LimitExcept>
</Directory>

I had restarted Apache with sudo apachectl graceful, so what was up? Then I noticed something else in error_log:

Processing config directory: /private/etc/httpd/users/*.conf
Processing config file: /private/etc/httpd/users/sarah.conf

What was this /private/etc/httpd/users/sarah.conf that it was talking about? I had never created this file. I checked and it certainly existed. It also had an Options line without ExecCGI—bingo! I simply removed the file because it was just redefining what I had already specified in httpd.conf for Users/*/Site directories (shown above). I then restarted Apache and voila, my scripts worked. :) I can only assume something auto-generated that file, because it certainly wasn’t me.

Other things to check if you’re still seeing the source of your scripts or getting a 403 error:

• Is your script executable? Chmod it to 755 to be sure.
• Ensure these lines are uncommented in your /etc/httpd/httpd.conf (or whatever your Apache config file is):
  • LoadModule cgi_module libexec/httpd/mod_cgi.so
  • LoadModule perl_module libexec/httpd/libperl.so
  • AddModule mod_cgi.c
  • AddModule mod_perl.c
  • AddHandler cgi-script .cgi .pl
• Be sure to restart Apache after making any config file changes. You can do this via Terminal with the command sudo apachectl graceful, which will prompt you for your password, or via System Preferences > Sharing, where you Stop “Personal Web Sharing” and Start it again.

Creating a Custom Shape

1. Create a blank 200 pixels x 200 pixels image. Select the Rounded Rectangle Tool and set its radius to 30 px.
   
2. Draw a rounded rectangle that takes up the whole image.
   
3. Choose the Rectangle Tool and select the Add to Shape Area button.
   
4. Draw just any old rectangles in the top right and bottom left corners. This will add the areas to the path.
   
5. In the Path window, choose the path of the shape you’ve just constructed. Go to the Edit menu and choose ‘Define Custom Shape…’. Give the shape a name and click ‘Ok’.
   

Using the Shape

1. Open another image.
   
2. Duplicate the background layer and delete the original. You will be left with ‘Background copy’.
3. Choose the Custom Shape Tool and select your shape from the drop-down menu on the right.
   
4. Draw your shape from the top left corner to the bottom right. It will be created in a new layer above your regular image–this is fine.
   
5. In the Layers Dialog, grab the shape and drag it down onto the layer that has your image.
   
6. Now you can delete the shape layer, leaving only your image layer.
   
7. Voila! Now you have your image with the custom rounded edges that you designed.
   

The example images link to the web sites from which I took the screen shot.

Text

Tiny fonts

The purpose of writing anything is for it to be read, eventually, by somebody. Don’t make your font so small that nobody can read it without a magnifying glass. It may look more attractive somehow, maybe, because it’s ass tiny, but text that is large enough to be read can be just as aesthetically appealing.

Example:

Not only is this text very small, it’s also in a color that makes it even harder to read.

Another example:

This one illustrates another point: if you’re going to have a very small font, at least make it sans-serif (i.e. a font like Arial or Verdana, not Times New Roman). At such small sizes, it’s better to not have the little curlicues that a serif font has, to improve readability.

Small line-height

This one often goes hand-in-hand with small text. Having the line-height so small that your lines of text overlap is not cool, nor does it make your writing particularly easy to read. It pains my eyes to try and read text that is all squashed together. About 1.2 is recommended, according to richinstyle.com.

Layout

Huge images before reaching the content

Not everyone has a gigantic resolution. If you have an image sitting above your content that’s taller than about 400 pixels, you’re just wasting our time. Most of the time the image isn’t going to be seen anyway, since the visitor will be scrolling through your content further down the screen.

Itty bitty iframes

I don’t understand the point of having parts of your site sectioned off into small blocks with their own scrollbars. One scrollbar (i.e. the main one on the browser window) is enough. Having multiple scrollbars just gets annoying for me.

Skinny columns of text

Having a column of text that’s only 200 pixels (~2.8 inches) wide is not convenient. Think about how a novel is setup: the text spans at least 3.5 inches, and that’s at a smaller font size that allows about 60 characters per line. If you make the font size large enough to be read comfortably on a computer monitor, at least 4 inches would be nice so that the visitor isn’t continuously jumping to new lines.

Cluttered appearance

The adage “keep it simple, stupid” makes sense in web design, too. The page layout should be logical and allow the eye to flow from one thing to another in a leisurely way. It should in no way cause confusion about what to do, how to do it, or what things are. Space is just as important as content: don’t have everything squashed up together. Put in padding and margins and blank space. There should be a consistent look to things to tie the page together and make it less confusing.

The page scrolls on forever with no content

If there is no content in a section of the page, then the visitor ought not have the option to scroll to that section. It’s pointless. This applies to both horizontal scrollbars, which are usually accidentally caused, and vertical scrollbars, which are usually because the designer specified a huge height on some iframe to make sure all their content showed up without having a second scrollbar. Silly. Just slap in a div, position it as necessary, and let the browser determine the height.

Colors

Really bright colors

Some layouts done with neon colors are pretty because they’re coupled with darker colors, or they just aren’t overused. If you use a lot of bright colors all together, though, or do something goofy like put white text on a cyan background (see example), you’re going to hurt eyes and cause your visitors to just leave, rather than blind themselves trying to visit your site.

Example:

Contrast

If you put light gray text on a white background, it’s going to be hard to read. If you put light pink text on a light pink background, it’s going to be hard to read. You get the idea. All writing on your site, including both plain text and links, should be easily distinguishable from the background. What’s the point of writing something if no one can read it?

With this in mind, too much contrast can also be annoying. It personally bothers my eyes to read a great deal of text if it’s absolute black on a white background.

Other

Designing for only one browser

Your visitors are going to be using a variety of browsers. Some people will be using IE, some Firefox, some Safari, some Opera, some Mozilla, and a few are going to be using browsers you’ve never even heard of before. You should at least check your site in the major ones so that you know your site looks good for the majority of your viewers. There’s nothing sillier than proclaiming that your site “only works” or “works best” in –insert browser name–. That’s just snobby. Your site should work equally well in any given browser that is common for your site’s demographic.

Different cursors

I find it annoying when I hover on a link and see a crosshair, a question mark, or any other cursor that my browser didn’t choose without the designer’s influence. The only time I think it’s acceptable for a cursor to be changed is for an acronym or abbreviation, where a question mark cursor can make sense to help differentiate from plain text.

Requirements

• You need PHP support on your server. An easy way to test this is to stick <?php phpinfo(); ?> into a .php file, upload that file to your server, and load it in your browser. If you get a huge table with information about your PHP setup, then you know you have PHP support. If you get a blank page, then you don’t have PHP. :(
• Knowing some CSS would allow you to further customize the look of the page, but it isn’t required.

Try It and Get It

• View a sample gallery
• Download .zip file (11K)
• Download .tar.gz file (8.5K)

Features

• Loads of variables that you can edit to customize the behaviour and look of your gallery.
• Acts intelligently if you throw garbage at it. Example: if the visitor tries passing a bad argument (letters, numbers less than zero, numbers larger than the number of photos in your gallery, etc.) in the URL, the gallery loads either the main page, the first image, or the last image, depending.
• Generates valid XHTML 1.0 Strict code that is neat to look at (try viewing the source of the sample gallery). Valid CSS comes by default, too.
• Comes with a simple design (graphics and CSS included) so that you can get your gallery going immediately–just supply the photos and thumbnails!
• Many things are determined automatically, such as image sizes and names, so you don’t have to spend time changing unnecessary variables.
• Choose between plain text navigation, images, or both.

Source Code

If you don’t want to install the gallery, you might still be interested in viewing the source code.

Benefits

• I can update everything from anywhere.

  If I take a notion to change my autobiography while I’m visiting relatives, I don’t have to mess around with saving any files to edit them, uploading them, and then remembering to update my copy on my computer when I get back home. I can just log into WordPress and fire away. My whole site is at my fingertips for any changes I want to make.

• Consistency.

  Even though I used PHP when I was maintaining all my pages by hand and so layout changes were a breeze, some people don’t have PHP or any similar programming language at their command, and so a CMS would be a perfect choice in order to keep all the pages looking the same.

• Community.

  I mean two things by this: one is the community that forms around your whole site when feedback is allowed and displayed on almost every page (a feature that I know WordPress offers pretty easily), and the other is the community that supports and expands your CMS of choice. There are a ton of plugins, themes, hacks, and tools made just for WordPress that are easy to implement, thus allowing me to have some nifty features on my site without having to write them myself.

• Organization.

  It’s great when I can change the name of a category and have all the links throughout my site that point to that category be updated immediately. It’s also nice when I can have archives of old posts, and then have those archives linked to on every page. I edit one thing and everything related to that thing is updated to reflect my changes, and I don’t have to tell it to do so. Having such things taken care of by the CMS allows me to focus on the content and appearance of my site, which is what I care about.

Drawbacks

Those benefits above make up for the few drawbacks that I’ve seen:

• Less control over individual pages.

  All pages are treated the same, which is usually a good thing because you want a uniform look and feel to the site. If I want a particular page to look or act differently, however, this is a problem. I can make a stand-alone page and merely link to it, but then what happens if I want a few things on that stand-alone page to be like the rest of my pages, such as its design? I can’t very well just write out the same HTML and CSS that configures the look of the page, because I support skins and my visitors might be using a different skin. So I could write out a skinning tool just for that one page, but then what if I update the navigation on my other pages? I’d have to go back and keep this one stand-alone page up-to-date, and that becomes a hassle. That’s why I moved away from maintaining all pages by hand in the first place: I don’t want to deal with the logistics of how a site is set up, but instead what it’s made of and how it appears.

• If one thing goes down, it all might fail.

  I used WordPress a few years ago to maintain a blog but dropped it like a hot potato because, one day, I went to my blog and all I found was an error message. Something about MySQL and PHP, I think, but I never could fix the problem. It might’ve been a problem with my database or with WordPress itself, but whatever went wrong caused the whole page to not display. None of my blog archives or categories were available, either. With all your pages being stand-alone pages, if one page has a problem, it’s a very isolated problem and it shouldn’t affect the rest of your site. A few visitors may be inconvenienced when they’re trying to read the history of Harold, your pet hamster, and find the page is down, but they can still read your political commentary, so it’s all good. If the main system of your CMS goes down, for whatever reason, then visitors can neither read your pet’s history nor your opinions.

Indentation

Indenting your code, usually by a tab or with spaces, makes it much easier to read because you can tell what sections are inside others (i.e. what is a child and what is a parent). Example of ugly, unindented code:

<div id="head"><div class="title">My page <img src="john.gif" alt="My Page"></div>
<a href="http://www.google.com/">Google <b>is great</b>
   </a></div><div id="main"><p>My
stuff</p></div>

Now because that’s such a short segment of code, it’s easy enough to look and understand. However, if you have 300 lines or so of stuff like that, you’re going to get a headache and you might miss some otherwise obvious errors that you’re trying to correct. Example of cleaner, indented code:

<div id="head">
 <div class="title">
  My page
  <img src="john.gif" alt="My Page">
 </div>
 <a href="http://www.google.com/">
  Google <b>is great</b>
 </a>
</div>
<div id="main">
 <p>My stuff</p>
</div>

Now it’s easy to tell that the “title” class is nested inside the “head” ID, and that “head” and “main” are separate. In the future, if I edit this code and the page no longer displays how I want it to, it would be a simple thing to come back and realize that I must have left out a closing </div> or didn’t put my “footer” ID outside of the “main” ID, because of how the spacing lines things up.

HTML isn’t the only thing you should indent: CSS is a prime candidate for indentation. Example of ugly CSS arrangement:

body {font-family: "Verdana", sans-serif; background-color: #fff; color: #000; line-height: 130%; font-size: small; margin: 0;}

And here’s that same code, neatly indented with tabs and organized:

body {
     margin: 0;
     background-color: #fff;
     color: #000;
     font-family: "Verdana", sans-serif;
     font-size: small;
     line-height: 130%;
}

I have a tendency of indenting entire sections if, within the HTML, they are subsections. Example:

#head {font-size: 150%;}

     #head div.title {
          font-size: 90%;
          color: #494949;
          border: 1px solid #999;
     }

#main {
     font-size: 80%;
     font-family: "Georgia", "Times New Roman", serif;
}

Since the “title” class is within the “head” ID in the HTML code, I indent the styling for the “title” class so that it looks to be a child of “head”.

It’s really not hard to keep up good indentation practices, especially with the help of a good editor. I recommend Bluefish, Vim, or Dreamweaver.

Documentation

The next step in making your code more readable is to explain things that might otherwise be obscure. A habit of mine is to note which <div> is ending when I put in the closing tag, if the tag is not on the same line as the opening tag. Example, using the above code:

<div id="head">
 <div class="title">
  My page
  <img src="john.gif" alt="My Page">
 </div><!--End of class title-->
 <a href="http://www.google.com/">
  Google <b>is great</b>
 </a>
</div><!--End of ID head-->
<div id="main">
 <p>My stuff</p>
</div><!--End of ID main-->

Again, this may not seem necessary for this small bit of code, but when you’re dealing with several <div> tags that are nested within each other and mixed in with other code, this can be very helpful. Without such comments, you might remove the wrong closing tag for a <div> that you don’t want removed. I don’t comment the opening tag because it isn’t necessary: the class and id attributes are explanation enough.

Other useful documentation can be to explain what a particular section is for, if it isn’t already clear:

<!--This will hold the date and time that I last updated-->
<div class="dtlastUp">
 06.23.05 - Thursday<br>
 3:12 P.M.
</div>

Documentation is especially important if someone else is going to be looking at your code. If you’re running an art collab with a friend and you each have your hands in the source, you don’t want to be left baffled by their wacky coding, wondering why on earth she used an inline <h1> rather than just a <span>.

Consistency

Neat code is consistent. Don’t start out indenting with a space and halfway down the page indent with a tab. If you put comments describing the appearance of each <div> tag on one page, do it for the other pages. With your CSS, if you start having the opening bracket on the same line as the body section, then keep it on the same line for all the sections. If you make your main header be a <div> of a specific class and not an <h1>, then make all the main headers of all your pages use that <div> with its specific class.

Having code that is consistent in its appearance makes it easier to debug. If a page isn’t showing up correctly and you’ve coded the page in a neat fashion, consistent with spacing and the naming of things, then it might be possible to find the error with a cursory glance at the code. You won’t have to weed through pages of a jumbled-up mess in order to find that you didn’t close that <table> like you thought you did.

Logic

The most illogical thing I see in web design is the misuse or bizarre usage of different tags. Just because you can make a page look pretty by using nothing but the <span> tag and some wild CSS doesn’t mean that that’s the best option. The following are some common oddities:

Lists

If you want a list of items, use either <ul> or <ol>; don’t just make a list of items separated by <br>’s. You have more control over your content if it is in a list than if you just have a bunch of lines and breaks. For example, using CSS you can change the bullet image, the line-height, borders, colors, fonts, whether the list is displayed inline or one item per line, padding, margins, and so on. If you just have things separated by the <br> tag, then you’re going to have stuff all that into another area, perhaps a <div> or a <p>, and use CSS to style that to get the same effect. And as for bullets or numbers or images alongside each item, well, now those you’ll have to put in by hand. With <ul> and <ol>, they’re there by default.

Paragraphs

There is no need to have a block of text separated by two <br> tags to create the look of a paragraph. There is a specific tag for this: the <p> tag, and she is your friend. Use her! I have no idea why people want to use <br>’s for this purpose. They are intended to create a line break, which is not the same as ending a paragraph. Maybe because having two <br>’s generally makes a larger space than just closing and opening a <p> tag. That’s something that is easily changed with CSS:

p {margin: 15px 0;}

That will make it so that there is a margin of 15px above and below each <p> tag. You can change that to 150px for all CSS cares. See? The <p> tag offers you more flexibility, which is always a good thing.

Tables

The purpose of tables is to hold tabular data, like the billing records from the month of April for a few customers. Tables are a poor way of designing a layout, but it’s done all the time. Using <div> tags and some CSS (mainly the float property) is preferable. One reason this is so is because tables don’t resize worth a two-dollar whore. If you specify a table width because your layout’s main image is 847 pixels wide and I resize my browser to be only 842 pixels wide, then I’m going to get a horizontal scrollbar and that’s annoying. However, if you use <div> tags with some CSS, you can have it so that the sections of the page either resize with the browser, get cut off at a certain width, or flop down to a different position on the page. All of those keep that horizontal scrollbar from appearing.

More information related to this can be found in HTML Dog’s Mastering Text article.

“So many webmaster/mistresses on the web are so afraid of having their code stolen. Does it really matter?” yes, I think it does matter. Particularly for people like myself who spend hours and hours perfecting cross-browser compatible layouts for the Internet. I don’t want my code stolen.

That prompted me to write this article.

I whole-heartedly support the idea of looking at someone else’s source to see how they did something. As long as you don’t reproduce my work exactly, I encourage you to look at my source, see my coding techniques, and figure out why I used a <div> there and a <span> there.

The thing that hath been, it is that which shall be; and that which is done is that which shall be done: and there is no new thing under the sun.
–Ecclesiastes 1:9 (KJV)

Well, there are no new things on the Internet, either. The HTML that I use to code this page is all open source stuff. It’s all standard, and it’s all public. The innovation of this site does not lie in the specific tags and attributes of my code, but in how I arrange those things. Therefore, look at my source to see how I did something, and then use that information to make your own innovations. Don’t copy my ideas verbatim, but instead learn from them and use your own ideas.

I got my start in web design by seeing something I liked in another person’s site and then trying to implement a similar thing on my own. I learned HTML by imitating the HTML of others; the same with CSS and PHP. Those first attempts at getting that weird <body> and </html> stuff to actually produce a web page are frustrating enough to a newbie without having the fear that someone is going to get pissed at them because they clicked View Source.

There are a ton of shitty sites out there. You might consider it an act of good will toward the web community at large in encouraging others to view your source and learn from it, if you’ve a good opinion of the code you write. Let all those sites with #00FF00 text on #FF00FF backgrounds take a look at your pretty CSS and see how an attractive site should look!

Another argument is that one learns how something is put together by taking it apart. If I save your page to my hard drive, open it up in an editor, and start removing pieces at random, I’m going to discover what makes each part of the page look the way it does. Your source proves a powerful learning tool for the inexperienced.

Another reason why someone might look at your source is because you, the coder, are an idiot. If you’ve got those annoying Javascript mouseovers that change my status bar text and I can’t tell what URL I’m going to go to if I click that link, then I’m likely to dig around in your source to figure out where the heck you’re trying to take me.

There is no reason to want others not to view your code. What, are you ashamed of it? No? Then show it off! Insist that every Tom, Dick and Sally take a gander at your madd cOdInG skylz! It isn’t the viewing of the code or even the taking of the code (this is starting to sound like some arcane bible…) that’s so frustrating to people who value their source, but the misuse of it. Don’t select a chunk of my page source, copy and paste it into your file, and upload that file claiming that that is your work. Don’t even slap it up there and acknowledge that you took it from me. If you’re going to go to the trouble to dig around in somebody else’s work, at least have the decency to personalize it. Make it look different, act different, be different from what I have already created. But certainly don’t hesitate before clicking that View Source option.

Why Should I Care?
It’s an easy bit of code to throw in and yet it’s quite helpful. Here’s why:

1. Not all web browsers can display images. (Text-only browsers such as lynx and links come to mind.) Image-challenged browsers will instead display the text in your alt attribute.
2. Not all of your visitors can see images. There are programs designed specifically for helping blind users surf the web. Your pretty images without alt attributes don’t do jack for these users. However, if an alt attribute is specified for an image, said alt attribute can be read aloud, via their special program, to the visually impaired user.
3. They get you hits. Search engines check your alt attributes. If someone does a search on Google for “chocolate eagle superman” and the only place in the world that such a thing exists is in an image of yours, you’d dang well better have an alt attribute saying “This is a photo of my chocolate eagle superman” so that search engines can find it.
4. Gotta have ‘em to be valid. If you want your site to be valid HTML 4.01, XHTML 1.0, or XHTML 1.1, you must have alt attributes for images. If you don’t have alt attributes, the W3C validator will give you a message like this: “Line 9, column 34: required attribute “ALT” not specified”.

Basically, if you want to make your web site as widely accessible as possible, you want alt attributes.

Make Them Worthwhile
So many times I’ve gone to a site, viewed the source, and have seen that the owner used alt attributes, but that they were pretty worthless. If you have a big photo of Natalie Portman as part of your layout, don’t just stick in an empty alt attribute so that your site will validate. It’s a cheap way of being able to brag, “Whee, I have valid code!” and it isn’t helping anybody. In your alt attribute, stick a short description, a title, something related to your image or <area>.

Further Reading
More information can be found in the W3C’s Use the alt attribute article as well as in Web Pages That Suck’s Google Is God, Don’t Piss Her Off article.