Table of Contents:
Introduction
Principles
Preliminary Analysis
Mechanics
General HTML Concerns
Specific HTML Concerns
Graphics
Required Elements
|
|
Specific HTML Usage
Head
Every page must contain a unique, meaningful, context-free TITLE in
the HEAD element.
This title should not contain obvious or redundant information (such
as the words "Home Page"). The title should be as short as it can
reasonably be made and still present all the necessary information.
Multiple TITLE elements (for a marquee effect) are forbidden. Control
characters within the title, such as backspace or linefeed, are
similarly forbidden.
The META tag should be used to include important and relevant
descriptive information. In most cases, it is NOT appropriate to use a
META FORMATTER tag. In general, META information should follow the
Dublin
Core recommendations.
Body
There must be one and only one BODY element, and it must
enclose all of the visible content of the page. Do not use
one BODY element for document structure, and another for
supplying background colors or images. Do not use an unpaired
<BODY> start tag as if BODY were not a container element.
Whenever using the BODY element to supply colors, always
supply a complete set (background, text, and both unvisited
and visited link colors). Do not assume that just because the
reader permits the page author to override the browser
settings, that those settings are necessarily the default
ones. (If the browser setting is white text on a black
background, overriding only the background color and setting
it to white will render the page invisible.)
Headings
Headings should be used to manifest the structure of the
information being presented on a page. If the headings were to
be removed from the page and displayed on their own, they should
form a reasonable outline of the information content of that
page. The Hn elements (H1, H2, H3, H4, H5, and H6) should be
used for this purpose and only this purpose (they should not be
used simply to produce changes in font size), and no other
device should be used to simulate them.
Headings should generally be used sequentially, in keeping with their
function of providing an outline of document content. This means
that a heading level (such as H3) should not be used unless the
preceding level (H2 in this case) has previously been used, and
the higher-numbered heading should denote a subtopic
within the portion labelled by the lower-numbered heading.
Levels should not be skipped.
Exceptions:
- Running titles within a set of documents/pages.
- Multiple-page documents in which the headings are used
sequentially within the document as a whole.
The level one heading (H1) effectively represents a title for
the page, which implies that there should only be one level one
heading on any given page. All other levels represent the
subdivision of a topic into subtopics.
Headings are block-level elements, and imply a
paragraph break. Do not place headings within paragraph (P)
elements (doing so makes no sense: a heading already
is a paragraph, all on its own), or within
text-level elements, such as anchor (A) elements (you can have
an anchor inside of a heading, but not the other way around).
Start and end tags are always required.
Links
Links should be used whenever a hypertext connection to further or
related information is appropriate.
It is important to help the user maintain a 'mental map' of the site
or area being traversed. To that end, the use of 'mapping' links,
such as 'back', 'forward', and menu links is encouraged.
Links should use relative, rather than absolute, URLs whenever
possible, to facilitate relocation of documents.
The use of tables of contents and named sections in long documents
is encouraged for ease of use. Targets (named anchors) should be
meaningful.
Images
All IMG elements should contain an ALT attribute which either
is sufficiently explanatory to replace the function of the image
when viewed from within a text-based browser, or which contains
information on how to download the graphic, if no textual
explanation could possibly be sufficient. Purely decorative
images may use a null ALT attribute (ALT=""), if and
only if this does not detract from the completeness or utility of
the document when viewed as text.
All IMG elements should use the attributes WIDTH and HEIGHT
to promote efficient loading of the page,
unless the information provider is striving
for strict HTML 2.0 compliance (in which
case, the DOCTYPE for the page should reflect this).
Image Maps
All image maps should incorporate both server-side and
client-side methods. In other words, the IMG element should
include both ISMAP and USEMAP attributes, and the definition
of "hot zones" within the map should be contained
within both a MAP element (and associated AREA elements) in
the same file, and also within a separate map file. The
defined areas and behavior (target URLs) should be identical
in both cases.
The client-side map should provide as much assistance as
possible for any text-oriented agents (such as newer versions
of Lynx) that may support image maps. This means that the ALT
attribute of the IMG element and the TITLE attribute of the
MAP element should both be present, and must have identical
text (the title or description of the map itself). Each AREA
element within the client side map should include an ALT
attribute, which represents the link text for each possible
destination.
In most instances, any page containing an image map should
also have a link to a text-only alternate page. This page
should use only very basic HTML features (no tables, for
example), as it only exists to accomodate browsers that do
not support advanced features.
Even more than with most images, the image used for an image
map should be designed to load as quickly as possible. Keep
the number of colors to a minimum, and keep the file size
small. Always use HEIGHT and WIDTH attributes on the IMG
element. Consider using the LOWSRC attribute of the IMG
element to provide a quick preview of the map image (in this
case, the preview image file should be much
smaller than the primary image; note that because the only
agents that will support LOWSRC will also support image
autoscaling, the preview image need not be full-size in terms
of pixels: you can use a quarter-size image to help keep the
file size at a minimum).
Remember to be careful that the image used for the image map
looks like an image map; i.e., make sure it is obvious that
clicking on the image will take you somewhere. This is
especially important if the BORDER=0 attribute on the IMG
element is used to eliminate the colored link border around the
image.
Lists
Since the use of "white space" (indents,
blank lines, etc.) is ignored by the browser, the source
file should be formatted in a way that it makes it easy to
read and reflects the structure of the information as it
will be rendered by the browser. This means that lists
should be formatted so that the list items are indented in
order to mimic the physical layout of the page as
displayed by the browser.
List tags (UL, OL, DL) must be paired correctly and correctly matched
to the type of list item(s) used within them.
List item (LI, DT, and DD) tags should be used only within the
proper list elements, and must be correctly nested.
Unordered lists (UL) should be used when a number of items are to be
listed in no particular order, ordered lists (OL) when the
order or number of the items is important. When the items consist of a
heading or term and explanatory text, definition lists (DL) should be
used.
Tables
Although the tables element is widely used as both a way
to present traditional tables, and a way to format the layout
of the page, it is not a part of the HTML 2.0
standard. Consequently, browsers can (and do) render tables in
different ways. (Lynx does not handle tables at all).
If you must use a table to present
information, do not use more than 2 levels of nesting. In many cases,
the same effect (as nesting tables) can be achieved by the appropriate
use of COLSPAN and ROWSPAN attributes.
The use of tables in order to lay out a page in a specific
manner should be avoided when possible.
As an aid to browsers which do not support tables, all
cells containing text (or images with ALT text) should
end with at least one trailing space, and the last cell
in each row should end with a break (BR) element. Any cell
with more text than just a word or short phrase should
probably end with a break element, even if it is not
the last cell in the row. This should help make the text
readable, even if the structure and formatting implied
by the table is ignored.
Forms
Due to security concerns, at the present time, LUIR does not allow
users to run their own CGI scripts. A number of
form-processing
scripts and other generic applications are available for use
with the Lehigh Web Server. Departments may make requests for
specific types
of generic applications through the Webmaster (www@lehigh.edu). Such
requests will be handled at the discretion of IR.
All forms must be enclosed in paired (<FORM>
</FORM>) forms tags. You may have multiple forms on a page, but
form elements may not be nested.
Comments
Comments within HTML code are encouraged.
The correct syntax for a comment in HTML is:
<!-- comment text -->
(Comment delimiters are NOT symmetrical.) There should always be
at least one space between the comment delimiters and any
comment text. A comment should all fit on one line (because some
browsers do not correctly handle comments that begin on one line
and end on another); if the comment is longer than this, break
it into separate lines and treat the long comment as multiple
comments.
Comments are particularly encouraged in cases where the HTML
code which follows uses an element or feature to achieve an
effect for which it was not really designed (such as using a
TABLE to provide a margin, or a two-column list). Comments that
explain HTML code should precede the code
section to which they refer, rather than following it.
|
|
