Technical Specifications

We require that every successfully funded and completed grant deliver all code, media and html files to the SALRC for long-term archiving and maintenance. The files should include documentation along with a list of all technologies employed (with version numbers).

With that in mind, we require that the following technical conventions be adhered to.

Approved Programming Languages/Databases

For the sake of long-term support and maintenance of SALRC funded projects, we require that grant projects limit their programming or that of their utilized tools to the following languages and widely held conventions:

  • XHTML 1.0 Strict or HTML 4.01 Strict doctype and CSS 2.1 Stylesheets
  • PHP 5.x and higher
  • Python 2.6.2 and higher
  • MySQL 5.1 and higher (UTF-8)
  • Java Standard Edition 6 or higher
  • Javascript 1.8 (jQuery, Google Web Toolkit, Yahoo! UI Library)

Required Standards & Practices

  • All web-sites must separate content and structure (i.e. XHTML or HTML plus CSS (plus PHP or Javascript)).
  • Ensure that all XHTML/HTML markup and CSS validates in the W3C validators
  • Follow Web Accessibility Initiative (WAI) guidelines to achieve Level 1, Priority 1 compliance. Aim to achieve substantial Level 1, Priority 2 and 3 compliance.
  • No frames / no XHMTL 1.0 Frameset doctype
  • UTF-8 (i.e. instead of HTML entities) must be used in ALL code/Databases.
  • No use of ActiveX, no use of Flash for navigational elements, banners or intro pages.
  • No tables for layout, no use of invisible graphical elements for spacing, filler etc.
  • No graphics substituting for text, especially not for menu items.
  • Target browsers are *Firefox 3.x, Safari 4.x, and IE7
  • Pages must be readable and navigable even without the use of a CSS or Javascript savvy browser (i.e. "degrade gracefully").
  • Strive for a logically organized, semantically meaningful document structure, especially for class and id elements.
  • Tags and class names should reference meaning or behavior.
  • Meaningful alt attributes on all images
  • Business code - functions, classes, etc. - can never contain any formatting information for the data they display. All formatting should be left up to the display code. Clearly some code will need to be in these pages - include functions, looping functions, if-then statements, etc. - but these should only exist to support the display of data. Database access and data manipulation should all be handled by classes and functions written specifically for these purposes.
  • All code should be peppered with comments wherever reasonable, particularly in areas where the purpose of the code may not be immediately obvious. Comments should also be used to describe any special algorithms or functions to act as both documentation as well as a ''sanity check'' to help testers ensure the code is working as described. In addition, all functions and publicly accessible variables should be documented using comments in the relevant style in order to help automatically create API documentation. This documentation should include descriptions for all parameters and return values as well as describe exactly what type of data each function expects to receive and what type of values, if any, it will return.
  • All functions and variables should be named to describe as accurately as possible the type and context of the data to be used. All names should start with a lowercase letter.