Chapter Two: Philosophies and Techniques

The web is a mere 5,000 days old. By comparison, the first 5,000 days of television are almost unrecognizable as what we consider “television” today. Similarly, twenty years after its introduction, cinema was still a novelty. Not so the web, which is now used by roughly a quarter of the world’s population. But for all its impact on news, business, politics, and culture, the web is still in its infancy, and we’re still only beginning to understand how it works as a medium. On the surface, the fundamental ways in which users interact with websites—via pages, links, and forms—haven’t changed much in over a decade. But despite this seeming stasis, a great deal has happened to the practice of web development in these 5,000 days, and much of it has happened in the last five years.

The Browser Wars

In the 1990s, three major browsers—Mosaic, Netscape, and Internet Explorer—alternately dominated the web and essentially dictated what the web’s technologies would be. Browser makers created their own extensions to HTML, introducing such features as fonts, colors, tables, and frames, without the involvement of any standardizing organization. As these features were introduced, makers of competing browsers reverse-engineered these new, usually poorly-documented features and countered with their own. As the decade progressed, features like JavaScript and the DOM were implemented and released to the world still without the involvement of any standards body. Web developers, meanwhile, scrambled madly to keep up, and were constantly forced to decide whether a new feature was likely to take off before investing the time required to learn and use it.

The accelerating browser wars threatened to fragment the web into its own kind of tower of Babel, where everyone spoke a different language. Into this chaos stepped the World Wide Web Consortium (W3C), an organization made up of member companies and institutions with significant interests in the web and founded by Tim Berners-Lee, the inventor of the World Wide Web.

The Dawn of Standards

Just as the UN brokers ceasefires and peace agreements, the W3C and other standards bodies and organizations, such as the ISO, the IETF, and Ecma International, brought together competing companies to agree on common web standards, like HTML and CSS, that would underpin the web.

But the standards-based web is not only a consequence of the existence of the W3C and these other bodies. Standards only work if they are adopted.

As key W3C standards emerged and began to be widely implemented in browsers like Netscape 4 and Internet Explorer 4 (often called the “version 4 browsers”), a small but influential group of web developers exemplified by The Web Standards Project (WaSP) used the medium of the web itself to promote the concept of a standards-based web to their fellow developers—and to encourage browser developers to support web standards. The resulting combination of formal standards bodies, grassroots advocacy organizations, and individual standardistas ushered in the standards-based web we have today. Successive generations of web browsers embraced standards support, and fewer and fewer innovated outside the context of standards.

Web Standards Today

When we speak of standards today, the key technologies we are referring to are:

• HTML/XHTML from the W3C

• Cascading Style Sheets (CSS) from the W3C

• The Document Object Model (DOM) from the W3C

• JavaScript (also known as “standard EcmaScript”) from Ecma International

• Image formats such as PNG and SVG from the W3C, and JPEG from the ISO

• Accessibility technologies like WAI-ARIA from the W3C

But standards-based development doesn’t refer only to the use of these technologies. It also involves a philosophy of development, one that emphasizes accessibility and platform independence—an approach that lives up to the name “World Wide Web”—with a central commitment to make web content and applications available to as many people as possible.

Why Should I Care?

But why should we, as developers, care about standards? If a technique works in common browsers, that’s good enough, isn’t it?

For those old enough to remember CDs, imagine that you bought a CD, and put it in your car stereo, only to have your stereo inform you that the CD was best played in a SONY player—and that as you listened on your non-Sony player, tracks skipped or wouldn’t play at all. (Actually, something very like this did happen several years ago, producing a collective shriek of rage from consumers who’d unknowingly purchased the non-standard CDs.) The reasons why a CD will play in any CD player, a DVD in any DVD player, why wrenches and other tools match nuts and bolts of a particular size, why you don’t have to buy Ford-branded gas, is because in all these areas, standards enable interoperability. If your gas was only mostly compatible with your car, you’d have a problem. And in the years before web standards were established and adopted, we did.

Standards are about interoperability: they mean you can choose which tools you want to use to develop and manage content, and then change those tools if you wish, all without being locked into a particular vendor or proprietary technology. They mean you can choose different browsers depending on your need. They mean no one controls the flow of information around the web.

Standards benefit everyone: content creators, web users, tool developers, browser developers, and web developers alike.

How to Develop for the World Wide Web

The first two words in “World Wide Web” are usually overlooked. But developing for a genuinely world wide web means focusing on the interoperability and longevity of the content we develop. Here, I’ll outline some of the most important themes to consider when developing for the web.

It Doesn’t Have to Look the Same in Every Browser

Not long ago, it was still common to see “best viewed in” badges on websites. These clearly indicated that a site was “optimized” for certain web browsers, and too bad if you were using any other. Too bad if your non-optimal browser was mandated by your IT department. Too bad if you had poor eyesight and needed to use a browser that could help you access content.

These badges are largely a thing of the past, but their underlying philosophy lives on in more subtle ways. Its core principle is that we are designing and developing for browsers. We aren’t. We are developing for users. A user is often a person, but can also be a piece of software, like a search engine. And the philosophy of the “World Wide” web is that we should develop our sites in ways that provide access to as many users as possible. Many developers (and marketing departments) think this means that our sites should, or even must, look the same in every browser. In fact, the opposite is true. By striving to make our sites identical across all browsers, we can quite easily exclude users. By, for example, fixing the width of a column of text to 600px, we may well exclude users of mobile devices.

And, in truth, our sites will never look identical in every browser, no matter how hard we try. Even two different screens attached to the same computer will quite probably display the same page differently. And users can resize their windows, zoom their text, and specify preferred fonts, colors, and so on that override your design choices.

So, if we can’t make sites appear the same in every browser, what should we do—just give up?

In a sense, yes. Embrace the web’s flexibility as one of its greatest strengths, not as a weakness. After all, the technical term for a browser is a user agent—a phrase you’ll see quite a bit in this book. As the term reveals, it’s the user who is intended to control his or her web experience. It’s users who should be able to choose how they view and interact with the web. We have to give up the notion that designers and developers are the ones who are in control. We aren’t—and we never really were, even in the days of pixel-perfect “cross-browser” site designs.

But what does this mean in practical terms?

Progressive Enhancement

One of the concepts you’ll see over and over in this book is progressive enhancement. Progressive enhancement is a design practice based on the idea that instead of designing for the least capable browser, or mangling our code to make a site look the same in every browser, we should provide a core set of functionality and information to all users, and then progressively enhance the appearance and behavior of the site for users of more capable browsers. It’s a very productive development practice. Instead of spending hours working out how to add drop shadows to the borders of an element in every browser, we simply use the standards-based approach (box-shadow, detailed in Chapter 13) for browsers that support it and don’t even attempt to implement it in browsers that don’t. After all, the users of older and less capable browsers won’t know what they are missing.

The biggest challenge to progressive enhancement is the belief among developers and clients that websites should look the same in every browser. As a developer, you can simplify your life and dedicate your time to more interesting challenges if you let go of this outdated notion and embrace progressive enhancement. To do so, you may need to convince clients and bosses of the benefits as well, and common ways of doing so include emphasizing lower development costs, more maintainable code, and the fact that most users use only one browser and won’t know the difference anyway. Another beautiful thing about this approach is that as your users upgrade browsers, their experience on your site will improve automatically, without you touching even a single line of code.

Separation of Content, Presentation, and Behavior

If progressive enhancement is one pillar of modern web development, the separation of your site into three layers—markup, presentation, and behavior—is another. This means that our semantically structured content goes in the markup, the code that defines the content’s appearance goes in CSS, and any front-end interactivity goes in the JavaScript. We’ll return to this central concept throughout this book.

Once More, with Meaning

It’s easy for designers and developers to get caught up in the appearance of a website or web application, but much of the real beauty of the web lies beneath the skin. If we develop our sites only to please the eye and ignore the needs of software, like browsers and search engines, we miss more than half of the users of our work. Software doesn’t care about font sizes or colors. It cares about the underlying structure and meaning of our markup. Browsers and search engines can’t yet be said to really understand English (or Mandarin or Swahili), but they can understand a lot about the nature of our content if we mark it up correctly. When a browser, or search engine, or other piece of software knows that this piece of your page is a heading, that is an address, this is navigation, and so on, that software can do all kinds of interesting things: it can automatically build tables of contents for people who can’t see, for example, or detect a location and display it on a map. But to do this, it needs to understand the semantics—the meaning—of your content. Throughout the book we’ll focus on how you can make your markup semantically meaningful.

For My Next Trick

Now it’s time to start actually developing with web standards. We’ll begin in Chapter 3 with the fundamental web standard that started it all: HTML.