 | ||
|
| ||
| ||
|
| ||
October 21, 1997
Planning to sail into the magic land of Cascading Style Sheets? Here's a chronicle of one of MSDN Online Web Workshop's recent voyages. You May find it helpful on your own travels.
If you haven't visited the MSDN Online Web Workshop Design area in a while, you'll notice some big changes. Gone are the framesets, and the whole area now uses Active Server Pages (ASP) technology -- which enables the handy site-wide menu. We've added new graphics to each section and article, providing them with distinct identities. And we've formatted each page using Cascading Style Sheets (CSS).
Several weeks into the project, I knocked on our designer's door and asked her to remind me why we were rebuilding the entire Workshop Design section with CSS. She calmly replied that it would give us greater control over such variables as font-size and leading, or the vertical space between lines and different HTML elements. She was right. It does. However, we learned a lot along the way, and ventured far from our original plan.
We began our redesign by building HTML templates for each of the three levels of pages: top-level, contents-level, and individual articles. Each template included a style sheet, with styles for various heading levels and paragraphs with different amounts of white space around them. Because a margin-bottom property is supported evenly, we manipulated that white space by using the margin-top property. For example, we wanted paragraphs immediately following a headline to hang with that headline, so we created a paragraph class with a smaller top margin.
In reviewing the code, we found that several of our original styles were no longer necessary. We threw them out. We checked that the remaining class names were intuitive enough to be easily remembered and applied. We also used inheritance -- the idea that properties already listed for a style do not need to be repeated for classes of that style, as long as the property values remain the same, as in the following code:
BODY { font-family: "Verdana, Arial, Helvetica"; font-size:10pt; }
P { line-height:13pt; margin-top: -5px; }
P.graph1 { margin-top: -10px; }
We added only what changed, which allowed us to create much leaner style sheets.
Our style sheet was sleek, and our template looked great. We asked our tester to put it through its paces.
What looked so elegant in Internet Explorer 3.0 on Windows 95 blew up in Internet Explorer 4.0 and any Netscape browser we tried. In specific instances, text appeared badly mangled when viewed on a Macintosh. I had naïvely thought that a pixel was a pixel, and a point was a point. I was mistaken. The CSS implementations on different browsers can result in vastly different sizes and margins. It was immediately apparent that one style sheet was not going to cut it. By using linked style sheets, we could set up separate style sheets for the different browsers, which meant we would need to sniff for those browsers, and point them to discrete style sheets.
To do this, we stripped the style sheet from our templates, and pasted it into three .css files: one for Internet Explorer 4.0, one for Internet Explorer 3.x, and one for all other browsers (which we would optimize for our users viewing in Navigator 4.0). Then we had to put a big chunk of browser-sniffing code into each file. If we needed to make any changes, modifying that code in each file could be just as tedious as making changes to a style sheet in each file. Because we were using ASP technology, we opted to put the browser-sniffing code in a separate .htm file, and access it, using an include statement in each .asp file, as in the following:
<!-- #include virtual="/workshop/design/browser.htm" -->
By putting all our style sheets and our sniff code in separate files, we could make adjustments without going into each .asp file.
We added a few new styles into the files -- and, in one case, had to add a special style for Navigator 4.0. (Notice the line height for the feedback message at the bottom of each Web page. It kept scrunching up in Navigator 4.0, so we created a special style, raised the line-height value, and added it to our "other" style sheet.) Then it was my turn to play with the margin values for each of the three style sheets, and to fine-tune them until the pages pointing to them appeared basically the same in each browser -- and basically the way we wanted them to look!
It sounds like fun, and mostly it was. If our designer wanted to shave a few points off every Level 3 heading, I could make the change globally by opening three small files. But certain code circumstances didn't work, and I learned an important lesson: Use the right tool for the right job.
Contents pages in the Design area include article summaries, with icons next to each. These were set up in a table, and we applied a special style to the summaries to achieve the desired margins between them. Those summaries and icons should align properly, but the elements ended up in different places in each browser version. We could change the margins all we wanted, but the icons and paragraphs didn't align.
We didn't want to alter the actual files for the contents pages, since that would create new spacing and alignment discrepancies. Even a <BR> tag will be interpreted differently by the various browsers on different platforms. Once I reached the end of my rope, I decided to try an old and hardly technical trick. I deleted the margin-top property from the style, and added a table row of white space--just a WIDTH value and a . It worked, and that's what I learned about using the proper tools. You can use CSS to do some wildly wonderful things, but not everything.
In the end, we still had the spacing problems in browsers running on a Macintosh. Paragraphs following </BLOCKQUOTE> and </UL> tags rammed up against, and even over, the preceding text. Those paragraphs needed a higher margin-top value. That meant we needed to sniff not only for browser, but also for platform -- and we had a deadline to make. Readability became critical, inline styles would break the style sheets that were working, and our scripting guru was beyond the reach of e-mail. We manually put in extra space following the </BLOCKQUOTE> and </UL> tags. It was a compromise, one we view as temporary.
Once we work the kinks out of our platform-sniffing code, we will be able to resolve those spacing problems by adding a separate style (we'll have six style sheets by then) for paragraphs following a BLOCKQUOTE or a list.
We've torn a fair amount of hair out and have gained a lot by using CSS. Because we've set our site up with linked style sheets, we will easily be able to expand our content while maintaining a high level of consistency. Would we use CSS again? You bet. Would we add a lot more time into the design process? You can bet on that, too. It will be time -- and hair -- saved later.
For more information on Cascading Style Sheets, please see George Young's article Cascading Style Sheets in Internet Explorer 4.0 in the MSDN Online Web Workshop Authoring area.
For a quick overview of CSS, read Nadja Vol Ochs's overview for designers.
To see some of the effects CSS can provide, take a look at Nadja's Site Lights column (Now MSDN Online Voices Design Discussion column A Coast-to-Coast Cascade of Style Sheets, which offers many samples, and discusses how to combine CSS with Dynamic HTML.
Photo Credit: Hans Wiesenhofer/PhotoDisc; Neil Beer/PhotoDisc
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top