Web development coding standards

Internet-related coding standards, why website owners should care, and their effects on usability, execution speed in the browser, and the costs of maintenance and development.

HTML, CSS, and Javascript

Just a few languages support most front end web development. Developers use them to encode a site’s content, its visual form, and certain of its functions. They are not the only such tools but they are the most common and provide the essentials.

“Back end” languages run on the web server, and may include PHP, SQL, and others; in general, they are not as concerned about how a site looks as they are with what will be displayed and what functions are available to visitors and administrators.

These languages evolved along with the internet. CSS supplanted code-heavy HTML techniques once commonly used to define web pages’ layout. By shifting layout-and-style duties to CSS, HTML refocused on tagging content with succinct codes that identify text as, for example, a paragraph, a heading, or a path to an image. There are some defaults, but HTML itself doesn’t determine with any specificity what things look like or where they belong on the web page. CSS does much of that. This results in improved separation of content from markup code, and typically makes a website’s development and maintenance more efficient, more easily maintained, and more even affordable.

Javascript has evolved, too. In the dawn of its evolution, some people had security concerns related to it and others worried that its injudicious use would too greatly tax the computers of the time. Some companies forbade it on office computers, and many users chose to disable Javascript in their web browsers. Developers had little choice but to compose their code in a way that would accommodate browsers with and without Javascript.

Web browsers today are more likely to interpret Javascript code in a standard way. It is common now for websites to require it in visitors’ browsers. Now, web browsers on some devices do not provide an obvious way to disable Javascript. It is still courteous and good practice to display a reminder to users whose Javascript is not active, but the number of visitors who will see that message may be statistically negligible for many sites. Some sites, such as those with mission-critical functions or that are safety related or concerned with users’ immediate health and well-being, may still need a non-Javascript alternative because although the chances of needing it may be small, the potential cost/liability of not planning for it may be high.

Generally, HTML with CSS offers a streamlined alternative to code-heavier methods of implementing web designs. In general, a site employing CSS efficiently:

• requires less code, downloads faster
• may render faster in the browser
• can eliminate some Javascript, effects may execute faster
• simplifies updates and maintaintenance of site content and code
• adapts more easily for mobile devices, other display sizes, and print

Change and evolution proceed apace. Some inconsistencies remain in browsers’ intrepretations of the standards but, usually, workarounds can be found or the differences are negligible in all but the most demanding, pixel-perfect cases. (See our “browser stress test” on this page.)

It is worth noting that CSS cannot and was never intended to entirely replace Javascript; and tabular data still may be best represented using HTML tables that formerly were forced to serve layout purposes. Each technology has its strengths and appropriate uses.

Older web browsers

From graceful degradation to progressive enhancement to responsive design

Certain websites may be mandated or find it cost-effective (due to ROI) to support very old web browsers that have not adopted modern standards. Site owners should be aware of the costs associated with making a website perform for outdated browsers.

In order to render today’s web content correctly, older browsers are more likely to need workarounds or even reversion to an older coding style in order to achieve an equivalent look and feel. This may add to development costs, increase maintenance time, and contribute side effects that should be evaluated when making the business decision whether to support older browsers.

It is considered poor practice to deploy code intended to work correctly only in particular browsers.¹ A user’s choice of web browser (or assistive device for visually impaired users) must be left to the discretion, preference, and needs of the end user. Despite any eagerness to embrace new standards, developers mustn’t consign users of yesterday’s browsers to a shadow of the intended user experience.

1. Exceptions include institutional and dedicated systems where the hardware and software may be mandated. Even there, however, workplace regulations might require that users of assistive devices have equal access to everything that is available to users of the mandated browser. Organizations deciding whether to mandate use of a specific browser by its users may wish to refer to federal guidelines and/or seek legal counsel about the obligation, if any, to support other browsers and devices.

HTML and XHTML — web development coding standards

Adhering to web coding standards makes cross-browser incompatibilities less likely and makes many projects easier to deliver on time. It also increases a site’s likelihood of seamless transition as future web-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; non-standard code triggers a browser’s quirks mode, in which it goes to some lengths to interpret a page’s intended appearance. That slows the browser and can make a web page feel sluggish to the user.

An HTML coding standard, perhaps with others for CSS and Javascript, can allow a web page to be designed for platforms as different as desktop displays, smartphones and other mobile devices, dashboard instruments, and specialized browsers for the visually and physically challenged. The HTML says, “This is a paragraph.” The CSS says, “A paragraph looks like this…” in print, on the screen, on mobile devices of various sorts.

To validate or not to validate?

Online validators provided by the W3C, and perhaps other services, make it easier to know whether a web asset conforms to one of 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, acceptable, and necessary — may publish a well-tested web page whose code doesn’t pass validation. They should, however, be aware of the tradeoffs and act thoughtfully.

Managers of WordPress and other CMS-based websites might include validation as a way to identify themes, plugins, and other assets that might be generating non-standard code. Informing the authors of non-validating software, so they can take corrective actions, may be a service to the wider community because of the impact non-standard code can have on performance, cost, and maintenance.

Techniques intended to artificially coerce non-standard code into passing a validator should be mistrusted. Forced-validation might fool the validator, or one’s manager, but the code could still trigger a browser’s quirks mode, or worse.

In a perfect world

We prefer to keep websites free of workarounds that address obscure issues. But even major browsers may have deficiencies — or differing interpretations of the standards — and some businesses must support users of archaic browsers.

We assess a client’s audience when planning our code approach. We take the time to understand the business at hand, then adopt appropriate approaches to ensure a smooth development process and reliable, effective results.

External Design’s approach

We prefer code that validates but we do not always insist on it.

Our work focuses on achieving good results for web projects. That doesn’t always require code that validates, or that is perfectly standard, but the potential impact on performance and maintenance is real.