Rule 5 - Informatics technology
Content
- 1. Rule
- 2. Justification
- 3.
Description
- >>> 3.1. Environment
- >>> 3.2. General Rules
- >>> 3.3. Detailed Rules
1. Rule
The technology used in IntraComm pages must conform to the capacity and capabilities of the standard Commission internal server and client PC configurations.
2. Justification
Compatibility with internal Commission server platforms and PC configurations ensures access for all internal users, but it must always be kept in mind that this does not guarantee access to all users (other Institutions, officials at home or on mission, retired officials, etc.).
Where access to external users is essential, no assumptions can be made concerning the target users' technical capabilitis and so a "lowest common denominator" approach must be taken, as for EUROPA internet pages.
3. Description
3.1. Environment
The Data Centre (DIGIT.C.1) , hosts IntraComm on behalf of the Communication and Information Management Unit, ADMIN.D.5, using web servers and database servers run on UNIX compatible systems. The technical details are described in a separate document.
The Data Centre has set up two environments. The production environment is accessible to all users. The test environment is accessible only to information providers and can be used to upload and verify content, links and scripts before having them copied to the production environment.
Changes to the production environment are executed according to the procedures set out in this IPG, chapter 2.
The target user configuration is :
- browser type: MS Internet Explorer (version 5+) or Netscape Communicator (version 4.7)
- JavaScript capability : yes (but may be disabled by user choice)
- frames capability : yes (but should not be used for IntraComm sites)
- 800 x 600 colour monitor
- Plug-ins available (see Product list)
For a decription of standard reference configurations, see the Informatics Architecture.
3.2. General Rules
- Use standard templates where available and appropriate
- Use standard images where available and appropriate
- Use standard software listed on the Commission's official Product List
- Follow all the rules and procedures described in this Information Providers Guide
3.3. Detailed Rules
3.3.1 Identification
!DOCTYPE
The current version of HTML officially approved for use on IntraComm is HTML 4.01 Transitional.
Allthough the !DOCTYPE tag is not strictly required for any HTML page, it is recommended as it has many advantages :
- it specifies to a browser that the code is HTML, that the DTD (Document Type Definition) is an official W3C public DTD, and it specifies the HTML version
- this identification is also essential for any quality control and/or verification procedures
Usually the !DOCTYPE is inserted automatically by HTML-editors and authors give little or no thought to its accuracy or usefulness. Care must be taken that the !DOCTYPE tag accurately reflects the status of the HTML which follows.
Recommendation for the !DOCTYPE tag :
!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
This is the HTML 4.01 Transitional DTD, which includes presentation attributes and elements that W3C expects to phase out as support for style sheets matures. The Strict DTD should be used when possible, but it is very strict, and use of the Transitional DTD gives more flexibility in the transition from previous HTML versions to 4.01.
META DATA
See chapter 7
3.3.2 Presentation
Text and fonts
- do not use embedded fonts - they add to the overheads of the page and there are browser compatibility problems
- always declare the character set in use
for Latin characters use ISO-8859-1 META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1"
for Greek pages use ISO-8859-7
META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-7"
Links
Links may be implemented in different ways :
Text
- a link may be attached to a word or phrase
- links must be underlined to distinguish them from other text, except when they are part of a list or otherwise indicated to be a link
Image
- a link may be attached to an image
- the image must not have a border to indicate a link, use BORDER="0"
- the image must have a descriptive ALT text in the language appropriate to the page
Image map
- several different links may be attached to different areas of an image
- image maps must be client-side
- the image must not have a border to indicate a link, use BORDER="0"
- the image must have a descriptive ALT text for each link area in the language appropriate to the page
JavaScript
- several means of specifying links may be embedded in JavaScript
- a text alternative must be provided for the same links (this also improves indexing by search engines which may not be able to see inside scripts)
The HREF attribute of links may be specified in several ways :
- absolute URLS of the type "http://www.xxx.com/things/index.htm". This is the format for external links only. For internal links this format must not be used as it destroys the independence of the test and production environments by crossing over between them.
- relative URLs of the type "../../index.html". This is the preferred method within IntraComm.
- relative to root of the type "/index.html". This is particularly useful to return to higher levels of IntraComm or other sub-sites and also to reference standard images, because the HREF value remains the same at whichever level it is used (it may, however, cause some difficulties when testing locally on a PC).
Other requirements for links :
- Links must always be to a page in the same language as the source page. Where this is not possible because the destination page does not exist in the appropriate language, this should be indicated.
- Links should always be to pages/sites which are accessible to the same audience as IntraComm itself. Clearly indicate where this is not possible.
- Where links are made to other IntraComm sites, care must be taken to follow any rules established by the owners of those sites.
- Do not duplicate information, link to the existing source in all cases
Images
- always use standard IntraComm images when available :
- the images must be used from the standard libraries (important : do not make local copies)
- the language version appropriate to the page must be used
- When standard images are not available, create new images or use existing ones:
- always use .gif or .jpg formats
- to allow a transparent background use .gif format 89a
- for animation use .gif format 89a
- keep image sizes as small as possible
- all images must have the alternative text attribute (ALT) set in the same language as the page
- all images must have HEIGHT and WIDTH attributes set
- always use BORDER="0"
- do not use large background images
- care must be taken to respect the copyright restrictions on images
3.3.3 Structure
FILE FORMATS
The following file formats are recommended for use on IntraComm :
HTML files
filetype ".html" or ".htm"
PDF files
filetype ".pdf"
This platform independent format has become a standard on the internet with the necessary reader included in the Commission's standard configuration, and available free of charge to others
IMAGE files
filetype ".gif", ".jpg"
(The ".png" format is not yet fully supported by all browsers)
ZIP files
filetype ".zip"
This is also an industry standard for grouping and compressing files for download
SOUND and Video files
Formats must be compatible with the Commission's standard plug-ins (see Product List)
Always indicate the file type and the file size
Frames
The general rule is : no frames.
Frames can be quite useful if used in the right manner, usually for retaining an index or a header on a page, but quite annoying if you want to bookmark a page or print out a page. There may be further problems when individual frames become directly accessible via a search engine, without the presence of the full frame context.
The special rule is : under "special circumstances" frames may be allowed with prior authorisation of the IntraComm Team. There is a big emphasis on PRIOR.
The "special circumstances are" :
Where the use of frames significantly improves access to, or maintenance of, information without compromising the other rules of this IPG. This may be through :
- improved navigation
- retention of an index, or other reference, always visible on screen. This may be particularly significant on large complex sites
- concentration of fast-changing information into a frame for regular and fast updating (news, for example)
Authorisation is considered on a case-by-case basis.
When authorised, the following constraints still apply :
- a NOFRAMES version must be available. It does not need to be a complete second version of the site as this would imply doublication of effort but it is not enough to allow "Sorry, you can't access this site because you don't have frames" - a NOFRAMES alternative must be provided
- the WAI guidelines for the use of frames must be followed
- automatic breakout when linking outside the frameset is essential
- automatic (re)construction of a frame context should be used where possible
3.3.4 Multimedia
Sound and video
Sound and video add to the richness of IntraComm pages but excessive use can overload the server and/or the user's connection and result in an unacceptably long download time. Sound and video should only be used to convey information, not simply for entertainment.
Plug-ins
Pages and documents on IntraComm must not require the use of a "non-standard" plug-in. (See the Product List for standard plug-ins)
3.3.5 Dynamic web pages, scripting, CGI, ...
Active X
Must not be used because it is platform dependent.
Java
Java is a very versatile and powerful platform independent tool, and its use is allowed on IntraComm with the following restrictions :
- it is not used simply for flashy tricks, but adds real value to a site
- its use must not be vital to the functioning or navigation of the site
- all possible server side security concerns are investigated and resolved
- pure Java is used (to remain platform independent)
- when development tools automatically generate Java code, it should be checked for "purity"
- the standards for presentation and content described in this IPG are maintained and respected
DHTML
Dynamic HTML is HTML which can be modified even after it has been loaded into a browser. It is a concept which has been enabled by a number of inter-acting technologies, including JavaScript, VBScript, the Document Object Module (DOM), layers, and Cascading Style Sheets (CSS).
There are certain difficulties in its use :
- different implementation in different browsers
- the habit of some users to disable JavaScript which may be vital to the functioning of the DHTML
DHTML techniques are recommended for use on IntraComm only with the following restrictions :
- they are not used simply for flashy tricks, but add real value to a site
- their use must not be vital to the functioning of the site
- it is not used as the sole base for navigation
- it degrades gracefully for users who do not have (or choose not to have) the necessary capabilities in their browsers
- it is implemented for and tested for compatibility with all different browsers
Javascript
The use of JS is subject to certain restrictions :
- it is not used simply for flashy tricks, but adds real value to a site
- its use must not be vital to the functioning or navigation of the site
- do not use for functions which already exist in another form ("Back" for example)
- always check for browser compatibility
- the standards for presentation and content described in this IPG are maintained and respected
Examples of adding real value are :
- improving navigational options
- validation of form input
- checking and routing according to the user configuration
In all these cases alternative non-JS solutions must also be available and the JS must degrade gracefully. (See also part 7 on WAI accessibility.)
Dynamic contents
The use of static pages is preferred, but dynamically generated content is allowed with the following restrictions :
- only official web development products in the Commission's Product List are used
- alternatively, CGI scripts written in Perl 5 or other compiled programming languages may be used (there may be problems testing CGI because of access restrictions to the cgi-bin library)
- only database products in the Commission's Product List are used
- the standards for presentation and content described in this IPG are maintained and respected