Standards
Nearly every modern web developer claims they are "standards compliant" these days. In actual practice, this amounts to nothing more than a marketing buzzword. All too frequently it is used merely to denote that the web page uses XHTML and CSS with no regards to the use of best practices such as separation of presentation and content, use of semantic markup, or adherence to accessibility standards.
Table of Contents
- CSS & XHTML
- Semantics & Separation of Presentation and Content
- Accessibility & Cross Platform Compatibility
- Tables for Layout
CSS & XHTML
CSS is a format used for adding style information to a document. It can be used for everything from setting font size and type to positioning elements on a page.
XHTML 1.0 is a modification of the HTML 4 specifications to serve the same purpose in an XML based format. Visually, this will have no effect to the end user. Structurally, it enforces stricter guidelines that eliminate a number of ambiguities present in HTML and results in a page that is much easier to decipher by applications and developers, making it easier ( i.e. cheaper and faster ) to maintain or modify.
XHTML 1.0 has three different specifications, referred to as DOCTYPEs, each intended for slightly different uses: Strict, Transitional, and Frameset. Transitional and Frameset exist solely to ease the transition from older websites that include features like frame or deprecated HTML elements, none of which should be used due to a variety of accessibility and design reasons. XHTML 1.0 Strict is essentially the default, intended for use on any new website, and has the most consistent implementation across web browsers.
Semantics and Separation of Presentation and Content
XHTML and CSS are meant to work together so that XHTML contains all content and the CSS files hold all presentation information. Separating these out makes future maintenance and updates substantially easier. By simple alterations to the CSS files, global alterations to the visual style and format can be made to a website. Were the two not clearly separated, that is a feat that would require altering each and every single page on the website. It also allows for styling the same page in multiple ways, either to make different themes available to the user ( See CSSZenGarden for further examples ) or to target different displays such as desktop PCs, cell phones, and print. To achieve either of those two goals without a clear separation of data would require creating and maintaining multiple copies of every page, adding to maintenance costs.
This only works if the XHTML document does not contain presentational information. For example, passages generally should not be marked as being italic. Instead, the reason why they would be italicized should be marked instead. Is the text italicized because it is emphasized, a quote, or a citation? Labelling these correctly provides hooks in case the styling needs to be changed and clearly identifies to the browser what this element is.
Accessibility & Device Independence
The Internet is on the move or, at least, the people accessing it are. The presence of PDAs, cell phones, and other portable devices capable of accessing the web is growing daily and there is no reason why a website should not work with them. Taking these devices into consideration means that the developer has to take accessibility seriously. For all intents and purposes, a user having their car's computer read them a website and a user who is completely blind are no different. A user with a low-resolution screen in their cell phone will have many of the same needs as a user who is colour blind or needs to magnify the screen several fold.
It is crucial to remember one fact about designing web pages and search engines: Google, Yahoo!, and all other engines are blind. They cannot appreciate the fancy graphics on a web page. just like any blind user, they can only read the text actually present on the page and will penalize you for complicated page structures and excessively confusing markup.
Clearly separating the structure from presentation helps immensely. Using a strike through tag may have accomplished the effect desired on a computer screen but what does a strike through sound like when read in a screen reader? If correctly labeled, the receiving device will know that this is marking deleted text and can compensate with its own means of reading these. Following at least the priority 1 & 2 checkpoints of the WCAG 1, or Web Content Accessibility Guidelines, will also greatly assist in ensuring accessibility.
Tables for Layout
Before CSS was widely supported in browsers, the only way it was possible to precisely position objects on a page was through the use of tables. This is no longer required since nearly all browsers at least partially support CSS2 but is still frequently used today. Some developers are stuck in there ways, some simply don't care, and others lack the skill to implement the same design any other way. ( Some designs are genuinely impossible to implement without resorting to some tables but these are extremely rare exceptions. ) The increasing use of WYSIWYG editors has not helped matters since none are as capable of laying out code in a logical manner as a human and therefor frequently fall back on to crutches, such as tables, to accomplish their goals.
Using tables for layout manages to violate all best practices for web development discussed so far. The table tag itself designates that what is contained is tabular data. For it to contain anything else contradicts its meaning and renders it non-semantic. Tables are a structural element and reside in the XHTML portion of the code. To use them for layout is a presentational effect and will require substantial changes to the code to accommodate any style changes, failing to provide any kind of separation of presentation and content. Finally, using tables for layout purposes is a direct violation of Checkpoint 5.3 of WCAG 1:
5.3 Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version). [Priority 2]
Note. Once user agents support style sheet positioning, tables should not be used for layout.
As noted earlier, user agents ( web browsers, etc. ) do support using CSS to position elements. For further information, read more about using tables for layout.