Testing and Debugging CSS Program
Checking Punctuation
The single best advice for those times when your CSS code isn’t working is to check your punctuation. Unfortunately, CSS was designed to include several punctuations derived from the C-type computer languages. This means that you have to use braces, colons, and semicolons where more sensible punctuation — or no punctuation at all — would have worked just fine.
Validating Your Work
Ensuring that your CSS or HTML code has no problems is called validating. This process can assist you in locating actual bugs and can also provide other useful information. For example, validation can warn you that you’re using “nonstandard” HTML tags or other features that work in Internet Explorer but might not always be supported in future versions or that may not work in other browsers such as Netscape.
Ignoring Fringe Browsers
As I’ve mentioned elsewhere in this book, to me, Netscape and the other fringe browsers are of negligible impact on my programming because so few people use them. Internet Explorer is the standard — it won the browser wars. So I’m a bit puzzled why other books on CSS and HTML spend 30 percent of their time worrying about how to ensure compatibility with, for example, Netscape 4 (which probably nobody still uses) or Opera and the rest. You should see some of the multiple if . . . else complexity in some scripts — attempting to accommodate every last possible browser variation. Rather than spend lots of time on these minor compatibility issues, I’ve instead used the space saved to explore and demonstrate additional CSS features and capabilities.
What if you must consider compatibility?
I do, however, realize that some designers must, for various reasons, take into account alternative browsers and older versions. If that describes you, I think you’ll find most all the information on CSS in this book is still of use to you. It’s merely that after designing your Web page, you have an extra step to take: Run the page through a validator, or, better yet, load it into Firefox, or Netscape 4, or whatever browsers you’re worried about. You’ll immediately see what, if anything, needs to be adjusted or worked around.
Sniffing browsers
Browsers are divided into two primary categories: up level and down level. Down-level means that they support HTML 3.2 (no scripts, no CSS). Up level browsers support HTML 4.0 and later, and consequently they can also handle JavaScript 1.2 and CSS.
Experts suggest several solutions to handling browser incompatibilities, none of them entirely successful. You can provide a splash screen or special page that you show users before you show them your home page. On this page are links to alternative home pages that, for example, don’t rely on CSS if the user’s browser doesn’t support it.
Forcing users to upgrade
If you want to severely discipline any wayward visitors to your site using weak or outdated browsers, you can use what’s called a DOM (document object model) sniffer. If they are using a browser that’s not up to your standards (in other words, if your page won’t look the way you like in their bad browser), tell them to upgrade. You redirect them to this location.
Trying Out the W3C Validator
W3C — the World Wide Web Consortium (W times 3, get it?) — offers a way to test your Web pages’ HTML and CSS code. However, the W3C offers debugging utilities (they call them validators) that are so strict and exacting that you might want to consider alternative utilities.
Before you even resort to a professional utility, I suggest you first try to locate errors in your code by yourself. Not only do you find the problem fairly often, but this approach helps you to remember what to watch out for (what your personal boo-boos often are). Also, a validator tends to give you more information than you want. It might tell you not just what doesn’t work, but also what doesn’t work in some obscure browser, or what might not work in the future.
Lastly Comment
Sometimes, in the warning section, you’ll find a valuable suggestion. Consider this possibility: You neglected to specify a background color for one of your paragraphs of text. You did specify that the foreground should be dark green, and you assumed that the background would remain the default white.
But what about those people who’ve got their own user style sheets turned on or are otherwise customizing their browser’s behaviors and display characteristics? What if one of them has set the background to a color that makes your dark green text pretty much unreadable? The warning section of the validation report makes suggestions about this kind of problem, and even if you ignore many of those suggestions, at least you’re able to consider them and make an informed decision.