Web Standards

This document describes the standards for content in the science fair website.

Document Format

All documents will conform to the XHTML 1.0 Strict standard. All documents must contain the proper DOCTYPE header to tell the browser to render according to this standard:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
  <title>[Your title here]</title>
  ...
</head>
<body>
...
...
...
</body>
</html>

Uploaded documents will be checked for adherance to this standard by using the w3c validator.

For those familiar with HTML, there are a few things to keep in mind when coding XHTML. The major changes are as follows:

For those new to XHTML, the following tutorial is a good starting point: WebsiteTips: Basic Tags.

PDFs

PDF is a print media format and should not be used for web pages. PDFs should only be used for material specifically intended to be printed out, such a cutout for a paper airplane.

Coding Guidelines

The rule of thumb of XHTML (and HTML as well) is that the markup defines the content and the structure of the content, but not the formatting or presentation of that content. Formatting is accomplished quite nicely through the use of Cascading Style Sheets (CSS). Keep the markup as simple as possible while still passing the validation tests.

Good Tags

Relevant use of the following tags is encouraged:

<h1></h1>
<h2></h2>
<h3></h3>
<h4></h4>
<h5></h5>
<h6></h6>
Use as many header levels as needed to organize sections. Don't skip header levels though.
<p></p>
Use liberally to structure blocks of content. (Not needed around lists though)
<ul><li></li></ul>
Great for a list of items, such as a list of materials.
<ol><li></li></ol>
Great for a numbered list, such as a list of procedure steps.
<dl><dt></dt><dd></dd></dl>
Great for key-value mappings, such as a list of terms and definitions.

Restricted Tags

The following tags should only be used in the proper context:

<table><tr><td></td></tr></table>
Use only for tabular data, not for formatting.
<br />
Use only for single line breaks. Do not use for spacing between blocks of content. Consider using <p> tags instead.

Forbibben tags

The following HTML tags are obsolete and should not be used:

<b></b>
Use <strong> to denote a very important word or phrase.
<i></i>
Use <em> to emphasize a word or phase.
<u></u>
<font></font>
<center></center>
HTML should not be used for formatting, this is the job of css. Avoid using these tags.
<blink></blink>
Don't even get me started

Content Guidelines

These guidelines are established so that all pages of the website are consistent and so that the website is maintainable.

Navigation

A consistent navigation menu should be available on all pages of the site. The navigation menu of every page should always have a consistent set of top-level links to the main parts of the site.

Large Documents

Content should not be arbitrarily split into multiple pages. Pages are for print media, not a website viewed on a screen. The user should be able to freely scroll about a page on a particular topic to get any information he wants. Any print media specific style settings should be set in the @media print section of the style sheet and not affect the appearance of a page on screen. If a web page is very large (more than 10 pages in print), then it should be divided into subtopics, presented by an index page that links to a page for each topic.

Readability

The XHTML source of all documents should be human readable. This means the source of the document should be formatted to mirror the structure of the document. Document sources with little or no line breaks are not acceptable.

All Caps

Don't write words in all capitals with the exception of acronyms. Using capital letters for normal words is equivalent to shouting in conversation. Use <strong> or <em> tags to emphasize words or phrases.

Multimedia

Every piece of multimedia added to a page does three things:

Before adding multimedia to a page, one should ask if the multimedia will add enough useful value to the page to offset these side effect.

Images

No compression artifacts should be visible on any image while keeping file size to a minimum. To achieve this goal, the following conventions are established:

Photographic images should be compressed with JPEG as much as possible without showing compression artifacts. Inspect the image carefully for these artifacts before adding it to a page. This usually amounts to 15%-30% compresssion (70%-85% quality).

Computer screen shots must be losslessly encoding using the PNG format. JPEG compression should not be used for this purpose since it's designed for photography, not bitmap or vector graphics.

Vector graphics (such as diagrams, flowcharts, icons) should be rendered with subpixel precision (antialiasing) and losslessly encoded using the PNG format with an alpha channel (variable transparency) used to make the background transparent. If the image is properly encoded, it should seamlessly render on any color background and no aliasing (pixel jaggies) should be visible. The source for these graphics (svg, visio file, omnigraffle document, etc.) should be kept in the repository with the rendered images, preferably in an XML format. Image titles, captions, or other auxilliary text should not be rendered in these images.

Video and Animations

Animated images should be avoided, especially animations that run continuously as these are distracting and annoying to the reader.

Video should be encoded using the H.264 encoder with AAC audio (MPEG-4 standard) to achieve good quality and high compression. This codec is becoming part of a web standard that all browsers will support by default.

Executables

Executables should not be hosted on this website. The user's browser may think that the executable is a virus or trojan and block the site. If the intent is to help the user install some software, the user should be directed with a permanent link to the software maker's downloads page.

Interactive Content

For interactive content, the preferred scripting language is javascript since it integrates very well with web content, it's being developed into a standard (ECMAScript), and almost all browsers support it by default. Java, flash, and other nonstandard browser extensions should be avoided. Almost always, these extensions are unnecessary since javascript can provide the needed functionality and more using a web software development model known as Asynchronous JavaScript and XML (AJAX).

URI Hierarchy

Since we want others to link to our website, URIs should be selected so that they won't change, breaking other's links to our site. To achieve this end, the following conventions are established:

URIs

URIs that reference a web document (or any resource we want others linking to) should not have an extension. The extension is an implementation specific detail which indicates what server-side scripting language is used to render a page (.php, .shtml, etc.). Since a URI should not change, it should not be implementation dependent.

For every valid URI, every parent of that URI should be a valid URI. For example, if http://example.com/foo/bar/baz is a valid URI, the the following must also be valid URIs:

Redirects

In the event that a URI does change, or an old URI becomes obsolete, the server should be configured to redirect the user to the currently existing page most relevant to the content hosted at the old URI.

Repository Hierarchy

Every directory should have an index file which is the file the server retrieves when the client requests that directory. The index file should never be referenced directly in a link. Adding the following apache directive will change the index from from index.html to index:

DirectoryIndex index

Every directory that contains subdirectories should have a ReadMe.txt file describing the purpose of the directory, and minimally the purpose of all of the subdirectories. This file should be kept up-to-date with changes in the repository. Similary, directories which contain files with that don't have an obvious purpose should have a ReadMe.txt file

Links

Links that reference page specific content should use relative references. Examples:

href="."
Link to the index page of the current directory
src="table.jpg"
Reference an image in the same directory as the current document
href=".."
Link to the index page of the parent directory
href="airplane"
Link to a document in the same directory as the current document
src="../pattern.png"
Link to an image in the parent directory

Links that reference global content should use absolute paths. Examples:

href="/"
Link to the main page
background: url(/images/bg.png)
Reference a global background image
href="/projects
Link to the projects page from anywhere

Server Side Scripting

Server-side scripting should only be used for dynamic content, not static content. Dynamically generating static content wastes valuable server resources which can bring the server down when a sudden spike in hits occurs (right when the server needs to stay up the most). Use the build script to put together static content at website build time.

References