4.XX Separating structure, st...

4.XX Separating structure, style, and behavior

(Reference : http://www.mercurytide.co.uk/whitepapers/separating-structure-presentation-and-behaviour/ )

http://webdesign.about.com/od/intermediatetutorials/a/aa010707.htm

Generally, Web application development consist of three layer elements.

1. 1. Content or Structure
The content or structure layer is what your readers are coming to get when they come to your Web page. Content can consist of text or images and includes the pointers that your readers need to navigate around your Web site. In Web development, XHTML makes up the content layer and it also structures the Web document.

· 2. Style or Presentation
The style or presentation layer is how the document will look to your readers. This layer is defined by the CSS or styles that indicate how your document should be displayed and on what media types.

· 3. Behavior
The behavior layer is the layer of a Web page that does something. If you use Ajax or DHTML, it is the JavaScript that makes the page do something. If you have a PHP or CGI back-end, it is the PHP or CGI scripts that take action when your reader clicks something. For most Web pages, the first level of behavior is the JavaScript interactions on the page.

When you're creating a Web application, it is important to keep the layers separate. So why should you separate?

Among the many advantages (recently written about in Roger Johansson’s Ten reasons to learn and use web standards) we find these the most compelling:

Reducing bandwidth usage

Separating the structure (XHTML), presentation (CSS), and behaviour (Javascript) almost always results in smaller downloads: the presentation and behaviour do not need to be retrieved with each page, but can be cached by a browser. A usual side-effect of separation is that the XHTML markup becomes simpler, making pages smaller to serve to clients, thus faster.

Meaning and accessibility

Remove presentation and behaviour from the structure, and you are left with only semantically-correct markup and data. The semantics can be used by screen-readers, text-only browsers, mobile devices, next-generation search engines, and microformat discovery programs to garner meaning.

Maintainability

Using standard markup, coding style, and identifiers make it easy to understand code long after it has been written. As Johansson says: Would you rather wade through many kilobytes of multiply nested-tables and spacer-images or just browse through a clean and well-structured document when you need to update your site?

4.XX.1 Separating information and structure from presentation

(reference : http://www.w3.org/TR/WCAG20-TECHS/G140.html )

The objective of this technique is to facilitate the interaction of assistive technology with content by logically separating the content's structural encoding from the presentational encoding. Structural encoding is the indication of elements such as headings, paragraphs, lists, tables, etc., and is done by using technology features reserved for the purpose. By contrast, presentational encoding is the indication of formatting effects, such as typeface, color, size, position, borders, etc., and is also supported by technology features.

While presentational features visually imply structure — users can determine headings, paragraphs, lists, etc. from the formatting conventions used — these features do not encode the structure unambiguously enough for assistive technology to interact with the page effectively. Providing separate structure, functionality, and presentation layers allows the semantics implied by the formatting to become programmatically determined via the structure layer.

Following this technique allows user agents to:

Perform meaningful structure transformations based on the existing structure of the content, such as reordering sections or generating a list of sections or a list of links.
Support interaction with content based on structural characteristics that cannot be determined by assistive technology on the basis of presentational information alone. For instance, it may be desirable to provide special interactions with lists by indicating the number of list items or skipping to the end, but this is only possible if the list structure is encoded in addition to the list presentation.
Modify the presentation of content by substituting alternate presentation rules attached to structural features.

4.XX.1.1 What it means

For example, an HTML document uses the structural features of HTML, such as paragraphs, lists, headings, etc., and avoids presentational features such as font changes, layout hints, etc. CSS is used to format the document based on its structural properties. Well-crafted "class" attributes in the HTML extend the semantics of the structural markup if needed to allow more flexible formatting with CSS. Assistive technologies can substitute or extend the CSS to modify presentation, or ignore the CSS and interact directly with the structural encoding.

4.XX.1.2 How to do it

- Examine the encoding of a document.

- Check that structural information and functionality are explicitly provided and is logically separated from presentational information.

4.XX.2 Unobtrusive JavaScript - Separating Behavior From Structure

(reference : http://en.wikipedia.org/wiki/Unobtrusive_JavaScript )

http://labs.adobe.com/technologies/spry/articles/best_practices/separating_behavior.html

"Unobtrusive JavaScript" is an emerging technique in the JavaScript programming language, as used on the World Wide Web. Though the term is not formally defined, its basic principles are generally understood to include:

l Separation of functionality (the "behavior layer") from a Web page's structure/content and presentation

l Best practices to avoid the problems of traditional JavaScript programming (such as browser inconsistencies and lack of scalability)

l Graceful degradation in browsers where the advanced JavaScript functionality will not work as desired

4.XX.2.1 What it means

Traditionally, JavaScript often was placed inline together with an HTML document's markup. For example, the following is a typical implementation of JavaScript form validation when written inline:

<input type="text" name="date" onchange="validateDate(this);"/>

However, the purpose of markup is to describe a document's structure, not its programmatic behavior. Combining the two negatively impacts a site's maintainability for the same reason that combining content and presentation does: if a site contains hundreds of such date fields, adding the appropriate onchange attribute for each one (and modifying them later, if necessary) can be a labor-intensive process. Furthermore, inline syntax prevents the registration of more than one event handler for the element's onchange event, which can be a problem as the application grows.

Like the practice of separating style from structure, this has several benefits which include:

· The ability to make incremental modifications to the HTML markup structure or the behavior code independently without having to modify the other.

· Because the behavior implementation is externalized, it can be shared across multiple HTML pages, so the bandwidth necessary to view these pages is reduced since the files related to the behaviors are downloaded and cached by the browser once. This also results in smaller HTML pages since the behavior code is not duplicated within the actual markup itself.

· Since the HTML markup is smaller and semantic, it is also easier to read which aids accessibility with screen readers, search engine web crawlers, and browsers or other user agents that don't necessarily support the behaviors you've implemented.

4.XX.2.2 How to do it

Though the essence of unobtrusive JavaScript is the concept of a separate behavior layer, advocates of the paradigm generally subscribe to a number of related principles, such as:

l Strict adherence to the W3C DOM and event model, and avoidance of browser-specific extensions.

l More generally, JavaScript best practices often parallel those in other programming languages, such as encapsulation and abstraction layers, avoidance of global variables, meaningful naming conventions, use of appropriate design patterns, and systematic testing. Such principles are essential to large-scale software development, but have not been widely observed in JavaScript programming in the past; their adoption is seen as an essential component of JavaScript's transition from a "toy" language to a tool for serious development.