at this time
RETURN WITH US to 1998. The web was no longer the exclusive playground of geeks. Creative web design had long ceased to be an “underground” phenomenon. Every corporation on earth was “building an online presence” whether it needed to or not. Chortling venture capitalists knew in their hearts that the money machine would never run out of steam. Netscape and Microsoft each claimed about 50% of the browser market, and their 4.0 browsers were almost entirely incompatible.
Into that miasma of giddy hype, foolish dreams, and broken websites, The Web Standards Project (WaSP) intruded with a practical message practically nobody wanted to hear: If Netscape and Microsoft persisted in building ever–more incompatible browsers, the cost of development would continue to skyrocket, tens of millions would find themselves locked out, and the web would fragment into a tower of digital Babel. In fact, we said, it had already begun to do so.
We also pointed to the solution. Tim Berners–Lee, the inventor of the web, had founded the World Wide Web Consortium (W3C) to nurture and recommend technologies such as CSS and XML that would enable the fledgling medium to remain open, interoperable, and accessible. If fully supported, these techologies would enable designers to design and developers to create functionality far beyond the capabilities of any individual web browser.
Indeed, with solid support for W3C recommendations, which we referred to as “web standards,” the web could expand beyond the browser without incurring additional fragmentation into incompatible wireless models.
OUR MESSAGE did not go down easy. As competitors, Netscape and Microsoft were disquieted by the notion that they should support the same, open technologies. As powerful companies, they were also quite naturally uncomfortable with the idea that anyone—including the people who actually built the web—had the right to tell them what they should or should not do.
Between 1998 and today, we persevered, and ultimately the browser makers listened. (In fact, engineers at both companies agreed with us, and privately delighted in our efforts to persuade the managers in charge to let Engineering do the right thing.)
Today, with most web users accessing the medium via products like Internet Explorer 5+, Opera 5+, Netscape 6, or Mozilla, we have solid support for many web standards, and The WaSP’s mission would seem to have been accomplished.
YET IN SPITE of the efforts of the W3C, the browser makers, and a leading–edge minority of designers and developers, most of the web remains a Balkanized mess of non–valid markup, unstructured documents yoked to outdated presentational hacks, and incompatible code fragments that leave many millions of web users frustrated and disenfranchised.
Browser makers are no longer the problem. The problem lies with designers and developers chained to the browser–quirk–oriented markup of the 1990s—often because they don’t realize it is possible to support current standards while accommodating old browsers.
It lies with “helpful” software that generates sites optimized for 4.0 browsers with nary a thought for document structure, open standards, separation of structure from presentation, or the long–term durability and viability of web documents. The resulting sites quickly become useless unless their browser–specific markup and code is continually updated to reflect changes in the browser market. In today’s economic climate, few site owners can afford such perpetual revision. Thus these once–ripe sites begin to rot.
Above all the problem lies with clients who confuse the web with print. Who insist on pixel-perfect rendering of their sites in user agents incapable of such renderings except at the expense of interoperability, accessibility, and document structure. And who are so concerned with “backward compatibility” that they neglect the far more important issue of forward compability.
So your site looks the same in Netscape 4 as it does in IE6. Mazel Tov. How will it look and function in a 7.0 browser? In a wireless device? On a web phone? In a Braille reader? What will become of your expensively–produced web documents in two years? In five?
As we once spoke to browser makers, now we address a challenge to our colleagues in design and development, to our friends in the web software industry, and to our clients: W3C standards, supported in all popular browsers, are the only means of ensuring that the sites you build today will work for all—today and tomorrow.
If not now, when? If not you, who?
AT THIS TIME, The Web Standards Project takes a gentle leave of absence. In the interim, we will make ourselves heard in other ways, in other places — and perhaps mark the occasion with a small note here.
We may well do new things here, too, after a little time off to regroup. We will of course continue to maintain and update our Browser Upgrades initiative.
You may, if you wish, view the older materials archived on this site, including our original 1998 Mission Statement, our Action Page (covering browser upgrades and your role in helping browser makers plug holes in their standards compliance by reporting bugs); our Educational FAQ (“What are Web Standards and Why Should I Use Them?”); and our general WaSP FAQ. With the exception of the aforementioned section on Reporting Browser Bugs, these are historical materials that will not be updated.
We hope to launch new initiatives and a new site in the coming year. Meanwhile, if you are interested in implementing W3C recommendations, we recommend the following resources:
- World Wide Web Consortium
- The mother of us all.
- NYPL Standards–Compliant Style Guide
- An easy XHTML and CSS tutorial from The Branch Libraries of The New York Public Library.
- How To Read (W3C Specs)
- Just like it says.
- DOCTYPES
- A guide to those all–important document type identifiers.
- CSS Guide
- A complete online tutorial on Cascading Style Sheets (CSS).
- Little Boxes
- Look, Ma, no HTML tables! Click a layout, view the CSS that built it.
- Size Matters
- Working around incompatible CSS keyword implementations. (Note to the easily flustered: the model is wearing bathing trunks.)
- Fear of Style Sheets 4
- CSS techniques when you absolutely, positively have to support 4.0 browsers.
- Alternative Style
- Making sites more accessible, more customizable, or just plain funkier via cross–browser dynamic switching between alternate Style Sheets.
- WAI Guidelines
- Instructions on making your site accessible.
- W3C Validator
- Check your (X)HTML markup for errors.
- CSS Validator
- Check your CSS for errors.
- Bobby
- Check your site’s accessibility.
- 1–click validators
- Validation bookmarklets from David Lindquist.
- Favelets
- Validation bookmarklets and more from Tantek �elik.
Web Review, a commercial online magazine for web developers, publishes many standards–related articles and tutorials, as do Evolt and A List Apart, two non–commercial ’zines/forums by and for designers, developers, and “content” creators. We recommend all three.
And with that, for the moment, adieu.
The WaSP
[Gently revised 16 December 2001 in response to community feedback]