Web development coding standards

All about internet-related coding standards, why website owners should care, and their effects on a website’s usability, execution speed in the browser, and cost of maintenance and development. Includes links to key resources.

HTML, CSS, and Javascript

These languages are the triumvirate of most front end web development. Developers use them to encode how a site’s visitor sees its content, the visual form, and certain functions. They are not the only such software tools but they are the most common ones that provide the essentials.

“Back end” languages might run on the web server, and may include PHP, SQL, Ruby, 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 site visitors and administrators.

All these languages have evolved along with the internet. For example, CSS supplanted code-heavy HTML techniques once commonly used to define web pages’ layout. By shifting layout-and-style duties to CSS, HTML has refocused on what it was made for, 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 doesn’t really determine with any specificity what things look like or where they belong on the web page. CSS does that. This has resulted in greater separation of content from markup code, and typically makes a website’s development and maintenance more efficient, more easily maintained, and more 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. As a result, some companies forbade it on office computers, and a significant number of users disabled Javascript in their web browsers. Web developers had little choice but to code their web pages in a way that would accommodate browsers with and without Javascript enabled. Adding to the complexity, non-standard web browsers and browsers with added, non-standard features might require additional code just for them, and a close-but-not-identical Javascript variant appeared on the scene.

Thanks largely to standards organizations, Javascript has settled into one common track. Web browsers today are more likely to interpret web-site code in a standard way. It is common now for websites to require Javascript to be enabled in their visitors’ browsers, to the extent that web browsers on some devices do not provide any obvious way to disable Javascript. It is still courteous and good practice to display a reminder, only 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 older, code-heavy methods of implementing web designs. In general, a site employing CSS:

• 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 display on mobile devices and other display sizes, and for print

Developers, including External Design, use CSS to replace some tasks that formerly were solely the domain of Javascript. With the newer HTML 5 and CSS 3 standards, this evolution has become more solidified, even as browser manufacturers scramble to adopt the newest approved standard features and site developers learn how to reliably use them.

Change and evolution proceed. Not all browsers implement the HTML and CSS standards perfectly, but all major modern browsers offer strong support for them. Elements of HTML 5 and CSS 3 are being adopted more thoroughly by browser manufacturers, but new capabilities require time before they can be relied upon. 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 pixel-perfect, demanding cases. (See our “browser stress test” on this page. It is one example that, using standard-but-cutting-edge code, displays a result that varies depending on how up-to-date the user’s browser is with respect to certain HTML 5 and CSS 3 attributes.)

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 there are real and reasonable costs associated with making a website perform for very 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, verbose coding style in order to achieve an equivalent look and feel. This may add to initial development costs, increase maintenance time, and contribute other 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 of assistive device, for visually impaired users) is to be left solely 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 less-than-functional or challenged shadow of the intended user experience.

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 assistive devices have equal access to everything that is available to users of the mandated browser, without hindrance. Organizations deciding whether to mandate use of a specific browser by its employees, or by other users, may wish to refer to USA federal guidelines and/or seek legal counsel about their obligations, 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 during development and 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 and usually quickly. But non-standard code on a web page triggers a web browser’s so-called quirks mode, in which it goes to laborious lengths to interpret a page’s intended appearance. That slows the browser and can make a web page feel noticeably sluggish to the user, depending on many factors.

In general, we currently recommend adhering to the XHTML 1.0 and/or HTML 5 coding standards. Used with CSS, this can allow a web page to be designed for platforms as different as desktop displays, smartphones, and other mobile devices, dashboard instruments, and specialized browser clients for the visually and physically challenged. The (X)HTML code says, “This is a paragraph” and the CSS says, “A paragraph looks like this” in print, on the screen, on mobile devices of various sorts. As a very minor example, certain elements of this site do not display when printed because we decided they are irrelevant in print.

To validate or not to validate?

Online validators provided by the W3C, and perhaps other validation services, make it easier to know if a web resource 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 does not pass validation. They should, however, be aware of the tradeoffs and act thoughtfully.

Managers of WordPress and other CMS-based websites should include validation as a way to identify themes, plugins, and other assets that might be generating non-standard code. It’s a good idea to inform the authors of such software so they can take corrective actions. This is 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 to pass a validator should be mistrusted and, usually, avoided. 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 the sites we produce free of workarounds that address 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. We assess each client’s audience and needs when planning our code approach. We take the time to understand the business at hand and adopt appropriate approaches most likely to ensure a smooth development process and a reliable, effective result.

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 each client’s web projects, for audiences using various computers, web browsers, smartphones, and other devices. That doesn’t always require code that validates, or is perfectly compliant with a recognized standard, but the potential impact on performance and maintenance is real.

We may consult with clients’ web-data analytics to look for clues about how backward-compatible their sites should be in order to serve their purposes.