CSS Best Practices

There are so many choices when coding a Web page. HTML or XHTML? TABLE tags for layout or not? Pixels, percentages, or EMs? Float or position? While many of these choices depend on the site’s goals, some also depend on personal decisions you’ll need to make. This article examines some of these choices.

DOCTYPE

Browsers can render your HTML code in many different ways. The DOCTYPE of an HTML document tells the browser how you want it to interpret and display your code. The most common DOCTYPES are HTML 4.01 Strict, HTML 4.01 Transitional, XHTML 1.0 Strict and XHTML 1.0 Transitional.

I mainly use an HTML 4.01 Transitional DOCTYPE, though it is often a partial DOCTYPE. The partial DOCTYPE technique allows me to throw IE into QUIRKS mode so I can more easily compensate for the IE family’s rendering issues as a group through the use of CSS filters. At the same time, I can still validate the code.

Is it the end of the world if you don’t use a DOCTYPE? Probably not. However, using a DOCTYPE is a necessity for validating one’s HTML, which is a great way to keep your code compliant, to quickly find any coding mistakes you may have made, and to perhaps help meet any standards requirements.

External Style Sheets

The STYLE tag should be avoided wherever possible for SEO considerations. Style sheets should be externally linked and only imported when a special requirement needs to be met, such as Mac/IE consideration.

For larger projects, it is usually easiest to break the style sheets up either by area or code group. In other words, create a style sheet with “global” commands: one for the “header” area, one for the “footer”, etc. Smaller or simpler sites may not benefit from this approach so it depends on the project and the preference of the coder.

For smaller projects, I generally use one style sheet. Larger projects are broken into global, home, basic pages, error and utility style sheets.

HTML or XHTML?

Although it’s not necessary to drop everything and code solely in XHTML, Web developers should be working toward coding the stricter XHTML. There are probably MANY years of HTML coding left for the industry, but there are two good reasons why we should be headed toward XHTML:

• HTML won’t be updated anymore. It has absorbed some XML features and turned into XHTML. HTML is dead. For that matter, XHTML will be dead when it moves totally to XML, so shouldn’t you get started learning now?
• XHTML gives your code the ability to be read on XML devices so you can, again, keep current with the trend of making Web pages available on more devices/arenas than just the local computer or Internet.

A list of additional XHTML benefits can be found at the New York Public Library Web site.

The decision to code in XHTML may come down to project budget or coder skill level. Many companies do not have coders who are familiar with the stricter XHTML and therefore could run into overages on projects. If a client doesn’t have the need for XHTML, there may not be a compelling reason for you to choose XHTML over HTML.

TABLE Tags for Layout?

This is a touchy subject. From a coder’s viewpoint, using TABLEs for layout can be a blessing or a curse. TABLEs are quirky in the various browsers. They are not “appropriate” to use for layout, they don’t seem to mix well with CSS, and they pose accessibility issues. From a business standpoint, however, they can speed up a site’s completion and may be the only way to achieve certain design goals.

Ultimately, whether to use TABLEs for layout or not is a decision made on an individual basis. Often it comes down to accessibility and/or budget. If a site has high accessibility goals, then leave the layout TABLEs out of the code. If the budget demands the fastest possible HTML output, then a hybrid approach including layout TABLEs may be the answer.

Even if CSS could mimic the TABLE tag in a well-supported manner, layout TABLEs would most likely continue to be used by the mainstream. Achieving advanced CSS layouts often requires too much effort or not enough return on investment (ROI) for a client so the arguments against using TABLEs for layout are not compelling to the average Web site owner.

Pixels, Percentages, or EMs for Font Sizes?

There are other choices for the font-size unit, but pixels (PX) seems to be the most used. They are the most reliable, simply because they cause the least grief during development. However, it is not the most accessible, since IE will not resize the PX unit. Not many project specifications require the need for relative font sizing, though.

If your project does require relative font-sizes, EM is the best choice. You can combat some of EM’s complexities by preparing the CSS a little. For example, I set the BODY font-size to 16px and then used EM as a measurement throughout to create a design where the majority of elements could be resized according to font size of the user.

Should You Float or Position Your Advanced CSS Layout?

CSS-based layouts usually require either FLOATing or POSITIONing techniques to create the illusion of columns. There are drawbacks to both approaches—floating requires “clearing” and positioning limits a layout’s flexibility.

Positioning was the early answer to CSS layouts. It remains a viable option and many examples of its use are widely published on the Internet as “the” answer.

My choice is to float, however, because of the flexibility it offers. Accessibility requirements may mean that text needs to be resized, which could cause broken layouts for positioned columns.

Applying Styles to HTML

For the most part, styles should always be applied with a CLASS attribute. Only use the ID attribute when absolutely necessary. Applying a style inline with the STYLE attribute should also only be used when necessary—hopefully that means never.

I only use inline style declarations when the site maintenance person will be making changes to background images or colors. Since they are often not as familiar with CSS, it is easier for them to find and change code that resides in the HTML instead of the style sheet.

CSS Shortcuts

Use of CSS shortcuts is a great way to slim down your code. You should use every opportunity to group styles and use shortcuts.

Example: .foo {margin-top: 11px; margin-right: 11px; margin-bottom: 11px; margin-left: 11px;}
              .foo2 {margin-top: 11px; margin-right: 11px; margin-bottom: 11px; margin-left: 11px;}

Could be: .foo, .foo2 {margin: 11px;}

CSS Rollovers

Stop with the javascript rollovers already! Use CSS—it requires less code. There are plenty of tutorials and articles on the topic. This is a good CSS rollover article from A List Apart, called “Sliding Doors.”

The problem with using CSS for rollovers is that, in IE, the :hover that is required will only work on ANCHOR elements. Mozilla-based browsers accept :hover over other elements but this is moot since it isn’t compatible with IE. There have been other solutions to this issue, such as using javascript or an .htaccess file to make IE hover on other elements. I often simply uses the :hover on ANCHOR tags only, though I am now experimenting with a .htaccess file that allows rollovers on other tags in IE. The script is proving helpful but its usefulness would depend on the goals and specifications of a given project.

Good Code

Many techniques exist for achieving good code. Many will argue about the most practical approach. Basically, though, it comes down to a personal decision based on what is most important to you and to the client.

My standard is to code my HTML/CSS while reviewing it in either FireFox or Mozilla. Then, I adjust the CSS for IE as needed through CSS filters, unless the client has specifically requested I not cater to Mozilla browsers. Even then, I suggest the client rethink any decision to forego my technique since it yields what I believe is the most cross-browser, cross-platform experience with the least code.