Area 51 Research Center

Web Style Standards

by Glenn Campbell
Version 1.03
2/17/96

© 1995, Glenn Campbell, PO Box 448, Rachel, NV 89001. Users may feel free to link this document from their own web pages and obey these rules, but the document itself is copyrighted and may not be reproduced without permission. May be copied to a local hard disk only for personal use.

Below are standards that all pages in the Area 51 web structure are expected to follow. These rules are always under development, and suggestions are encouraged, but once the rules are in place, they are the law. If we encounter a situation the rules do not adequately cover, then we must change the rules to accommodate the difference, not disobey them.

Most of this standards would be appropriate to all web pages anywhere on the web. However, a few rules apply only to the Area 51 Research Center--marked Company Rule and other sites may choose to deviate from them.

On this page:

1.1 General HTML Standards

  1. Page index. When a page becomes larger than a few screens, add an intra-page index to the top of the page in the same format as at the top of this page. (Internally, it should follow the same format as well, with every item given a separate source line starting with "<a".) This list should be a normal paragraph, not centered, and may extend over several display lines.

  2. Be Conservative with Netscape Tables. Use Netscape <table> format only with caution. In index pages, make sure the text also looks okay in browsers that ignore the <table> formatting codes. If a table in any page unreadable in non-Netscape browsers, an indication that the page requires Netscape should be printed in readable form at the top: This page may require Netscape. (In a small font so as to not interfere with Netscape users.) Netscape-only tables should be used only for relatively minor endpoint documents.

  3. Format of label names. The names of all internal labels should be...

  4. Use of Italic Formats. Several commands generate italics in Netscape: <i>, <em> and <cite>. They should not be used interchangably. Each has a different function, and their proper use depends on how they would appear in a hypothetical text-only browser. Although few such browsers exist, it is important to maintain these standards for when an html document is translated into a text-only document.

1.2 Page Layout & Appearance

  1. Separate hotkeys with "|". When different hotkeys are adjacent to each other in an index, separate them with a vertical bar | instead of a comma, which is difficult to see the color of. (See index list above.) In running text where the vertical bar would be inappropriate, try to separate adjacent hotkeys by more than a comma if possible.

  2. No space after <li>. In lists, there should be no space or linefeed between the <li> tag and the first character of text. (The space is handled inconsistently by different browsers.)

  3. No <li> outside lists. Do not use <li> outside of a <li> or <li> list, as this is handled inconsistently by different browsers.

  4. Titles are in Mixed Case. The text of all header and title lines should be Mixed Upper And Lowercase, not all UPPERCASE, which is harder to read.

  5. Avoid Blink. In normal pages, do not use the <blink> character style. Many users find it painful. Blink can be used only on expired and warning pages where annoyance is specifically intended, like in change-of-address pages: This page has moved! Please notify owner of calling page.

  6. Separation Bars. This applies to the <hr> directive.

1.3 English Language Style

  1. "Under Construction." Nearly all web pages are always under construction. Therefore, the words "Under construction" are superfluous and should not be used in any index page. (However, "under construction" or a similar phrase may be used in end-point documents to indicate that they are incomplete.)

  2. Avoid using the word "page" or "home page" in a hot key. It is implied.

1.4 Source Code Cosmetics

  1. Source code should be well-spaced and easily readable as a text file.

  2. Where possible, all html tags should be in lowercase, e.g. <table>, not <TABLE>. This makes html easier to read. (This rule applies to new, hand-generated source code; changing old code is not worth the effort.)

  3. Spaces in commands. Extra spaces within html commands (between < and >) should be avoided, except where needed to allow long commands to break cleanly across lines in wraparound text. (E.g. A space after "href= " and before " >" is sometimes helpful to make long URLs appear on a single wrapped source line.)

  4. Quotes in labels and URLs. Html label names and URLs are given without quotes: <a name=einstein> instead of <a name="einstein">. The quotes are superfluous here.

  5. No source code line should begin with a blank space, except within <pre>.

  6. Insert linefeeds wherever appropriate to make the source file readable, but do not double-space every line, and do not insert linefeeds within html commands.

  7. These directives, as well as their closing directives, should appear only at the start of a line: <center>, <hr>, <table>, <ul>, <ul>, <h1> (etc.), , <address>, <a name=label>. The only other items that can appear on that line are html tags that directly support the first item. (Example <p> on the same line is okay.)

  8. Examine the source for the source code for this document for style suggestions.

1.5 Graphics

  1. Do not use background patterns in index pages. They are a burden to users. (Unlike other pictures, text cannot be displayed until the entire pattern is loaded.) Background colors may be used instead to indicate an environment.

  2. Wherever possible, freestanding pictures (not in web pages) should be stored on our server as .jpg's instead of .gif's, since jpgs take less space.

  3. In-line pictures (in web pages) should be jpgs where possible to save space. However, gifs can still be used where there is a reason to.

  4. All in-line pictures must be given alternate titles for text-only browsers. Example: <img src=../graphic.gif alt="Alternate Title" >. The title must be enclosed in quotes in the source code.

  5. Wherever freestanding graphics (not in a web page) are linked to an index page, the approximate size must should be given in parentheses: e.g. (55k). The size appears outside the hot-link, and the "k" is always lowercase.

  6. Company Rule: Because graphics are often bandwidth-intensive and may be proprietary, wherever a graphic file already exists on someone else's server, it should be linked at that location instead of being copied to our own server. (However, important graphics should be backed up to our local support disk in case they vanish from the original server.) An exception might be a graphic that we use in multiple pages or a graphic on a slow server; in those cases, we might copy it to our own server.

1.6 Index Pages

"Index pages" (also known as "home pages") are pages consisting primarily of links to other documents, as well as lists of information in a very compact form. They are designed for maximum efficiency and ease-of-use. "Bells and Whistles" and anything that might slow access or confuse the user should be avoided. Index pages are highly standardized so that one author's page looks similar in format to anyone else's. Index pages are not the place for creativity, which is reserved for endpoint documents.

  1. Because they are used so often and are critical to accessing the rest of the database, index pages are designed to be as compact as possible. Specifically...

  2. Use the list directives, <ul> and <ol>, whenever as possible to break up knowledge into logical categories.

  3. Company Rule: Title at top is centered if no graphic.: The main <h1> title on the top of every index page should be centered (using <center>), unless there is a graphic to the left. (When there is a graphic to the left, there should be no centering.) All other titles should not be centered. Also: There should be only a single <h1> title in every document.

  4. Company Rule: All index pages serving a certain function and following the same style rules should have the same background color. (For example, we use light blue for most of our index pages.) This indicates a consistent environment that we have control over, so we must not link to any foreign page that uses the same background color unless it adheres to our rules.

  5. Use the unordered list, <ul>, for most short lists where order is not significant. Use numbered lists, <ol>, where numbered order is significant or where the list is very long (multiple screens). In long lists, the numbers help the user keep track of where he is in list. Nested <ul> lists are fine, but avoid nesting one <ol> list inside another <ol> as this gets confusing.

  6. There should be no <p> at the end of <li> lines in index documents, to assure the most compact display possible.

  7. There should be no dead-end hot-keys (that lead to nonexistent files), even for pages that are under construction. Every hot-key should lead somewhere; otherwise, it should not be highlighted. Do not add lines to index documents until the page referred to is actually operational. (It is okay for newly created pages to be missing for a few hours, but not days. If necessary, add placeholder documents with just a page title so the link will work until the new page is ready.)

  8. Avoid adding lines for documents that do not yet exist. ("Under Construction" and "Coming Soon" do not make it okay to add the line, since these are usually empty promises.)

  9. Where possible, every entry to a static endpoint document should be followed by a date. If the size is greater than 50k, that should also be given. This can be a single date in parentheses (11/30/95, 55k) if the creation date is known. If creation date is unknown, date of posting to page can be given (posted 11/30/95). A date or size should not be given for links to other index documents or foreign home pages, since these are subject to frequent change.

  10. Unless there is a reason to spell them out, dates are given in U.S. number format: (11/30/95, 35k).

  11. Size need not be given if the document is less than a certain size (say, 10k).

  12. Foreign Environments. If a link leads to another index page which is not under control of these standards, its tag names should be followed by a star (*): Fred's Home Page*. This indicates a "foreign environment" that is not under our control. The star should appear inside the hot-key. The star is required only for external home pages with links elsewhere. The star is not required for external endpoint documents--text files or html--without significant links elsewhere, since this is not an "environment." The star is also not required if the context on the index page clearly indicates that the page is external anyway (like a list of other people's home pages).

  13. Ethics: Index pages are neutral about the information they are pointing to. An index page must list all available documents that fit the topic of the page (or at least all documents that become available to the author). The author of the index page decides only how to organize the material and whether or not any new material fits the page's subject. On the other hand, the author must somehow indicate the user which documents are the most significant. The author also chooses where he will look for documents and how he will spends his time. Although he is obligated to post any related reference that is sent to him, he is not obligated hunt for references or to type in new documents that are not already available on the net. (He may do these things only if he is personally motivated to.)

  14. An index page may provide an overview description of the subject and an outline of the data and claims relating to it, as long as the outline itself is neutral. (e.g. " Frank Stranges claims to be in contact with a man from Venus named Valient Thor." While many people may dispute that Valient Thor exists, no one doubts that Stranges exists or that he had made this claim. Thus, the statement itself is neutral.

  15. A text block of one or two paragraphs is helpful at the top of an index page to provide a general overview of the topic, but any longer explanation should be given in a separate file.

  16. Wherever possible, an index page should be no larger than 25k. If it is bigger, try breaking it up by "spinning off" sub-topics into their own index pages.

  17. Graphics in index pages, if any, should be limited to a small logo, map or photo, formatted to the right in the header. (However, additional graphics in the footer are okay, since the main part of the page has already been loaded. This gives the sponsor an opportunity to advertise.)

  18. Whenever a personal opinion, either of the page author or someone else, is presented in an index page, it must be clearly labeled as an opinion. This can be done by using quotes or some other means that clearly indicates who's opinion it is and that it is separate from the neutral position of the rest of the page. See Stranges

1.7 Footer Information

At the bottom of every html page, there should be a full bar--<hr> (without options)--followed by this information...

  1. Back-links leading to parent pages. These allows a person who has accessed this page directly to find the parent page of the current one. (A "parent page" is one covering a broader field of knowledge than the current one and that calls the current one.) For a consistent interface, the button list should be surrounded by brackets and separated by bars, like this....

    [Parent | Grandparent | Top Level | Style]

  2. Name and city of Sponsor. Unless it is a link, the name should be bold: John Smith, Newark, NJ.

  3. Email address for corrections: johnsmith@newark.net

  4. A hit counter may optionally be provided here. The count should be bold. A date must be given to indicate when the count started. Example:

    Visits to this page since 6/10/95: 32124

  5. The date of last update, in US number format. This should be the last item in the file. 10/13/95

  6. A logo for the sponsor is okay in the footer. An advertisement is also acceptable here. The sponsor is free to do what they want in the footer (below the back-link buttons), as long as the above info is provided. Since the content portion of the pages has already been displayed, download time is not important here.

    1.8 End-Point Documents

    End-point documents are text or html files which report or analyze information, promote theories, express opinions or do anything else that is possible in writing. End-point documents may come from anywhere, and as long as they are not blatantly libelous or indecent, they need not adhere to any specific style rules to be listed in an index page. (However, any qualified rebuttal to the documents must also be listed with it). A source document is solely the work of its author, not the Company, so the author can use whatever creativity or ethical standards he finds appropriate. The linking of a source document to an index page does not imply the approval of the Company or the index page author.

    General rules for endpoint documents:

    1. Never store an endpoint document on our own server if it is available on someone else's. This both saves our bandwidth and assures that the original author can make changes.

    2. Company Rule: Whenever making a link to an important document on another server, also make a copy of that document on your local hard disk, in case the original document later vanishes.

    3. Whenever an endpoint document is written in html and contains a significant number of links to other document, a star (*) should appear beside our link to it to indicate a foreign environment.

    4. Whenever establishing a link to a little-used web page or endpoint document on another server, it is a common courtesy to inform the owner of that document. Then the owner is more likely to preserve the document or let you know if the location changes. This is most important with personal web pages that have little traffic. Notification is not needed for automated pages or ones that are so popular that the owner would not care.

    5. Any .html endpoint document produced by us (where there is no copyright risk) should include the following....
      • At least one backlink button to the calling index page. (The full list of backlink buttons is not necessary.)

      • Name of person or organization providing html conversion. E.g. "Html by Area 51 Research Center, 1/7/96"

      • The date of last change, or the date that the document was converted to Html.

    1.9 URLs and Server Storage

    1. No quotes in file names. File names in URLs should not be enclosed in quotes unless there is a specific need to do so: <a href=filename.txt>. (The only need that has arisen so far is when an external page uses a blank in a label, which we do not do.)

    2. Link to internal labels. When specifying locations within the current page, use only the pound sign and label: <a href=#label>.

    3. Intra-server references are relative. References to files on the same server should be relative: <a href= ../../area51/filename.html>. This allows the server to be moved or mirrored without changing all internal URLs.

    4. Default names. When the name of the file is "index.html" or "index.shtml", use only the directory name in the URL, not the full file name. This allows future upgrade to index.shtml without changing URLs. Example: Use <a href=../../area51> instead of <a href=../../area51/index.html>.

    5. File name format. All file and directory names given to items stored on our server must be all-lowercase. The only non-alphanumeric characters allowed are "." and "_". There should be only one "." in a file name, and what follows it must be a valid file suffix. Every file must have a suffix.

      • Company Rule: We use only these suffixes in file names: .html (not .htm), .jpg (not .jpeg), .txt (not .text), .gif (rare), .map, .count.

    6. Directory size. Directories should be broken up into logical subdirectories so that there are rarely more than 50 files in one directory. (Any more than this and FTP takes too long to retrieve the file list when uploading.) This rule is especially important in directories that have further subdirectories; it can be relaxed for directories that contain only endpoint documents.

    7. Planning. A great deal of thought must be given to the naming of subdirectories at the beginning, because the names and locations will be difficult to change once links are established.

    8. Directory names are singular. Words used for directory names should generally be singular, not plural. (e.g. "/place/", not "/places/".) The only exceptions are: "/articles/", "/people/" and "/orgs/".

    9. Common directories. These directories can appear throughout the server structure...

      • /articles/ -- For articles and scanned text not written by us that might possibly be copyrighted.

      • /anecdote/ -- For testimonials and secondhand stories that are told from memory.

      • /place/ -- For information arranged by location, usually by state abbreviation, then by city. (Country preceeds state if the scope is international.) e.g. ufo/place/usa/nv/hawthorne/sighting.txt

      • /org/ -- For documents relating to the web structure itself, including style documents, templates, etc.

      • /orgs/ -- Organizations relating to this topic. Each organization has its own subdirectory. (Plural is used here to distinguish this type of directory from "org.")

      • /people/ -- Files on people associated with this topic. Each person is filed under their last name. If more than one person has same last name, first one file uses the name alone; others are filed by lastname and initial -- smith_g -- or last name and full first name if initials start to repeat. If list has potential for growing large (100+ people), the people subdirectories are first filed by letter of alphabet: s/smith/.

      • /social/ -- Social and cultural aspects of the topic, independent of its reality.

      • /event/ -- Parent directory for incidents or events relating to the topic, each stored in a separate subdirectory.

      • /topic/ -- Parent directory for different aspects of the subject, each stored in a separate subdirectory. Topics differ from events in that they are on-going.

      • /ref/ -- General reference works on the topic that cannot be filed under people or place. e.g. Glossaries.

      • /date/ -- Items filed by date. Subdirectories are by year (four digits).

    10. Use of index.html. Use index.html in the home pages of major directories that are likely to be linked directly by outside users. Then, refer to the page only by its directory name. This makes the address more compact and allows for future upgrade to index.shtml. There is no need to use index.html in directories that are linked primarily from within our server and are not likely to be linked from outside (like catalog entries, etc., that are broken up into subdirectories only for space).

        Discussion: Use of index.html helps distinguish supported and unsupported addresses. Addresses given only by directory name (using index.html) are supported by us, and foreign links are encouraged to that address. Addresses using a full file name (not index.html) are not supported by us. Foreign users are free to make links there, but we do not feel obligated to support this address in the future.

        Example: We do not promise that ufo/place/usa/nv/hawthorne/smith_sighting.txt is a permanent address, but we do index that ufo/place/usa/nv/hawthorne/ be permanent once this index.html page is established.

        In general, we prefer that people link to our index pages and not our endpoint documents because index pages give us an opportunity to provide new material and direct users to related fields. We also get no credit for direct links to endpoint documents. Even though we are providing the storage space and possible input labor it seems to be part of the calling user's page.

    2.1 Ethical Rules

    Over time, rules will be assembled regarding the fair presentation of information. The job of an index page is to provide basic information and access to source documents and not to make a judgment about the information. At the same time, an index page has to direct the user to the most important information without burying him in irrelevant noise. Charlatans should be exposed, but preferably with their own words and claims. The role of the index page is to provide the available facts, claims and opinions, neatly organized, and let the user decide how to evaluate them. Like the rules of fair journalism, there is a delicate line to walk, and specific future rules will help define this line.

    See special rules for Internet Character Reporting.

    [Research Center | Top Level]

    Copyright © Glenn Campbell, Area 51 Research Center, PO Box 448, Rachel, NV 89001.

    Send corrections to: campbell@ufomind.com

    Created: 1995
    Last Modified: See version date at top