Since the publication of the first IETF draft specification for HTML, browser vendors and site developers have made a frequent bad habit of disregarding published web standards. At the same time, the community of developers who make a point of respecting those standards (of which this author considers himself a devoted if usually quiet member) has never been anything but vocal and predictable, if not actually disciplined. There are a number of issues at work behind the scenes of the ongoing debate.
Note
This section addresses web standards as they are typically promoted.
Untested assumptions about visitors are a big mistake. Common adherence to standards would reduce the number of assumptions. Developers could build their sites and deploy them with a minimum of platform testing. And who doesn’t want that?
The virtues of interoperability do not, however, harmonize easily with the hot desire for bells, whistles, and pretty things often felt by artists and marketers. Browser vendors cannot ignore the imperative to innovate, and the market usually works on a shorter life cycle than the standards acceptance process.
Market forces are what drove the prospect of common standards
compliance off the rails in the first place. In early 1995, table support was introduced in Netscape 1.1,
while codification of earlier enhancements brought to market by Mosaic
2.0 was still awaiting acceptance. In effect, Netscape—then still
deserving of the “startup” label and two years from its groundbreaking
entry into the equity markets—was capable of running circles around the
standards adoption process, and the market responded. The resulting
conditions nurtured a diffident attitude toward web standards that
persists more than a decade later.
It is often argued that standards compliance ensures the longevity of sites that
respect it; while features are often added to user agent platforms, they
are rarely removed or disabled (the blink element being a notable but absurd
exception). Older standards, meanwhile, tend to lie within the lowest
common denominator of features supported by all user agents. The upshot
of these two facts is that standards compliance allows sites to better
survive across browser versions.
Standards compliance tends to make materials more accessible to impaired users, many of whom rely on various forms of third-party assistive technology to ensure a meaningful experience. The standards are a useful guide in this respect for a number of reasons:
While not enforced by an impartial body, W3C Recommendations are authoritative and as such are incorporated into requirements of statute law relating to accessibility, especially in the United States.
The published Recommendations provide vendors of assistive technology with baseline expectations for their customers’ browsing environments, even when that baseline follows lowest common denominators.
From the beginning, one of the principal design goals of HTML has been cross-media compatibility, which makes it easier to create technology.
After the release of Internet Explorer 6 in 2001, Microsoft’s attention to the web user experience entered an era of somnolence that has only just definitively ended with the release of Internet Explorer 8, a substantial upgrade.
IE6 was released at a time when market shares of competing user agent platforms were on the wane, and the public understanding is that Microsoft made a strategic decision to rest on its laurels until developer community outcry—driven by an official United States Government recommendation to stop using Internet Explorer altogether, among other factors—encouraged it to resume significant ongoing development of Internet Explorer.
A similar incident illuminates Netscape 4’s poor support for CSS. When CSS 1.0 was in development, Netscape and Microsoft offered competing proposals to the W3C, and Netscape’s proposal was rejected outright. It’s apocryphally understood that because Netscape 4 was about to pass its RTM (release to manufacturing) milestone, frantic last-minute engineering of Netscape 4’s rendering engine was required in order to provide any support whatsoever for the W3C-mandated CSS—a necessarily slapdash effort that had long-term consequences for the quality of the browser, to say nothing of Netscape’s viability.
During the era of the Web’s fastest growth, standards were barely on the proverbial radar, and the cost of putting sites into production was high because the tools available at the time were quite primitive.
As a result of those adverse conditions, tremendous investments were made in poorly built web properties and the software that made them go. These properties continue to be nurtured because the cost of replacing them—measured in terms of institutional politics and capital investment—is seen as too high.
This phenomenon most strongly affects typical web developers in the area of third-party content and solutions, particularly news publishing and advertising platforms.
Web shops and solo web developers can be found under a wide variety of institutional umbrellas: solo freelancers, specialist boutiques, large advertising agencies, mass media outlets, online businesses, medium-size businesses, information technology and information services departments of every imaginable size, and departments that have one or two developers fully responsible for the breadth of that unit’s web presence. In addition, there are legions of do-it-yourself-ers, who can be undercapitalized, bloody-minded, or both. Websites are built by all kinds of people, and everyone has different notions of what makes a website good or bad. That difference in judgment of quality and choice of tools, which in large enterprises is compounded by interdepartmental confusion and infighting, results in widely varying ideas of best practices.
An individual’s most valuable web development qualification is neither her level of skill nor her degree of talent, but instead her ability to interact agreeably with teammates and others in order to be effective at her job, a quality frequently called “team fit.” That dynamic is made still more complex by the fact that there is a high incidence of introvert personality traits amongst the population of professional web developers. Finally, the reluctance of many employers to take responsibility for their employees’ ongoing skill development puts considerable drag on the momentum of median skills growth—sometimes to the point of eliminating that momentum completely.
As you can imagine, such an environment can result in wildly differing opinions regarding good and bad.
The most passionate dispute that many developers have with the prospect of standards compliance is that it’s an all-or-nothing affair. The most visible requirement of standards compliance is valid markup, which is too often impossible to publish because of the many challenges explained earlier.
In addition to meeting the extreme challenge of genuine standards compliance, well-intentioned development teams must tolerate the rather shrill and morally superior attitude of many self-styled standards advocates, and the result is a large cadre of professionals who couldn’t possibly care less about standards compliance.
Get HTML & CSS: The Good Parts now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
