Page 2 of 2 In general, browsers are supposed to ignore any "white space" that falls between elements, but occasionally such normally harmless spaces produce bugs. If mysterious gaps or openings show up in your page and there seems to be no apparent cause, try eliminating the inter-element spaces. These types of bugs are found mostly in Internet Explorer, but not always.
If eliminating white space fixes the problem but you want to keep the code lines short so they are easier to read, it is possible to break long code lines within tags, usually between element attributes.
Also, the bug may not always appear as a gap, but may instead assume some other weird form, such as an element that is too tall. Some frequent places these display problems can be found include lists, and above or below images. For more on eliminating white space, see the article Writing Efficient CSS (http://www.communitymx.com/abstract.cfm?cid=A43B828960590F55) here at CMX.
Many people will use an XML prolog on the first line of their xhtml page in the mistaken belief that the prolog is required. In fact, it is only required for XML pages and not xhtml pages. IE6 is somehow thrown into "quirks" rendering mode by the XML prolog and this causes considerable head-pounding in those unfamiliar with this behavior. Other modern browsers have no difficulty with the prolog, but IE6 simply cannot handle its presence. So, omit that XML prolog unless you are actually writing an XML page. More information on rendering modes and the XML prolog can be found in the article Rendering Mode and Doctype Switching (http://www.communitymx.com/abstract.cfm?cid=E2F258C46D285FEE).
A large percentage of page problems are due to improperly written code. The W3C HTML and CSS validators can catch just about every syntax error quickly, although there are a few bugs in the validators themselves. So, don't panic if they throw an error and you can't see one in your code.
In addition, the CSS validator often gives "warnings" when certain styles (or lack of them) could lead to problems viewing the page. This might happen, for example, when an author does not supply a text color value for an element that has a background-color specified. If the user has their browser set to display white text on a black background, and the author declares a black text color but not a specific background-color, then the page could end up solid black! Another warning can be encountered when a generic font-family has not been specified.
The point is that these warnings are just that, warnings, and not errors. It is up to you to decide how relevant a given warning is to your situation.
HTML validation: W3C
Markup Validation Service (http://validator.w3.org/ )
CSS validation: W3C
CSS Validation Service (http://jigsaw.w3.org/css-validator/ )
A very common cause of difficulties is failure to fully grasp the nuances of "The Cascade." This leads to the belief that a certain style rule should be operative when in fact the cascade rules make another style rule dominant. The only "fix" for this is to buckle down and study the cascade rules. See Understanding the Cascade: Part one (http://www.communitymx.com/abstract.cfm?cid=A5A3E5C65CA5584B) and Understanding the Cascade: Part two - Specificity (http://www.communitymx.com/abstract.cfm?cid=AE76913AF0D2E5D2) for more on this subject.
When writing "relative" paths to files from within style sheets, there are two important points to be aware of. One is that the indicated files (background image files, for example) are relative to the CSS file itself, and not the HTML file, unless the CSS is embedded in the HTML. Netscape 4 gets this backwards, but it is the only CSS-capable browser to do so.
The second point goes for both relative and absolute paths written with the url ( ) syntax. Using any syntax other than the examples shown below might cause certain browsers (mostly older ones) to ignore the target file.
<style type="text/css">
@import url(../stylesfolder/mainstyles.css);
background-image: url(../images/bg-image.jpg);
</style>
Using single quotes to surround the path within the url( ) syntax causes IE5/mac not to apply the styles. This problem also occurs with background-image calls and any CSS that uses the url( ) syntax.
Unless you are trying to "hide" CSS styles from older browsers, or IE5/Mac, we recommend using the no quotes version to avoid unnecessary problems. See the following pages information on hiding with quotes.
Internet Explorer for Windows has a text sizing problem that occurs when a user alters the "text size" from their browser View menu. If font-sizes are designated in em units, then the text size "steps" applied by IE are too large or too small, causing a setting of "larger" to be huge, and "smaller" to be almost microscopic.
The best way to avoid this fate and retain resizable text in IE is to define an overall percentage font-size for the <body> element, and then use em units to control font-size in the rest of the page. This will correct IE without harming other browsers.
In a side issue, the use of "keywords" such as "large" and "smaller" for font-size are theoretically fine, but in practice can be less than identical across the different browsers. Be prepared for a potential hassle if you are forced to, or insist on, using such keywords.
When using the different link pseudo-classes, a:link , a:visited , a:hover , and a:active , to style links in your documents, the pseudo-classes must appear in this exact order, or problems will result. This is because the last operative pseudo-class gets applied to the link (if the specificity is the same between them). Typically, a:link refers to an unvisited link, however, all link states could be styled by that pseudo-class alone. By ordering the pseudo-classes as indicated, each will have the opportunity to affect the correct link state.
a:link {color: purple;}
a:visited {color: blue;}
a:hover {color: lime;}
a:active {color: red;}
For example, if, as shown, a:link precedes a:visited , a visited link gets that second style rule. But suppose the order of those two is reversed, then the a:link styles get applied regardless of any visits, because a:link is always operative, and it came last in the style rules.
If the a:hover and a:active pseudo-classes do not follow in the order given, those pseudo-classes are likely not to be displayed as the author hopes in all browsers, and indeed, the W3C specifications state that the order shown above is what will allow the various link states to display correctly. There are variations, notably IE/Win browsers that may apply out-of-order pseudo-classes. Read more about link pseudo-classes (http://www.w3.org/TR/CSS2/selector.html#link-pseudo-classes) in the W3C CSS 2 specifications.
If you happen to have anchors with names or IDs to serve as targets for linking within a page, for example <a name="top"> , and use a {property: value} in your style sheet for your link styles, then these normally invisible anchors will actually appear on the page if borders or backgrounds are being used for the link styling. The way to avoid this is to use a:link which does not get applied to the anchors, but only actual links with an href=" " attribute.
Note: Some coders use href="#" when testing links on a page in development. Be aware that IE/Win fails to obey a:link styles under these conditions. However, if an actual path is used for the href attribute, the browser will obey the styles. IE harbors lots of nasty surprises like this!
While the HTML and xhtml specifications allow pixel values in attributes to be assigned without specifying the unit being referenced, CSS specifications require some unit to be used with any non-zero numerical value that designates a width or other dimensional length. Such units include: px, pt, em, ex, and % .
Now you're armed with "answers" to some of the vexing problems that you may encounter when you use CSS. We're not done, however. The second part of this series will begin covering various problems associated with page display, positioning, and the ever popular float property mess. Yes, the really fun stuff!
Keywords
CSS, FOUC, media types, MIME types, white space, XML prolog, html validation, CSS validation, the cascade, @import, text size bug, pseudo-class, pseudo-classes, styling links, anchors, browser bugs, CSS bugs
