custom web site designers, technical editors
custom creative services

Web Site Coding Standards

Technical background — here we discuss internet-related coding standards, reasons for choosing a particular standard, or any standard at all, and the impact these decisions may have on a web site's business and future development.

HTML, CSS and Javascript

CSS has largely supplanted earlier, verbose HTML techniques that commonly were used to define web pages' layout. HTML has thereby been freed to do just what it was made for, to tag text with succinct codes to identify the text as, for example, a paragraph, a level-1 heading or a path to an image — but not to determine what any of those things look like or where they belong on the web page. This has resulted in greater separation of content from markup code, and today typically makes development and maintenance more efficient and affordable.

Generally, HTML with CSS offers a streamlined alternative to older, code-heavy methods of specifying design attributes. In general, a site employing CSS:

Developers, including External Design, increasingly are using CSS to replace common Javascript functions like image swapping. With the advent of new capabilities in HTML 5 and CSS 3, this trend will continue. Some weightier PNG-24 graphics may be replaced by more-efficient formats if, for example, drop shadows are rendered via CSS instead of in Photoshop.

Not all browsers adopt the entire HTML and CSS specifications consistently, but all major browsers' current versions offer good support of HTML 4, XHTML 1 and most of CSS 2. Elements of HTML 5 and CSS 3 are quietly being adopted by some browser manufacturers. Some inconsistencies remain in browsers' intrepretions of existing and forthcoming standards but, in most cases, workarounds can be found or the differences truly are negligible.

But CSS was never intended to replace Javascript, and tabular data still may be best represented using HTML tables. Each has its strengths and appropriate uses.

Older Browsers: From Graceful Degradation to Progressive Enhancement

What is CSS? "Cascading Stylesheets"

Cascading stylesheets (CSS) faced initial, but short-lived, resistance from web developers and site owners because of poor support for it in the web browsers of the time. Today, though, most web browsers comply to a great extent with official CSS specifications, and CSS is used widely to define the style and presentation of web documents. For many web sites, the adoption of CSS lightens the byte-load (of the pages we sampled) by about one-third to one-half compared to sites using older HTML-based methods of page design and layout. The first standard for CSS was formalized as a W3C recommendation in 1996.

Certain sites may be mandated or find it cost-efficient (due to ROI) to support very old web browsers, which we may informally refer to collectively as "Netscape 4 and earlier" (NN4) or "Internet Explorer 6" (IE6). Even such browsers can benefit from a carefully coded, HTML+CSS site's content. But in order to render today's internet correctly, older browsers are more likely to need coded workarounds or even reversion to an older, verbose coding style in order to achieve a look and feel equivalent to that of more standards-compliant browsers.

In earlier years, designers treated older browsers with a design principle known as "graceful degradation." Some page elements would not work, or may not even be visible, but the content would remain at least marginally accessible. It was "graceful" if the page didn't look obviously broken and nothing prevented the user from gaining access to the content. The oft-unspoken presumption was that users of older browsers were used to seeing a poor version of most sites, so a poor rendering in those browsers would not reflect poorly on the site in the eyes of those users.

But time has passed, and web-design philosophy has shifted from graceful degradation to "progressive enhancement," which presents a well-designed web page to today's less-capable browsers, with design and feature upgrades possible for browsers that have adopted the standards more progressively and accurately. At the time of this writing, users of minority browsers like those mentioned above account for only a small percentage of most sites' visitors, often less than 2%. But for some web site owners, it still makes sense to go to the lengths necessary to support them. Similarly, a distinct minority of visitors to a web site will have disabled Javascript in their web browsers, another factor developers and even marketing departments must consider.

It is considered poor practice to deploy code intended to work correctly only in a single browser.1 Choice of one's browsing software (or equivalent assistive device) is to be left to the sole discretion, preference and needs of the end user. And despite any eagerness to embrace new standards, developers mustn't consign users of yesterday's browsers to a less-than-functional or transactionally challenged shadow of the intended user experience.

See also:

1. Exceptions include institutional and dedicated systems where the supported hardware and software may be controlled or mandated. Even there, however, federal workplace regulations might require that users of relatively standards-compliant assistive devices have equal access to everything that is also available to users of the mandated browser, without hindrance. Organizations contemplating mandating use of a single browser by its employees or other users may wish to seek legal counsel about their obligations, if any, to support other (types of) browser.

The fact remains that supporting older browsers requires additional design forethought and coding considerations, and may add to the time and cost of development. (The same can also be true of supporting mobile devices with screens optimized for their display sizes and the context of their uses.) Site owners should evaluate the importance of support for old browsers, and be aware of the tradeoffs and foreseeable consequences before including them in the list of browsers to be supported by a new web site design.

HTML and XHTML

Adhering to web coding standards makes cross-browser incompatibilities less likely during development and, thereby, makes many projects easier to deliver on time. It also increases a site's likelihood of seamless transition as future browser versions are released.

But standards have a measurable effect on users that goes beyond technical purity and administrative convenience. A web browser can render standard code efficiently. But non-standard code on a web page triggers the web browser's "quirks mode," in which it must go to more-laborious lengths in an attempt to make the page render well. That slows the browser and can even make a web page feel noticeably sluggish to its users, depending on the many variable issues involved.

In general, we recommend the XHTML 1.0 coding standards, another activity of the W3C. Used with CSS, this can allow a web page to be designed for platforms as different as desktop displays, smartphones and other mobile devices (PDAs), dashboard devices and specialized browser clients for the visually and physically challenged. The XHTML code says, "This is a paragraph," and the CSS says, "A paragraph looks like this" in print, on the screen, on handhelds, etc. As a very minor example, certain elements of this site — like the navigation — do not display when printed because we deem them irrelevant to that medium. (This site does not yet make full use of alternate-device stylesheets, but adoption of the CSS and XHTML web coding standards makes that achievable with minimal effort.)

To Validate or Not To Validate?

Online validators provided by the W3C, and perhaps other validation services, make it easy to test whether a web resource conforms to the standards. Is it necessary to validate your site's code? In general, no. Is it a good idea? Usually. Canny developers will use validators intelligently and, if it is appropriate and acceptable, may publish a well-tested web page whose code does not pass validation. They will be aware of the tradeoffs and act thoughtfully.

Techniques intended to coerce validation of non-standard code should be generally mistrusted and usually avoided. Forced validation might fool the validator, or one's manager, but the code might still trigger a browser's quirks mode, or worse.

External Design's Approach

Our work focuses on getting good results for our clients, including our client sites' equivalent look and functionality across computer platforms and browsers. We look at how many of a current site's visitors are users of old browsers. The site owner often can deduce how many of those visitors convert to meaningful contacts, so we consult with the client on how backward-compatible their sites need to be to achieve their business goals and the desired results from their investment.

In most cases, we now advocate a XHTML+CSS approach with Javascript and, sometimes, Flash. Flash content is only developed with the knowledge that certain popular devices may not support it, so alternate content must be provided for any Flash material. And HTML tables may be used, but to a lesser degree and as tables in general are intended—for tabular or columnar data, and only quite rarely, if at all, for layout purposes. Inline style tags are more sparse and succinct.

Rationale

The XHTML and CSS standards improve accessibility and enable more-consistent, reliable performance from web browsers. They streamline the code, in the hands of experienced developers, thus reducing bandwidth and improving both developer and user experience. They also simplify content integration and maintenance, and lead to the development of web resources more likely to be compatible with future web browser releases. Even dynamic content is more easily served because its markup can be freed of hand-coded style overrides.

In a Perfect World

We prefer to keep the sites we produce free of workarounds that fix obscure rendering issues in specific browsers. But even some major browsers have CSS bugs, or deficiencies, and some businesses must support users of browsers that were developed before today's standards were published.

The terrain is not as rocky as it once was, but still, it is possible to stumble. We work with each client to understand the business at hand and specify the project requirements, then adopt appropriate technical approaches to ensure a smooth development process and a reliable, effective result.

Sunday, 05 February 2012