Use ASCII mode for HTML FTP transfers

TIP: Transfer HTML documents and other text-based files in ASCII mode, and transfer graphics, sounds, and executable programs in BINARY mode.

When uploading or downloading HTML files using an FTP (File Transfer Protocol) program, always use ASCII mode rather than BINARY. The reason for this is that different operating systems vary in how they represent line breaks. MS-DOS and Windows systems use a carriage return followed by a linefeed (ASCII characters #13 and #10) at each line break, which is the traditional standard dating back to 1960s Teletypes which needed both characters to get the terminal to both move the carriage to the left margin and move down a line. Developers of some operating systems have decided that this is wasteful and a single character would suffice, but unfortunately they weren't consistent: UNIX ended up using a linefeed (#10) alone (which Unix developers refer to as a "newline" character), while Apple computers (both the old Apple II line and the Macintosh) chose the opposite course of using a carriage return (#13) by itself.
The result is that there are three different ways of denoting the end of a line, and software can fail if faced with a file that is delimited in a manner different from your operating system's convention. For instance, Windows Notepad will discard all line breaks if they're nonstandard, producing a file that's all on one line. (Perversely, this Notepad bug doesn't show itself until you've first loaded the file, which looks fine initially, then saved it; at that point, the line breaks collapse so the next time you load the file it will be messed up.) To avoid these problems, the FTP protocol was developed with an "ASCII mode" that converts line breaks to the appropriate style for the destination system. When you're sending from a UNIX server to a Windows PC, it adds a carriage return before each linefeed. Transferring the other way, it strips the carriage return. Transferring from UNIX to a Mac, it converts the linefeeds to carriage returns. Thus, the integrity of the file is maintained no matter what systems it's transferred between.
It's possible that file transfers in ASCII mode may perform other conversions depending on your system. Perhaps special extended characters will be converted from your system-specific values to the ISO standard (see my section on character sets). If so, this may enable you to edit text files with special characters in your word processor and store them in a manner that works on the Web, but watch out for unwanted conversions of characters you didn't want to alter. Check your FTP program's documentation for details.
Be sure to use BINARY mode instead if transferring non-text-based files such as graphics, sound files, and executable programs. Most FTP programs let you set extension recognition to use the proper mode for different file types. Set it to use ASCII mode for .htm, .html, and .txt files, and any other text-based files you may be using: style sheets (.css), image-map data (.map), CGI scripts in PERL or UNIX Shell (.pl, .sh, .cgi), program source code (.c, .h, .pas, .java), etc., and use BINARY mode for everything else (.gif, .jpg, .jpeg, .exe, .wav, .class, etc.)

You don't have to show off how many "neat-o" tricks you can do!

If your Web site is trying to communicate information about a subject, it may detract rather than enhance this if you try to "show off" by loading it with Java applets, animated GIFs, blinking text, a kaleidoscope of colors and fonts, a profusion of frames and tables, a MIDI background sound with a stolen pop-song melody you hope you don't get sued over, and every other fancy trick you've learned how to do. But does your Web-based chart of the schedule of your upcoming convention really gain anything by having an embedded applet giving the current time in Outer Mongolia? Unless the whole purpose of the site is to show off your bag of Web tricks, it may be better to "keep it simple, stupid!" (the [in]famous "KISS Principle") and stick to the content, presented in a straight, logical manner, with a few carefully-chosen visual enhancements designed to emphasise the important parts of the site rather than distract the user from them.
It can be a big turn-off to a user when, upon entering a site, there are long delays with status messages like "Loading Applet", "Loading Plug-In", etc.; some popular browsers implement such things so poorly that the user loses control of his/her browser for an indefinite period while all the fancy stuff loads and initializes, unable even to scroll in the page or use the "Back" button to get out of it. And sometimes the browser even crashes, especially if memory or disk space is getting low. Are your "snazzy" effects really worth that?

Note: One of the stupidest "page enhancements" site authors use is JavaScript code to insert the current date on a page. The apparent intent is to make users think the site is up-to-date because it's got today's date in it; this is dishonest if the site has in fact not been updated lately. Anyway, the date shown by such a client-side script will be the user's system date, not necessarily the date where the site is located. If the user is in a different time zone or has incorrectly set his or her computer's clock, the date might not even be appropriate for the site. And if the user has disabled JavaScript, the date won't show at all. It's better to update the date by hand when you change the site (as I do with my pages), or use a server-side script or server-side include to generate it automatically. This will produce a date display that actually relates to your site, instead of recapitulating the date the user can get elsewhere on his/her own system.

It was a source of some pleasant amusement that some of these JavaScript date routines were programmed so carelessly that they weren't Y2K-compliant, and showed such years as 1900, 2100, 19100, or 20100 (among other bogus values) when the year 2000 arrived.

One JavaScript "enhancement" I'm coming to really hate these days is the tendency of some pages to set the user interface focus to a page element -- for instance, to put the cursor in an input field, rather than just letting the browser and operating system set the focus by its usual rules. This can be really annoying -- for instance, while a page is still loading, I might click on something else, like the "Location" field (where I'm starting to type the URL of the next page I want to go to), but as soon as the current page finishes loading, its scripts run and move the focus to an input field somewhere in the page, making what I'm typing in the address field wind up in the input field instead. Or I've sent the browser window into the background so I can work on something else in a different window while it finishes loading, but it insists on sending itself to the foreground before I'm ready for it. Please don't mess with my focus; let me focus on what I want to focus on, OK?

---

A 'reply form' is NOT a 'guestbook'!

A guestbook is a feature, present on many Web pages, that lets a user type comments which get posted to a page on the Web site, so that visitors can see what comments other visitors have written and leave notes of their own. It's kind of like a graffiti wall. (See my guestbook!)
A reply form, on the other hand, is a form users can fill in to leave a private message to the Webmaster. They're used on many sites to let users give feedback to the developer, as well as on commercial sites to let potential customers request more product information, etc.
Many Web sites, though, have a link labelled "guestbook" that actually goes to a reply form which sends information to the developer, not to a publicly-posted page. This is sloppy and misleading terminology. I can understand why some sites (especially commercial ones) would prefer not to have a public guestbook where people might post nasty or obscene stuff that would reflect badly on their business, but they shouldn't claim to have a "guestbook" in that case. "Feedback" or "Reply Form" would be a better link title. (However, I've actually run into some sites with so-called "guestbooks" that aren't even feedback forms -- they simply have fields to type your name and email address, or maybe your postal address too, but no place to write any sort of comments. They're just a means of attempting to harvest addresses of suckers to spam, probably. (On the other hand, real guestbooks are increasingly becoming targets of spam, especially when they let people post Web links... a distressingly high proportion of guestbook entries these days tend to be links to porn or make-money-fast scams, with generic comments like "Nice site!" pasted in to make them seem like real feedback.)
If you're wondering how to set up a guestbook or a reply form in your site, this goes beyond the scope of these Web tips; it involves use of a CGI script rather than just simple HTML. You'll have to check with the administrator of your server to find out what scripts are available for your use; there may be response form or guestbook scripts already in place, and the administrator can tell you what you have to do in your HTML documents to refer to them.

Hall of Shame

Make your site better by looking at other sites that show, by example, what not to do!
NOTE: The inclusion of a site in my "Hall of Shame" links should not be construed as any sort of personal attack on the site's creator, who may be a really great person, or even an attack on the linked Web site as a whole, which may be a source of really great information and/or entertainment. Rather, it is simply to highlight specific features (intentional or accidental) of the linked sites which cause problems that could have been avoided by better design. If you find one of your sites is linked here, don't get offended; improve your site so that I'll have to take down the link!

• This page uses JavaScript to pop up an alert when you move the mouse over any link. This ends up making it impossible for users of some browsers to actually follow any of the links, since you have to move the mouse away to close the alert box. At least, that's what happens in the Mozilla browser that I was using when I first went there; this seems to have been fixed in later Mozilla versions, since I currently have no problem following the links.
• B*Witched generates the copyright notice at the bottom of its splash page by JavaScript that inserts the current year, which is bogus; the copyright doesn't change just because you accessed the page in a new year. If you turn off JavaScript, I guess the page isn't copyrighted at all. (Yes, I know that the current copyright law actually protects even things with no notice...)
• The DHMO site always claims to be updated on the current date (even if it's actually been a decade since they've changed anything). But it's a "joke site", actually, so I guess they're excused.

Links

• Test suite for the OBJECT element -- see how well your browser supports this construct.
• AltaVista Discovery -- Has lots of functions, including the ability to generate a graphical map of the structure of a Web site.
• eXTReMe Tracking lets you see statistics on the visitors to your site.
• Linking Rights -- an article on whether somebody can legally bar you from linking to their site.
• A:hover and Linked Anchors -- info on fixing a minor annoyance regarding various browsers' treatment of named anchors when you're using the "hover" attribute in a stylesheet
• Freebieland Webaster Resources -- various free stuff of interest to webmasters.
• WebTemplates has free, downloadable templates for Web sites. The HTML even validates (that surprised me!), though I don't care for the templates' extensive use of absolute pixel-positioned elements instead of letting things resize gracefully.