Visual Formatting | SYS-CON AUSTRALIA

Visual Formatting

May. 19, 2004 12:00 AM

Support for cascading style sheets, or CSS, has been present in Dreamweaver for many years; you may have taken advantage of it as just another software feature without really knowing how to utilize it fully, efficiently, and correctly. This article will introduce you to some general guidelines to follow while setting up and working with CSS-based Web pages so you can achieve more consistent rendering cross-browser. It assumes you know what CSS is, have some idea of its syntax and rules, and are eager to take advantage of its benefits, but is aimed at the Web designer who has not yet taken the leap to using it as their primary layout and visual formatting method.

Choosing a Doctype and Rendering Mode
To assure that your CSS is rendered in a reliable way, you'll need to include a document type declaration, or doctype, on your pages. A doctype tells the browser which version of (X)HTML you are using and usually appears on the first line of your document. Here's an example of the default doctype Dreamweaver MX 2004 uses when you create a new blank HTML page:

<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

This doctype is complete because it contains both the public identifier (the part that states it is HTML 4.01 Transitional) and the system identifier (the URL to the document type definition, or DTD). Doctypes can also be written without the system identifier and still be valid, but you'll usually want to work with complete doctypes because of the impact this has on the way your page appears in browsers.

Your doctype determines whether your page displays in a browser's "quirks rendering mode" or in its "standards rendering mode." In quirks, a browser will try to handle sloppy authoring and will emulate the quirks and bugs of browsers of the mid- to late '90s. In standards, the browser will try to follow the World Wide Web Consortium's (W3C) current recommendations, even if the results are unexpected.

In general, the following doctypes will cause your page to be rendered in quirks mode:

No doctype
HTML 3.2 or earlier
HTML 4.0 Transitional or Frameset
HTML 4.01 Transitional or Frameset without URL

The following doctypes will cause your page to be rendered in standards mode:

All strict doctypes
All XHTML doctypes
HTML 4.01 Transitional and Frameset with URL

There are a couple of exceptions, so you may want to check the major browsers' sites to verify the rendering mode for your chosen doctype.

One caveat: complete HTML 4.01 Transitional and Frameset doctypes, as well as any XHTML Transitional and Frameset doctypes, actually put Mozilla into its proprietary "almost standards mode." Almost standards is the same as standards except in the way that images in table cells and divs are rendered - in standards, images sit on the baseline of a box (where text would sit), while in almost standards they fill the entire table cell or div. Almost standards is a good choice for old-fashioned table layouts of sliced images.

Also note that an XML prologue (or anything, for that matter, even an empty comment) preceding an XHTML doctype will throw IE6 and Opera 7.0x into quirks mode. Dreamweaver MX inserted this prologue in XHTML files, but MX 2004 does not. Since it can be omitted without harm, it's recommended you just remove it if you want to stay in standards.

How do you know which doctype to choose? XHTML is not a new standard intended to replace HTML; basically it is a more precise version of HTML that is intended to make it easier to bridge over to XML in the future. If you are creating a static site, you probably don't need to worry about XHTML and can use HTML 4.01 without feeling a tad bit guilty.

What about the difference between Strict and Transitional? Strict gives you the cleanest code, the most forward compatibility, and the best separation between content and presentation because it does not allow many of the presentational tags and attributes that Transitional does. You don't need these deprecated tags any more - you can use CSS to accomplish most of the things they were used for - but if you're working with a client who insists you use some of the old tricks for the old browsers, or if you're just revising existing pages, it may be better to stick with Transitional for now. Here are a few of the elements and attributes you can't use in Strict:

Center tag (use CSS instead)
Font tag (use CSS instead)
Target attribute on links (opening new windows is considered a usability no-no)
bgcolor attribute (use CSS instead)
Link, alink, and vlink attributes (use CSS instead)

No matter which version of (X)HTML you choose, I recommend picking a doctype that keeps you in standards mode. Standards mode usually results in a higher degree of cross-browser consistency and gets you accustomed to current rendering models so you can get in the habit of coding to the standards instead of old browser quirks. In addition, many CSS hacks depend on you using standards mode. For instance, many of the hacks designed to work around the incorrect box model in Windows Internet Explorer (IE) 5.x do not target IE6, because IE6 gets the box model right when it is in standards. However, if your page was in quirks, IE6 would have a box model problem, and since the hacks do not target IE6, it would not be fixed.

Dreamweaver automatically inserts a complete HTML 4.01 Transitional doctype on each new page, so you don't have to worry about rendering in standards. But what if you want to use HTML Strict, not Transitional, by default? Luckily, you can easily edit the default Dreamweaver HTML template. Locate the default template in the Dreamweaver Configuration folder: Configuration\DocumentTypes\NewDocuments\Default.html. The configuration folder is located in C:\Program\Files\Macromedia\Dreamweaver MX 2004\ (Win) or Library/Application Support/Macromedia/Dreamweaver MX 2004/ (Mac). Be sure to make a backup of the file (just in case). Open it in Dreamweaver and view the code (see Image I). Change the doctype to:

<!DOCTYPE HTML PUBLIC
"-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

Once you save the page, all new pages will include the doctype you entered. You may want to edit some of the other default pages as well, such as the Dreamweaver Template document (Default.dwt), to include the doctype that you want.

If you choose to use XHTML to build your pages, it's easy: from the New Document dialog box, select HTML and check the "Make document XHTML compliant" box at the lower right before clicking Create (see Image II). This will create a page with a complete XHTML Transitional doctype already inserted (see Image III). MX 2004 leaves out the XML prologue by default, so your pages should render in standards mode cross-browser. Unfortunately, there is no XHTML template for you to edit like there is for HTML, so if you would rather use XHTML Strict instead of Transitional, you're going to have to make that change by hand on each page (or use Find and Replace).

Setting Standard Rules
There are some rules that you will use over and over again in your CSS files for every site you work on. Just as you can modify the HTML template Dreamweaver uses, you can also modify its CSS template to include your standard rules. Open Default.css from the New-Documents folder (full path above) and edit away! Any changes you make and save will show up every time you create a blank CSS document from within Dreamweaver.

Here are some suggestions for rules you may want to add to your default style sheet:


body {
	margin: 0;
	padding: 0;
}

If you want to get rid of the default page margin on your page, remember that you need to zero out both margin and padding, since Opera uses padding rather than margin to add the extra space.


body {
	font-face: Arial, Helvetica, sans-serif;
}

The specific fonts listed above are just examples, but the idea is to include your font declaration on the body. This way you can define a default font for text so you don't needlessly repeat it across several tags such as div, p, and other text-related tags that can simply inherit font properties from the body.


body {
	font-size: 100.01%;
}

If you plan on using a relative measurement for text - such as ems or percentages - you'll need to use this little trick to avoid bugs in IE and Opera. IE has a bug that displays em measurements smaller than 1.0 as microscopic if the user has his or her text size set to "Smaller" or "Smallest." Setting a percentage font size on the body fixes this bug as long as you're in standard mode.

If you want to set the base size to 100% to match users' default settings (an accessibility plus), keep in mind that Opera has its own bug that computes 100% to be one pixel smaller than it should be. This means that text can become microscopic in Opera as well, since all subsequent font sizes are based off a base font that is too small. Using a value other than 100%, even 100.01%, fixes this bug in Opera.


table {
	font-size: 1.0em;
}

This rule fixes a bug in Windows IE5.x that prevents the font size from inheriting into tables as it should. The value of 1.0 em tells the table to take its font size from the surrounding content, which is exactly what it's supposed to do anyway, so the rule doesn't cause any damage in standards-compliant browsers either.


div.clear {
	clear: both;
	height: 0;
	margin: 0;
	line-height: 0;
	font-size: 1px;
	}

If you use floats to lay out divs, you are going to need a clearing element at some point to hold things together. When you float an object, you remove it from the flow of the document, so it does not affect other block elements, only inline content. This means that the float's parent element will not expand to contain the float, as you might expect. To force the parent to contain the float, insert a clearing element within the parent but after the float. The parent will have to expand down to hold the cleared element, containing the float in the process.

Although a simple <br style="clear: both"> will do the trick, you often want your clearing element to take up no space on screen, as if it wasn't even there. The rules for div.clear above do a good job of eliminating the space that the div would normally take up, providing an easy way to contain your floats seamlessly. In your HTML, just write <div class="clear"> </div>.

Hiding CSS from Old Browsers
To save your sanity - and your client's cash - it's best to focus on usability for all browsers, rather than pixel-perfect cross-browser visual consistency. At some point, Ford decided to stop providing support for its Model Ts, and at some point it no longer makes sense for us to spend exorbitant amounts of time optimizing visual appearance in an outdated browser with 1% market share. For most sites, trying to make things look perfect in version 4 browsers simply doesn't provide good ROI.

Notice that I said "visual appearance" - you of course want to make sure your site is still useable regardless of the user's browser. However, complicated CSS can actually hamper your site's usability in older browsers that can't handle it. Fortunately, you can hide CSS from these browsers to assure that their users will be able to access your site content without complicated CSS markup, turning things into a mess.

The most common and simplest way to do this is by including your external style sheet using @import instead of the link tag. From the Link External Style Sheet dialog box, browse to your CSS file, and select Add As Import (see Image IV). Dreamweaver will insert the following code into the head of your document:


<style type="text/css">
<!--
@import url("styles.css");
-->
</style>

Netscape Navigator (NN) 4.x will not be able to see style sheets called this way and will be presented with plain text pages. However, IE4, another old browser with poor CSS support, will see these styles. Get rid of the "url" part if you want to hide it from IE4 as well as NN4.x:


<style type="text/css">
<!--
@import "styles.css";
-->
</style>

If you want to give these old browsers at least limited styling that they can handle, use the link tag to include a basic style sheet and @import to include a more advanced style sheet for modern browsers:


<link href="styles-basic.css" rel="stylesheet" type="text/css">
<style type="text/css">
<!--
@import "styles-advanced.css";
-->
</style>

The version 4 browsers will ignore the imported style sheet and render the page using the values in the linked one, allowing you to more fully utilize the capabilities of CSS for those browsers that can handle it. If you do use this method, though, remember that modern browsers will read both style sheets, so if you create specific rules in the basic style sheet that you don't want applied in the advanced one, make sure you specifically set them back to the correct values in the imported sheet.

Using Print Style Sheets
In addition to separate style sheets for older and newer browsers, CSS allows you to set up a style sheet to format the printed version of your Web page. Before CSS, providing a text-only or printer-friendly version of your page often meant creating a separate copy of the content designed for a printer, meaning more work for you and your server. With CSS, you can use a single HTML file and specify how the printed page should appear, including which items on your page should or should not be printed, simply by linking to another style sheet with a media type of "print":

Keep in mind that if you have not specified a media type for your other style sheets, they will default to media="all" and apply to both screen and print. This means that you will need to place your print style sheet after the other style sheets in the head of your document to make sure its rules take precedence in the cascade on the printed page. To avoid this issue, you can set your other style sheets to media="screen", but having the overlap is actually often desirable - it keeps you from having to include rules you want both on screen and in print in two separate places, so that all your print style sheet has to contain is rules that are specifically changed for print.

Note that NN4.x only recognizes style sheets with a media value of "screen," or no media value at all, so your print style sheet is not going to work in that browser.

Also note that there was a bug in the original release of Dreamweaver MX 2004 that would render the print styles in the design view if you used @import with the media specification in the style tag, rather than in the @import line, to include the print style sheet. This bug was fixed in the 7.0.1 patch released on March 11, 2004, so be sure to download it from Macromedia's site.

Some things to include in your print style sheet:

Suppress printing of elements that are only needed on screen, such as navigational elements, by using "display: none".

Set colors to black and white or other colors that are easier to read on the printed page. Keep in mind that most browsers do not print background colors by default, so if you have white text on a dark background, you may want to change the color of your text to black in your print style sheet.

You can further improve readability on the printed page by changing to a serif font and increasing line-height.

Remember that not everyone will be printing to a color printer, so make sure any information you conveyed in color (e.g., "completed items are marked in red") is conveyed in an additional manner, such as a font style change or with the addition of a border.

Remove fixed widths so that text can flow to accommodate whatever size paper the user is printing to. Convert other units to measurements that make more sense for print (such as changing pixels to ems or inches).

Although you may be tempted to change your font sizes to points, leaving them as ems improves your page's accessibility and works just as well in print.

You may want to remove floats from items and let them flow normally down the page for more reliable printing cross-browser. Older Gecko-based browsers had a bug that cut off floats if they could not fit on the current page, instead of letting them flow to subsequent pages. Although this bug has been fixed, visitors using NN6.x, for example, will still have a problem.

When redefining rules in your print style sheet, make sure you use the exact same name that was used in your general style sheet. If you refer to "div#navbar" in your general style sheet, don't refer to it as just "#navbar" in the print style sheet, even if those selectors mean the same thing. Sometimes things will fail to be successfully overridden without this naming consistency.

Validating Your Documents
As you build your pages, remember to validate both the (X)HTML and CSS to make sure you are writing things correctly. A validator is a utility that checks whether a document's syntax conforms to the official definition of its doctype. Although validation is not an end to itself, it is a useful means of ensuring your pages are free from simple errors such as typos or disallowed values, making it a valuable first step in figuring out why things aren't working as you intended. Valid code is more likely to render properly cross-browser and is more forward compatible.

The W3C, which created the (X)HTML and CSS specifications, offers online validators at http://validator.w3.org/ for (X)HTML (see Image V) and http://jigsaw.w3.org/css-validator/ for CSS (see Image VI).

You can also validate your page within Dreamweaver by going to File > Check Page > Validate Markup (or Validate as XML if it's an XHTML page). The Validation tab of the Results panel either displays a "No errors or warnings" message or lists the syntax errors it found (see Image VII). Double click on any of these errors to highlight it in the code.

Moving Forward
Even with valid code, you'll still run into inconsistencies in various browsers due to the host of bugs that still exist in their rendering engines. However, following the guidelines above will help you avoid many of the cross-browser headaches Web development inevitably brings up, letting you more easily transition to using CSS throughout your sites as the visual formatting method.

Related Links

About Zoe Gillenwater
Zoe Gillenwater is a Web designer at the University of North Carolina at Chapel Hill with a passion for standards-based development. She also keeps busy with graphic design and multimedia projects. Zoe is an active participant in the css-discuss community and is one of those who believes CSS-based layout is ready for primetime.