Help! My CSS Isn't Working!

There are two familiar laments of programmers and IT workers the world over: "But it shouldn't do that!" and, "Why doesn't this work?" It's bad enough when you're writing code which you understand (in theory) and can fix. When you're working with a specification, it's even worse, because you can't do anything in the immediate term to change how well the browsers support, or fail to support, the standard.

Sometimes, it's true, the problems are due to incomplete understanding of CSS on the part of the page designer, but that's what these columns are intended to redress (so send me those questions!). Too often, however, the fault lies with the code in the browser itself, which makes mincemeat of what should be perfectly valid stylesheets.

Usually, all you can do about this is either search for workarounds, or abandon your design altogether and try something else. In a few cases, though, there are known ways to cope with browser bugs. In this column, we'll explore a few of them, including the dreaded "disappearing styles" bug in Netscape and an easy way to keep your length values from working.

First, Be Sure You're Right

Upon encountering a problem, the first impulse is often to wonder if the styles are correctly written. Fortunately, there are a number of resources to help you figure that part out. There are the articles here at Web Review, of course, but they may not cover your particular situation.

You need to make sure that there aren't any errors in either your HTML or your CSS, since mistakes in either place can result in botched document appearance. As you're learning CSS, that can be difficult. To that end, you should visit the following sites to check your handiwork:

Of course, if it comes from the W3C, it's probably fairly authoritative. The only drawback with this validator is that it isn't necessarily novice-friendly: a thorough understanding of document and HTML structure helps in interpreting the results.

By contrast, the Web Design Group's HTML validator is much more user-friendly, attempting to present problems in something that passes for plain English. There are also links to articles explaining why validation is a good idea, notes about the validator and its output, and so on.

Again, the W3C is the primary source for deciding what's right and what isn't, but this time the validator's output is a bit easier to comprehend-- possibly because CSS itself is a little more straightforward. This should cover all of CSS2.

Another good tool from the Web Design Group, this validator checks against CSS1 and CSS-Positioning, although not the version which ended up in CSS2. As such, it's a little out of date, but still a worthy tool.

The other place to turn is the Usenet newsgroup comp.infosystems.www.authoring.stylesheets-- otherwise known as c.i.w.a.s. or simply "ciwas," and pronounced "SEE-wass"-- where many CSS experts hang out and provide free advice to all comers. Before you post, though, make sure you run your documents through at least one of the validators listed above. If you don't, and your problem is due to coding errors on your part, you'll get the same list of validators from the experts, with mild admonitions to make better use of them in the future. (Don't worry, they're very mild admonitions: the ciwas regulars are a pretty friendly bunch, with hardly a flamer among them.)

Also, your chances of getting help are vastly improved if you provide a URL to the troublesome page. That way, people can go look at your page, see the problem in action, and examine your HTML and CSS firsthand. If the offending document is trapped behind a corporate firewall, move it to a public server if you can; if not, consider including at least your stylesheet in your post. Even a detailed description of the problem is no substitute for providing the source.

That said, here are a few common author errors, and workarounds for some browser bugs.

Too Many Spaces

For some reason, a very common error on the part of authors is the tendency to put spaces between values and their units. For example:

P {margin-left: 50 px;}

Notice the space between 20 and px? That's wrong. Values and units are never separated by a space. Having the space there will make the value invalid, which means that the entire rule is invalid, which means that your paragraphs won't have a fifty-pixel left margin. Instead, you need to write:

P {margin-left: 50px;}

This is one case where having extra space is definitely a problem, so be on the lookout for it. Either of the CSS validators listed above will catch this too.

Too Much HTML

Another very common author error is the tendency to put HTML in places it shouldn't be-- especially external stylesheets. If you are LINKing or @importing a stylesheet, then there should be no HTML whatsoever in that stylesheet. That includes HTML comments, the <STYLE> tag, or anything else.

So assume that you have the following file, called mystyles.css, which you're importing into HTML documents.

See that HTML comment about adding new styles? It's wrong. Rip it out, delete it, or turn it into a CSS comment, like the first line of the file. Thus, the "new styles below" comment should look like this:

/* add new styles below this line */

The other big error is to start out external stylesheets like this:

<STYLE type="text/css">

Don't do this! You need the STYLE tag when you're embedding a stylesheet in an HTML document, it's true, but this tag should not-- indeed, cannot-- appear in an external stylesheet. Neither can the close tag, </STYLE&gt. If it's an HTML element, it doesn't belong in a stylesheet!

External Problems

Another place you might run into problems is in trying to use external stylesheets. First, using @import is risky at best, because Netscape Navigator doesn't support the importing of stylesheets. Therefore, in order to make sure your styles are applied to your documents, use the LINK element.

In addition, make sure you use it correctly, and don't go overboard with the attributes. You should really have only one LINK element, which should look very much like this:

The actual order you write these attributes doesn't matter, of course, but some of the values are very important. The first two should usually be as written above, especially the type attribute. The value of href should obviously be the URI of your stylesheet, and the title should be whatever title you want to give to your styles.

The optional media attribute is used to identify the media for which the styles are intended. In theory, you could LINK in styles for display on a monitor, different styles for printing, and so forth. Sadly, only Internet Explorer supports such things. Furthermore, if you specify anything other than screen, then the entire LINK (and therefore the entire external stylesheet) will be ignored by Navigator.

You can actually turn this problem to your advantage, using it to hide styles from Navigator by declaring the media to be all. That's only recommended for experienced authors, though.

Correcting the Background

Another problem Navigator has is its mishandling of background colors. If you apply a color to the background of any element other than BODY, then you'll discover something unpleasant: the color is only visible behind the actual text in the element. It should, rather, be visible throughout the entire element box. The difference is shown in Figure 1.

Fortunately, it's easy to work around this. All you need to do is declare a zero-width border for the element, and magically, the background will be correctly filled with color.

P.side {background: aqua; border: 0px solid aqua;}

The actual color shouldn't matter in the slightest, but just to be safe, I recommend that you set it to be the same color as the background.

Where'd the Styles Go?

Finally, we address a rather obscure Navigator bug which is utterly baffling when encountered. If you have Navigator 4 available, load up a document with some CSS applied to it. Then resize the window. Presto! All the styles are gone.

Reloading the page will get them back, but that's hardly a satisfactory solution. Slightly better is the inclusion of a small bit of Javascript which will fix the problem for you. This widget should cause any Javascript-enabled version of Navigator to reapply the styles after the window in resized-- and if Javascript is turned off, then CSS won't work at all, which is another thing to remember when trying to figure out why styles don't work.

Whatever You Do, Don't Give Up

You may have noticed a preponderance of workarounds aimed at Netscape Navigator 4.x in this column. There's a good reason for that: Navigator's CSS implementation is pretty bad. I'm not making a terribly controversial stand there, since even programmers at Netscape have said as much, and you'd be hard-pressed to find a regular on ciwas who would disagree.

Although this all sounds bad, it's not so terrible. After all, just think of Java programmers, who have to cope with fundamental changes to their programming language every other month. By comparison, CSS is pretty stable, not to mention a lot easier to learn. Besides, with the recent emergence of almost fully standards-compliant browsers like Opera and Explorer 5, and the highly anticipated release of Netscape 5, CSS1 will become less of an obstacle course, and much more the powerful tool it was always meant to be.

In the meantime, between the free validators, the folks in ciwas, and future editions of "Sense of Style," you should be able to find the help you need-- so keep on stylin'!