Standards compliance
General principles
- Separate concerns (structure/content, style, executable) according to professional standards of good practice:
- Content should be easily editable by non-technical staff using text editors
- and complex code should be in separate files (CSS, JS, and include files).
- Support
- No reliance on proprietary plug-ins, special configurations etc. Write code to W3C standards and expect browsers to support them rather than optimizing for any specific browser or platform. Good coding habits result in pages that will be readable in old browsers; they just won't look pretty.
- Make every effort to ensure that code complies with the guidelines of the W3C Web Accessibility Initiative
- Sound coding practice takes us much of the way towards this goal
- Clearly justify implementations that violate these standards (e.g. on quiz pages where the answers are intended to be hidden from the students).
- As far as possible, re-use code and write new code that lends itself to reuse and ease of maintenance
- Use no gratuitous graphics
- in particular, no use of graphics to represent text
- Work with programmer's tools
- We will train our assistants and workstudy students in technical skills relevant to practitioners in Digital Humanities
Technical standards
All web documents and files produced by HCMC must conform to the following standards:
Web page structure and content
All pages must be validated using the , using automatic detection of character encoding and document type. The validator's approval graphic should be displayed somewhere on the site.
Currently, that means that (barring exceptional circumstances) pages should be written in XHTML5 and should declare themselves as such.
Data structure
For relational datasets, the preferred implementation environment is mysql, generally with a php-based front-end. PostGres may be used where the scale or nature of the data warrants.
In either case, proper relational structures and techniques should be used to optimize the storage, querying and retrieval of data.
For hierarchical datasets, the implementation environment is XML processed by the Jenkins build server to generate HTML files. The XML should be TEI p5 compliant to maximize opportunities for re-use and integration with other projects.
Page layout, text styling etc.
All text styling, positioning and page layout should be accomplished with Cascading Style Sheets (CSS), in an effort to balance the objectives of the project with usability on the widest possible range of devices.
The CSS should be centralized in a separate CSS file and linked from each page. As much as possible, the CSS selectors used should be plain XHTML tags. Proprietary classes should be used only where necessary, and if possible, limited to areas of pages likely to be edited only by technical staff.
CSS files must be validated using the (CSS version 2 or above), and the validator's approval graphic should be displayed somewhere on the site.
Client-side script
All client-side scripting should be in JavaScript/ECMAScript, and wherever possible should be stored in separate JS files. All JavaScript should be clearly commented, and should adhere to a regular coding standard -- for instance, if camelback notation is used, it should be used everywhere.
If XHTML standards are fully adhered to, and all styles are centralized in stylesheets, then even old browsers should display the text in a readable manner. This can be tested by renaming the stylesheet temporarily, to see the site displayed without styles.
Server-side processing
PHP is provided on the university's web server, use it to include elements repeated on numerous pages and to generate standards-compliant xhtml from the results of a query to a database.
MySQL is provided by the university as a back-end database for projects requiring such resources.
XML-based projects are run on servers maintained for the HCMC by the central system administrators and support the use of XSLT and other XML-based languages for querying and manipulation of data.