list

Checklist Adoption Levels   tags: about Most checklist entries identify an adoption level. These range from "mandatory" which must always be adopted, through to "disallowed" which should never be adopted. The information below provides details on these levels. Contents Main Description  Related Topics and Pages Expand All Sections     Collapse All Sections Main Description   Each and every aspect of these standards are given a desirability level. There are currently five such levels: Level Checklist Item Requirement Mandatory This is a standard and must be implemented and/or utilised by all projects. Failure to implement a mandatory element will reduce overall quality of the final product, and will be seen as a failure to adopt the R2 standards. Recommended This aspect is a guidelines and should be implemented and/or utilised by all projects. Failure to implement a recommended element will reduce overall quality of the product, but in itself doesn't constitute a direct failure to adopt the R2 standards. Suggested This aspect should be considered for implementation and/or utilisation by projects. Often several solutions to a given problem may be suggested, and where possible the most appropriate solution should be selected. Failure to implement elements of these guidelines that are suggested won't necessary affect overall product quality. Permitted These aspects are allowed only in certain circumstances, the details of which will be given with the check-list rating. For example, some elements are permitted to aid migration. Use of permitted elements will reduce overall product quality. Disallowed The described aspect must never be implemented or utilised. Implementation of disallowed aspects will reduce overall product quality, and is seen as a failure to adopt the R2 standards. Related Topics and Pages   Checklists (X)HTML Practices Application Layer Checklist Aspect Oriented Programming Aspect Oriented Programming Under Spring Configuration Under Spring Data Access Layer (DAL) Checklist Host Adapter Best Practices Implementing Data Objects and Models Integration Layer Checklist Java Application Performance Java Coding Standards JavaScript Practices JSP Standards Logging Performance Considerations Presentation Layer Checklist Resources for JAR Components Resources for WAR Components Security and Application Integrity Service Layer Checklist Threading Issues and Thread-Safety Using Exceptions Validating Quality Checklist

---------------------

Checklist: (X)HTML Practices HTML (SGML-based) and (X)HTML (XML-based) are the languages predominantly used to mark up the semantic structure of Web pages. Development in accordance with standards, best practices, and checkpoints in this section facilitate the interoperability, maintainability, usability, and accessibility of technology assets created at HSBC. Contents Main Description Know the Specification Know Your Target Browsers Mark up Web pages according to semantic meaning and structure Semantics Structure Document Outline Write Well-Formed Mark up Write Tags in Lower Case Close Non-empty Elements Add ending slash to empty elements Nest tags in a manner consistent with syntax rules Separate presentation, structure, and behavior Embedded presentation and behavior Close Non-empty Elements NLS Support for XHTML (X)HTML and Transitional (X)HTML References Check Items  Related Topics and Pages Expand All Sections     Collapse All Sections Main Description    Know the Specification In order to effectively use HTML, it’s essential to be familiar with the fundamentals of the language. Thorough knowledge of a specification’s elements and attributes is required to create valid, semantic, and accessible mark up. See (X)HTML Specification for guidance.  Know Your Target Browsers HTML specifications are requirements, not only for markup developers, but also for browsers vendors. Unfortunately, browser vendors don’t always implement all the features of a particular spec. Therefore, it is essential that authors know what selectors and properties are supported in specific browsers and versions. See the following references for details: Internet Explorer HTML Support Mozilla HTML5 Safari Developer Library Google HTML Reference  Mark up Web pages according to semantic meaning and structure WCAG 2.0 Guideline 1.3.1 Info and Relationships states, "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text." Screen readers must be able to extract the semantic meaning of elements and page structure in order to convey information to users in different modalities. Search engines must be able to extract the semantic meaning of elements and page structure in order to index and prioritize content.    Semantics Mark up elements according to semantic meaning. Header and Paragraph: <h1>header</h1> <p>paragraph</p>   Structure Nest tags in a manner consistent with the structural semantics. Correct: <p><strong>Inline element nested in a block element</strong></p> Incorrect: <strong><p>Block element nested in an inline element</p></strong>   Document Outline Ensure that the document's outline is clear, i.e., headline tag hierarchy should be ordered in a logical descending manner. Outline: <h1>Level 1 header</h1> <p>paragraph</p> <h2>Level 2 header</h2> <p>paragraph</p>  Write Well-Formed Mark up In order for Web pages to render properly in user agents and be perceivable by end-users and search engines, syntax rules should be followed that are consistent with a page's doc type declaration. While XHTML syntax requires strict adherence to XML rules, HTML5 syntax is more permissive - allowing both XML and HTML rules. However, for consistency and maintenance sake, the DSP recommends the usage of XML syntax under the HTML5 doc type.  Write Tags in Lower Case Tag case should follow XML rules. Correct: <h1>header<h1> Incorrect: <H1>header<H1>   Close Non-empty Elements Non- Empty elements should follow XML rules for closing tags. Correct: <p>Non-empty element</p> Incorrect: <p>Non-empty element  Add ending slash to empty elements Empty elements should follow XML rules. Correct: <br /> Incorrect: <br >   Nest tags in a manner consistent with syntax rules Tags should properly encapsulate one another. Correct: <p><span>Nested Tag</span><p> Incorrect: <span><p>Nested Tag</span><p>  Separate presentation, structure, and behavior WCAG 2.0 Guideline 1.3.1 Info and Relationships states, "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text." The W3C recommends separating structure (e.g HTML), presentation (e.g CSS), & behavior (e.g JavaScript). The benefits are improved performance due to caching, reduced maintenance effort, and the capability to render different presentations and/or behavior to a specific user agent.  Embedded presentation and behavior Avoid presentation and behavior mark up and attributes. Correct: <p class=”className”>  Lorem ipsum </p> Incorrect: <p width=”200” >  <font size="3" color="red">Lorem ipsum</font> </p>   Close Non-empty Elements Externalize presentation and behavior in files. Head Element: <link href="file.css" rel="stylesheet" type="text/css" media="all" /> <script src="file.js" type="text/javascript"></script> If required to use inline JavaScript or CSS, encapsulate code in CDATA. Applies only to XHTML 1.0 Transitional. Inline JavaScript: <script type="text/javascript">  <!-- <![CDATA[>  ...  //]]--> <script>  NLS Support for XHTML JSPs or plain HTML files should be written and processed using Unicode characters, stored and transmitted using UTF-8 format. In this respect, JSPs should include the following directives as appropriate: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> ... <html> <head>     <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />     ... Obviously the (X)HTML, corresponding DOCTYPE and XML declarations will vary depending on the combination of JSP/HTML source file and the standard being utilised.  The example above assumes XHTML transitional output being defined within it's own source file. Other points to remember: HTML has implied dir and lang attributes for nearly every tag so that the direction and language can be applied properly. Default layout is generally left-to-right, indicated by dir="ltr". In most cases, a good HTML layout/design will let the browser convert the output to 'right-to-left' automatically if desired. In extreme cases it may be necessary to provide alternate versions of content/JSP's for some languages. For example, German is typically twice as long as the English equivalent translation as may require it's own HTML.  (X)HTML and Transitional (X)HTML XHTML is an XML representation of HTML. It enforces the correct nesting and closure of tags, and removes many notable concepts which are made exclusively available via CSS (such as font and other text decoration). Other points to remember: DOCTYPE is required on all pages. The XML declaration is recommended, but may be omitted due to problems with browser compatibility. All URL's must be properly encoded using & etc. CDATA is required around most JavaScript and CSS declarations. <script type="text/javascript"><!-- <![CDATA[     ... //]]> --></script>  References http://www.w3.org/standards/techs/htmlbp#w3c_all Best Practices for Authoring HTML http://www.w3.org/standards/techs/html#w3c_all HTML and (X)HTML Specifications and associated publications http://www.w3.org/standards/techs/css#w3c_all CSS Specifications and Standards Check Items   Expand All Check Items  Collapse All Check Items   [MANDATORY] Use the correct content type     [MANDATORY] Separate information and structure from presentation     [MANDATORY] Follow the UI construction standards; follow the web content accessibility guidelines     [MANDATORY] Follow the internet guidelines     [MANDATORY] Always meet DDA compliance requirements; always verify DDA compliance     [MANDATORY] Correctly escape outputted data     [MANDATORY] Do not rely on JavaScript, Flash and non-(X)HTML technologies     [MANDATORY] Set language for Web pages     [MANDATORY] Set text direction for Web pages     [MANDATORY] Always use POST for HTML forms under portlet; always use POST for un-safe and non-idempotent requests     [MANDATORY] Order content so that it makes sense when linearized checkpoint     [Recommended] Declare a doc type     [Recommended] Prefer strict standards; avoid transitional     [Recommended] Use label liberally     [Recommended] Adopt CSS2 standards for style-sheets     [Recommended] Limit HTML file size     [Recommended] Create HTTP headers to have content-type set to "text/html" and character encoding set to utf-8     [Disallowed] HTML comments, except for legal notices     [Disallowed] Special characters in alt and title text     [Disallowed] Inlined JavaScript, except where attaching external JavaScript methods to events     [MANDATORY] Avoid using the style="" attribute except when absolutely necessary.     [MANDATORY] Avoid tags with presentation meaning such as bold (<b>) and font (<font>).   Related Topics and Pages   Guidelines Pop-under Windows Pop-up Windows Using GET vs. POST HTTP Requests Reusable Assets (X)HTML Specification CSS Specifications Supporting Globalization within HTML UI Construction Standards Web Content Accessibility Guidelines 2.0 Supporting Materials Checklist Adoption Levels

References http://www.w3.org/standards/techs/htmlbp#w3c_all Best Practices for Authoring HTML http://www.w3.org/standards/techs/html#w3c_all HTML and (X)HTML Specifications and associated publications http://www.w3.org/standards/techs/css#w3c_all CSS Specifications and Standards

Check Items  

Expand All Check Items  Collapse All Check Items   [MANDATORY] Use the correct content type   In order for the client application to work correctly with the selected standard, the correct content-type HTTP header must be generated. Ensure that any defaults are overridden, or explicitly specify the content type so that the client can understand the returned content correctly.   [MANDATORY] Separate information and structure from presentation   WCAG 2.0 Guideline 1.3.1 Info and Relationships states, "Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text." The W3C recommends separating structure (e.g HTML), presentation (e.g CSS), & behavior (e.g JavaScript). The benefits are improved performance due to caching, reduced maintenance effort, and the capability to render different presentations and/or behavior to a specific user agent. See Separating information and structure from presentation to enable different presentations Avoid tags with presentation meaning such as bold (<b>) and font (<font>). Avoid using the style="" attribute except when absolutely necessary. Use externalize style sheets to style presentation: XHTML 1.0 Transitional: <link href="file.css" rel="stylesheet" type="text/css" media="all" /> </script src="file.js" type="text/javascript"></script> HTML5 <link href="file.css" rel="stylesheet" media="all" /> If required to use inline JavaScript or CSS, encapsulate code in CDATA. Applies only to XHTML 1.0 Transitional. <script type="text/javascript"> <!-- <![CDATA[> ... //]]--> <script>   [MANDATORY] Follow the UI construction standards; follow the web content accessibility guidelines   All (X)HTML should follow the UI construction standards and web content accessibility guidelines, including the application of UICS CSS classes as required. This will permit the UICS stylesheets to be used by all entities to change the look-and-feel of the application, while helping achieve DDA compliance.   [MANDATORY] Follow the internet guidelines   All (X)HTML should follow the internet development guidelines, including the application of accessibiliy to meet DDA requirements.   [MANDATORY] Always meet DDA compliance requirements; always verify DDA compliance   Remember that different languages, locales and entities may have subtly different DDA requirements; adopt the superset of all requirements, and verify that DDA compliance has been achieved for all HTML pages that are generated.   [MANDATORY] Correctly escape outputted data   Where data is being provided from within the application, always escape the data to ensure that special characters (such as < and >) are escaped within the HTML. This is essential to prevent against injection attacks, and other security breaches.   [MANDATORY] Do not rely on JavaScript, Flash and non-(X)HTML technologies   Never expect the JavaScript to execute; never build the HTML such that it doesn't work without JavaScript, Flash or other external technologies.  All UI should downgrade gracefully.   [MANDATORY] Set language for Web pages   Applications use language information about content to serve users the most relevant information based on their language preferences (See Why use the language attribute? ). Set the page's default language on the root element XHTML 1.0 Transitional: <html xml:lang="en" lang="en" ...> HTML5: <html lang="en" ...> To change the language from the page default, set the language on an element: XHTML 1.0 Transitional: <div xml:lang="en" lang="en ...> HTML5: <div lang="en ... >   [MANDATORY] Set text direction for Web pages   When the language orientation is right to left, set explicitly, using the HTML dir="" attribute, the page's overall text direction on the root element - Left to right language is the default and is not required. CSS should not be used to set text direction: XHTML 1.0 Transitional <html ... dir="rtl"> HTML5 <html lang="en" dir="rtl"> To switch text direction on content within the root element, Set text direction on a block element using the HTML dir="" attribute See Changing direction on block elements XHTML 1.0 Transitional <div dir="ltr" ...> HTML5  <div dir="ltr" ... > Do not use the HTML align="" attribute for text alignment. Use CSS (text-align) instead. Note that this recommendation is not to be confused with the dir="" attribute. See Avoid attributes with values of 'right' and 'left'   [MANDATORY] Always use POST for HTML forms under portlet; always use POST for un-safe and non-idempotent requests   These requirements are stipulated by the HTTP protocol and JSR168/286 standards.  SeeUsing GET vs. POST HTTP Requests for specific details.   [MANDATORY] Order content so that it makes sense when linearized checkpoint   WCAG 2.0 Guideline 1.3.2 Meaningful Sequence states, "When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined." Because screen readers and search engines interpret content linearly, content should be logical and intuitive when code is linearized. See Meaningful sequence. and Ordering the content in a meaningful sequence. Correct <h1>header</h1> <p>paragraph associated to the header</p> Incorrect <p>paragraph associated to the header</p> <h1>header</h1>   [Recommended] Declare a doc type   The Doc Type determines which language version and validation rules are used within a HTML document. Decare the appropriate Doc Type: XHTML 1.0 Transitional: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang="en" dir="ltr"> HTML5  <!DOCTYPE html> Due poor browser support, it is not recommended to use the XML prologue with XHTML 1.0 Transitional. XHTML 1.0 Transitional: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang="en" dir="ltr"> HTML5  <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html lang="en" dir="ltr">     [Recommended] Prefer strict standards; avoid transitional   When choosing whether to use XHTML or HTML, prefer and adopt the strict standards rather than the transitional options. Use framesets only where UI design requires framesets to be used; use strict standards for the contents of each frame.   [Recommended] Use label liberally   Always use the label tag to link the input field with the input field's introductory text. This aids with DDA compliance, particularly in respect to screen reader technologies.   [Recommended] Adopt CSS2 standards for style-sheets   Superior to the CSS1 standard, CSS2 offers a good compromise in terms of functionality and support. (Later CSS standards are not supported by all browsers sufficiently well at the time of writing these standards.)   [Recommended] Limit HTML file size   Ideally this should be around 10K or below; always ensure that it's below 50K. HTML file sizes over 50K can lead to serious performance problems, both in terms of the network download speed, and the ability for the browser to render dynamic layouts during the download process.   [Recommended] Create HTTP headers to have content-type set to "text/html" and character encoding set to utf-8   In order for the client application to work correctly with the selected standard, the correct content-type HTTP header must be generated. Explicitly specify, using a meta tag , the recommended content type (text/html) and encoding (utf-8) to override defaults and to help user agents correctly interpret content: XHTML 1.0 Transitional    <meta http-equiv="content-type" content="text/html; charset=utf-8" />  HTML5:    <meta charset="UTF-8" />   [Disallowed] HTML comments, except for legal notices   In preference, use the JSP comment directive which prevents the comment text being sent to the client, thus increasing security and performance.  The sole exception is where client-visible content must be included for legal reasons, such as copyright notices.   [Disallowed] Special characters in alt and title text   Generally speaking there's little need for special characters; always avoid the asterisk (*) and never begin the alternative text with a hyphen (-).   [Disallowed] Inlined JavaScript, except where attaching external JavaScript methods to events   For the same reasons that stylistic information must never be in-lined within the HTML, all JavaScript should be included within it's own file. Ideally any script should be attached to the appropriate HTML elements at start-up, or should be written such that it's optional to the processing (eg. image roll-over code).   [MANDATORY] Avoid using the style="" attribute except when absolutely necessary.     [MANDATORY] Avoid tags with presentation meaning such as bold (<b>) and font (<font>).