Fear of Style Sheets

If you don’t know what style sheets will do for you and your audience, you can review the spec online; or see Dr Web {Dr Web is now off-line — Ed.} for a quick tutorial. We’ll be here when you return.

Cascading Style Sheets (CSS) save bandwidth, vastly reducing the size of your files when compared to old-style <FONT FACE> markup. With styles, your sites load faster. You work faster, too. Styles shave grueling hours of grunt-work off your design workload: one brief CSS document can style an entire domain; and when it’s time to redesign, you can execute site-wide changes in minutes instead of days.

Style sheets bring genuine leading and sophisticated margination to the web, easing our readers’ eyestrain while bringing us the control of negative space we take for granted in other media. They offer exciting new possibilities, from absolute positioning, to interactive manipulation of text and images. And they allow us to create sophisticated layouts while doing no harm to the underlying structure of our documents — ensuring that search engines (as well as hand-held devices, web phones, and other futuristic browser morphs) can “understand” our pages as easily as readers do.

Plus, unlike cross-browser DHTML, JavaScript, and other advanced technologies, CSS is bone-simple to learn and use.

So, with all these incredible advantages at our disposal, why have so many web designers and developers held back from harnessing the power? The answer is Fear of Style sheets. The solution, at least for now: No-Fault CSS.

Where the fear comes from.#section2

There are two levels to this fear of styles. The first comes from clients, while the second has to do with the technology itself. We’ll consider each in turn.

Part One: Coping With Clients#section3

Many times, when we wish to incorporate new technology into a site, our clients will hold us back. Their concerns are often reasonable. A good client may say, “our baseline for this project is Netscape 3. A lot of our users surf with that browser, and we can’t afford to ignore their needs.”

Good clients know their market, and we would be wrong as well as foolish to ignore what they are telling us. Fortunately, there is a way to bring styles into the design of a site without alienating users of non-CSS browsers.

Introducing “No-Fault” CSS#section4

If you’re viewing this site with Netscape Navigator 3.x, the proof is before you. This site is built with cascading style sheets in combination with older HTML techniques. It works in Navigator 3 — margins hold, colors load, text is readable, links and scripts work as expected — but when you upgrade to a 4.0 browser, additional design elements come into play, hopefully making the site look and work that much better.

The trick is to follow the principle that has always guided good web designers:

First Include; Then Enhance#section5

In practice, what this means is using styles to do what only styles can do, while using more universally accessible techniques for the basics. For instance, we use styles to establish fonts and leading on this site, but we still rely on TABLES to create our margins and other divisions. Think of it as No-Fault CSS.

Our Netscape Navigator 3.x users will not see the fonts we have chosen; instead, they will see their browser’s default font. And that’s okay. Presumably they chose that font for its readability (or the browser company chose the font for that reason, in the case of inexperienced users who never alter their preferences).

Why inflict a small sans-serif font on these users, when we cannot complement that font with the generous leading that makes it a pleasure to read? Why clutter our document with non-standard <FONT FACE> tags, when the page will look good enough — and may indeed look better — with the user’s default font? No reason that we can see.

The issue of tables is trickier. Style sheets were created, in large part, to separate content from style — our words from our tags. Using tables for layout defeats this purpose. Yet we find it a necessary compromise.

Table that motion.#section6

The framers of the web developed tables to present tabular data such as spreadsheets, not to serve as a tool of design, and their use as design tools has always disturbed the HTML purists. (There are practical problems as well: for one thing, tables slow down the appearance of the page.)

Unfortunately, while we’d love to please the framers of the web by laying out our pages with styles instead of tables, doing so would render our pages illegible for people with older, non-CSS browsers — bringing sorrow to our readers, anger to our clients, and emptiness to our bank accounts. So we compromise, as we always do on the web, using the degradable (if impure) “No-Fault CSS” approach to satisfy our clients, our design egos, and above all, the users of our sites.

Getting to “yes.”#section7

Your client who told you “No Style sheets” may we be reacting to early CSS demos that only worked in one browser. In early 1997, Microsoft built a gallery of such pages to show off the benefits of Internet Explorer 3.0, the only (semi-) CSS-capable browser at the time.

It made sense for Microsoft to do this; they had a genuine benefit, and a legitimate reason to market the heck out of it. But it makes no sense to build sites this way today (unless they are intranet sites); and it makes no sense to let a client’s painful viewing experience of the past dictate rules about the site you build for them today.

…Especially when, by following the No-Fault CSS Plan, you can show them a site that works well and looks great regardless of their customers’ browser choice.

Are we short-changing style sheets?#section8

Is the plan outlined so far in this article a compromise? Undoubtedly. Consider it a working model for a time of technological transition.

We will build the web as its framers intended when everyone uses CSS-capable browsers, and when the browsers actually deliver 100% of the promised capabilities of style sheets.

…Which brings us to the second, and much trickier, underlying cause of FEAR OF STYLE SHEETS: the current inadequacy of the browsers themselves.

Part Two: The Roots of Fear#section9

Let’s say a mad club kid dumps Ecstasy into your city’s water supply, and your clients go insane. Imagine that your largest client, the De-pend-o Truss Company, phones you up in a hallucinogenic frenzy. “The hell with our users!” the client bellows. “Give us DHTML and Flash and bubble viewer plug-ins! Give us sites that only work in the Unix Version of the new Mozilla beta! We don’t care!”

Wanna bet that, in all that drug-addled raving, they would not ask for style sheets?

Neither do many web designers — not even those on the bleeding edge. Why is this?

Outrageous behaviors.#section10

For one thing, many hard-core web geeks are more concerned with behavior than with style.  To these folks, interactivity is sexier than readability.
Wildly spinning logos that move from one pop-up window to the next at the slightest touch of the mouse may be Hell for the average user, but to bleeding-edge geeks, such scenarios are just south of Heaven.

Meanwhile, overworked commercial developers cry out for better e-commerce and improved user tracking. Sure, they’d like the site to look nice, but hey, the client wants to start selling framistats tomorrow, and the shopping basket isn’t working yet!

With high-profile award-winners pushing for improved image swapping, and the bulk of developers demanding secure commercial interactivity, is it any wonder the browser companies have failed to deliver on the nuances of page layout and design?

And the browser companies have failed, although they are getting better, and their hearts are often in the right place.

More promise than performance.#section11

With developers’ disinterest fueling brower companies’ complacency until very recently, style sheets and other standards have taken a back seat to proprietary browser features. The result: incomplete support for CSS, and nasty bugs in many of the parts that are “supported.” Together, these long-standing problems have convinced many developers that style sheets aren’t worth the virtual paper they’re printed on.

From images that overlap text, to wildly inconsistent margins, the mess has been well documented in Apartnik Matt Haughey’s Little Shop of CSS Horrors, the CSS Pointers Group’s Bugs and Workarounds and our own Dr Web {both now offline –Ed.}.

By far the most complete and scientific approach is that of the Web Standards Project’s CSS Samurai, whose standards-compliance reviews of Opera and Explorer set out the problems in detail, and challenge these browser makers to improve their products’ performance.

Why is there no review of Netscape Communicator? According to the Samurai:

Duct tape and chickenwire#section12

While the goal of all these formal (and informal) studies is to bring style sheets up to the mark, we can also use them as guidelines in determining what works and what doesn’t if we wish to use styles today. And until we are willing to do that, we will be denying the browser companies the feedback they need to (a.) become motivated enough to fix the problems; and (b.) get the real-world help they need in determining what the problems actually are. For it’s a funny thing with style sheets. Two parts of the Standard may work in a given browser until they are combined, when they suddenly stop working, often with wildly unpredictable results. But we’ll get to that soon enough.

More to come.#section13

In the next installment of Fear of Style Sheets, we will talk about specific bugs we’ve encountered, share our workarounds, and explain why we have high hopes for the very near future. Meanwhile, if you haven’t tried working with CSS, why not start now? With careful use, you can enhance the readability and usability of any site. And with a little moxie, you can participate in the solution, by helping the browser companies get up to spec sooner than later.

To report CSS- or other Standards-related bugs in pages you’ve created, visit the Web Standards Project’s War Stories form. Remember that these resources are designed so you can provide professional feedback to engineers at the browser companies; they’re not there as a dumping ground for emotional grievances, or to provide answers to questions about how CSS works. (Hopefully this series, and the resources it points to, will answer most of your questions.)

’Til next time, hang in there, and don’t be afraid of style sheets. But be afraid — be very afraid — of what the web will become if we don’t get working style sheets soon.