Technical Regulations

Preamble

When it was first created, the World Wide Web had only a few recommendations which web authors had to comply with.  These recommendations were written by the fledgling World Wide Web Consortium (W3C).  Browser makers saw the W3Cs recommendations as a starting point and dreamt up their own HTML tags, which other browser makers refused to support or use in their own products.  This lead to the web becoming a mish-mash of pages which wouldn't display correctly in every web-browser.

Since 2001, this situation has been changed, thanks largely to bodies such as the Web Standards Project who campaigned both for the W3C to set more rigid standards, and for browser makers to stick to them.  By adhering to the new W3C recommendations web authors can build web-sites which look the same in every web-browser.

It is with this in mind that we have put together the following set of technical regulations for web authors to use.

The Technical Regulations

Wherever reasonably possible you must make sure that:

  1. you only use ASP/VBScript or ASP.NET as your server side scripting language.  Information Services does not support Java, PHP or other scripting languages.
  2. you add a DOCTYPE statement to any web-page you create (REASON: DOCTYPES describe to a web-browser how the document should be rendered).  They can be found on the W3C website
  3. you only author web-pages in valid XHTML v1.0 Strict or HTML v4.01 Strict (You should check that each web-page you author validates against the W3C specifications via the online HTML checking service).
  4. you only author style-sheets in valid CSS v2.0 (You should check that each style-sheet you author validates against the W3C specifications via the online CSS checking service).
  5. <font> tags are not used in pages.  Use a CSS stylesheet to control font sizes and types instead.
  6. you do not copy/paste directly from a third party word processing application (such as MS Word) into web-pages (REASON You may copy over non-standard HTML or formatting code which could prevent you page from validating against W3C recommendations.  This formatting code must be stripped from the copied text).
  7. you only use lower case alphanumeric text for file-names and folder-names.
  8. you do not include any spaces in file-names (REASON: Spaces cause URLs in emails and other web pages to break).  Replace them with a hyphen (-), not an underscore (_).
  9. do not include any ampersands (&) in file-names or web-pages (REASON: Ampersands cause URLs to break and may not be interpreted correctly by the web-browsers rendering engine).  Replace them with a hyphen (-) or "and".
  10. do not break the web browser back button in web applications.
  11. store all images in a sub-folder called "images" (REASON: HTML and image files should not be stored together).
  12. do not delete the folders "_private" or "images" in the top level (or ROOT) directory on web-servers accessed with FrontPage (REASON: These two folders are used by the FrontPage/SharePoint Server Extensions).
  13. do not use any of the FrontPage Components such as:
    • Banner Ad Manager
    • Hover Button
    • Include Page
    • Scheduled Include Page
    • Scheduled Picture
    • Substitution
    • Confirmation Field
    • Search Form
    • Table of Contents
    (REASON: They can cause the page to load incorrectly on some web-browsers).
  14. only create image files in .JPG, .PNG or .GIF format (Preferably .PNG as it is not covered by any patents, to which intellectual property owners may assert their rights to at a future date).
  15. only put video online in .MP4.
  16. only put audio online in .MP3 or .AAC/.M4A.

We suggest that you:

  1. give your files descriptive file-names.  For example, if you have an image of the Clifton Suspension Bridge, call the file "clifton-suspension-bridge.jpg".
  2. use a coherent structured folder system to store all files.  For example, if you have several pages relating to specific modules, you should store them together in a folder called "modules".
  3. avoid using server-side Java applets (REASON: They slow down our web-servers).  Client-side Java applets are OK.
  4. avoid using server-side JavaScript cookies (REASON: They slow down our web-servers and may violate certain aspects of our Data Protection Act statement).  Client-side JavaScript cookies are OK.
  5. test your web pages render correctly with the following web browsers: We only support web-browser created within the last 2 years, so only test in those released versions.