You’re viewing an archive of outdated material. Visit The Web Standards Project’s updated site to learn about our current mission.
action | mission | members | resources |
HELP & TIPSCut ’n paste fun! Add this banner to your site, and link up. USEFUL STUFFNYPL XHTML Style GuideGetting started with valid XHTML and CSS W3C HTML Validator(also validates XHTML) W3C CSS ValidatorW3C Accessibility GuidelinesBobby Accessibility ValidatorCSS & DESIGNTantek Çelik’s CSS box model hackA List Apart’s Web Designer's JourneyBlueRobot’s CSS Layout ReservoirGlish’s CSS Layout TechniquesGlish’s CSS Layouts: The Good, the Bad, and the UglyOwen Briggs’s Little Boxes visual layouts pageOwen Briggs’s Box Lesson Problem & Workaround SetThe WaSP thanks David Eisenberg, Tantek Çelik, and Jim Heid for research, suggestions, and moral support. |
CAST OFF YOUR CHAINS! Well, anyway, quit spending so much time worrying about backward compatibility that your sites end up lacking forward compatibility — the ability to remain viable in upcoming browsers and devices. For instance, husqvarnaviking.com is an attractive and expensively produced site designed to the quirks of 4.0 browsers and not updated since. As a result, users of newer, more compliant browsers are actually sent away (or told to get an old browser if they wish to see the site). This kind of coding does nobody any good: not the site’s owners and not web users. If you're confused about (X)HTML, CSS, and validation, read the NYPL Style Guide. If you don’t understand the premise of authoring to common standards instead of to the peculiarities of individual browsers, read “Why Don’t You Code For Netscape?” at A List Apart. ABOUT THESE TIPSTwo methods are described below. One might be better suited to your site than the other. You can also evolve your own techniques. This page is just a starting point. Method 1 (DOM SNIFF) is radical and is not appropriate for every site. What it does is redirect non–compliant browsers to an “upgrades” page—yours, or ours. If you use this method, we encourage you to create your own upgrades page, tailored to the needs of your particular audience. Method 2 (INVISIBLE OBJECT) enables all visitors and devices to access your site’s content, but alerts visitors using non–compliant browsers to the existence and ready availability of better browsers. Used in combination with techniques (such as the import method) that protect bad browsers from Style Sheets they can’t handle, this can be an effective means of serving all users while encouraging upgrades and supporting standards. THE TOOLSMETHOD 1: DOM SNIFFAfter creating a valid web page, insert this script in the if (!document.getElementById) { window.location = "http://www.webstandards.org/upgrade/" } In a global .js file, the code would look exactly like it does above. If you're inserting the script on an individual page, of course, you would type it between <script type="text/javascript" language="javascript"> <!-- // if (!document.getElementById) { window.location = "http://www.webstandards.org/upgrade/" } // --> </script> In STRICT documents, you’d either use a global .js file, or insert this: <script type="text/javascript"> <!-- // if (!document.getElementById) { window.location = "http://www.webstandards.org/upgrade/" } // --> </script> If you prefer, you can just as easily send visitors to an upgrade page on your own site: if (!document.getElementById) { window.location = "http://www.yourdomain.com/yourpage.html" } WHEN YOU MIGHT USE THISIf you're creating pages that rely heavily on the W3C DOM and ECMAScript, those pages could fail in non-compliant browsers. On such a site, this technique would protect folks from viewing content their browser can’t handle. WHEN YOU MIGHT NOTIf your pages don’t rely on advanced, standards–compliant scripting, using this technique might win you more enemies than friends, and you might prefer the “kinder, gentler” OBJECT method described later on this page. WHY IT WORKSW3C DOM–capable browsers will ignore this bit of fluff, because WHY YOU MIGHT LIKE ITIt’s foolproof in any JavaScript–capable browser, so long as the web user has not disabled JavaScript. You won’t have to worry about anyone in your audience seeing web pages their browser can’t handle. You might have to worry about a few angry letters, though. WHY YOU MIGHT NOT LIKE ITLike we said, you might get a few angry letters. For that reason, we generally recommend the kinder, gentler, OBJECT method shown below. If you prefer to take a “belt and suspenders” approach, you can combine both methods. METHOD 2: INVISIBLE OBJECTThis method lets everyone access your site, but alerts audience members using older browsers to the availability of standards–compliant ones. If you’ve separated style from structure by using CSS for layout and (X)HTML for markup, this method will also let users of older browsers know why the site looks different, while reassuring these users that you have no intention of abandoning them. The message is hidden from folks who use browsers that comply with W3C recommendations and have CSS turned on. HOW TO DO ITAfter creating a structurally valid HTML 4.x, XHTML 1.0, or XHTML 1.1 page, add an “ahem” declaration to your global Style Sheet, like so: .ahem { display: none; } Naturally, you can call it anything you like. You can call it “invisible.” You can call it “clauderains.” We just kind of dig “ahem.” Then in the <h1 class="ahem"> This site will look much better in a browser that supports <a href="http://www.webstandards.org/upgrade/" title="Download a browser that complies with Web standards."> web standards</a>, but it is accessible to any browser or Internet device. </h1> The message will be hidden from CSS–compliant browsers as long as CSS is turned on. There is no possibility of crashing any browser, because all you’ve done is add a CSS class to an HTML headline. If you find it more appropriate, you can use a If you’ve crafted your message carefully, it will not offend anyone. However, you may prefer to hide the message from standards–compliant (but limited) user agents like Lynx and iCab, from Palm Pilot and similar device users, and from those who use current browsers with CSS turned off. If so, in an HTML document, you might use an When doing something like this, consider your audience before anything else. What kind of message is likely to encourage them to visit your Upgrades page? What kind of message might turn them off? We think the following is a good one, but we encourage you to fine–tune it or replace it with your own:
This site will look much better in a browser that supports web
standards, but is accessible to any browser or Internet device.
WHY IT WORKSCSS browsers will read the Style Sheet, will see that the text is supposed to be invisible, and therefore will not display it. Older browsers will. WHY YOU MIGHT LIKE ITIt’s kinder and gentler than forcing your visitors to go somewhere unexpected, and it leaves them with the choice. If visitors prefer to view your content in their old browser, they still can. The other nice thing about this method is that it works even when visitors have JavaScript turned off. WHY YOU MIGHT NOT LIKE ITIt takes guts to turn off your design in browsers that can’t handle it. And no matter how politely you word your “upgrade” message, some visitors will see it as an intrusion (and will see your having turned off the design as a “punishment”). Supporting standards is easy: author to (X)HTML, CSS, and other specs, and validate your pages before publishing them. Handling the complex needs of your audience is not as easy. Good luck! And now back to our regularly scheduled program. |
||