A Layered Approach to coping with CSS bugs

Originally posted at: http://homepage.mac.com/faucon/Design/layered_CSS.html

2004-08-13 (Friday, August 13, 2004)

Update

If I stick with this approach, someday it would be nice to have a list of safe CSS statements & declarations for each layer. For now, quirksmode.org has a general compatibility table. Thanks, mr. Koch!

2004-08-12 (Thursday, August 12, 2004)

In the beginning

In a previous article, I described a few strategies for coping with all the CSS bugs in browsers to minimize the headaches associated with creating CSS for real browsers, as opposed to the "ideal" standards-compiant ones we're all secretly pining for. That was then. I've since had time to learn a bit more about my methods and reflect on them a bit. As of this writing, I have not yet actually deployed this strategy anywhere, so if you do, please let me know how it works for you, or what you think.

The basic strategy hasn't changed much, only the methods. I'm working on a layered approach that effectively hides the "fancy" CSS from older, buggy browsers that are prone to crashing, or rendering a messy or, worse, unreadable page. My methods, however, have changed. I'm trying to Keep things simple (Hat tip to Peter-Paul Koch), and at the same time keep the content of the pages accessible, while simultaneously taking advantage of recent standards available in the newer browsers. The goal is to have pages that can be read in any browser, but look better in the most common, standards-compliant ones.

The Levels

Basically, there are 3 levels of "style":

Level 0: Unformatted HTML (or XHTML)

Unstyled, boring - but still readable. This is the foundation of your document. Some users can disable style sheets, impose their own, just don't support them, or don't use them (screen readers, etc.). So, even without your style sheets, the basic document should follow in a logical order, and be readable.

For this level, I generally test in Netscape 4 (why? it will make sense later).

Level 1: Typography (basic styling)

No layout, but the text might be easier to read. Mostly font face, size, spacing, etc. This will be incoporated into the next layer, but you can still make it visible to some "intermediate" browsers - the ones that might not be able to handle the layout, but can do text without crashing, or wrecking the page. Not that this has it's own challenges, particularly if you're trying to specify text-sizes in an accessible manner, but I feel that more browsers support this application of CSS sufficiently that it should be available to them. The page may not look perfect, or exactly the way you dreamed, but again, it's readable, and has a bit of extra "panache" over the plain, unstyled document.

For this level, I generally test in Internet Explorer 5 (Mac and Windows).

Level 2: CSS-based layout

The ultimate in CSS expression. This is where the vast majority of browsers have major bugs and problems, and where the most care must be taken to avoid messy pages.

I generally test in Mozilla (and Safari) and Internet Explorer 6 for this level.

The Browsers

I will first try to briefly describe which browsers I am concerned with, and which ones I want to "exclude" from the advanced CSS layout.

"Current Browsers" (at least, the ones I can test in, or want to worry about)

These are the most common, newest, most standards-compliant browsers that can at least deal with CSS-based layouts, even with a few minor bugs or quirks. There are also a couple legacy browsers that I just haven't yet figured out to shield from the 2nd level of CSS.

Internet Explorer 6 Windows (IE6Win)

Still the single most popular browser on the planet, much to the collective frustration of web designers. Microsoft recently announced there will be no new development on Internet Explorer as a free, stand-alone browser (v7 will come with the next OS, whenever that is). With any luck, it will die.

Internet Explorer 5.5 Windows (IE5.5Win)

Not nearly as common as IE6Win, but I'm not 100% certain how to shield this browser without also blocking IE6Win.

Mozilla (Moz)

A very good browser, as of this writing. I test in the the most recent version, and I generally assume that it behaves pretty much the same on all platforms.

Safari - for Mac OS X

This is the deFacto browser in Mac OS X (although I sometimes use Mozilla). After adopting the same strategy that has led to the dominance of Internet Explorer in Windows (bundling it with the Operating System), it has effectively taken over the Mac share of the browser market. It is based on the Linux browser Konquerer.

There are, of course, a plethora of other browsers out there. But, I don't want to spend my life testing in them. I don't expect them to comprise a significant portion of the people visiting my site, and until that changes, I will hope that they either don't get to mess with my CSS layout, or that they don't mess it up too much.

Other Browsers

A few more browsers of note:

Netscape

The Netscape browser is based on (& originally gave birth to) the open-source Mozilla Project. I assume that if it works in the latest major release of Mozilla, it works in the equivalent version of Netscape.

Netscape Navigator 4

Ah yes, the old dinosaur. This used to dominate the browser market, back in the early 1990s. Not anymore. It's CSS support is piss-poor and I don't trust it as far as I can throw it. It handles HTML well enough, though, so people using it should be allowed to read my pages, even if they're missing out on the party. If I've added a few styles visible in my collector ("level 0") style sheet, I test to be sure that's safe in Netscape 4. After that, I don't think about it anymore.

Internet Explorer 5 for the Mac

This is a dead browser, let it die. Microsoft has officially announced there will be no new development of this browser, now that Safari has officially taken over on Mac OS X. They will even discontinue support by 2005. Thankfully, Safari is an excellent browser, and much better than IE5Mac. In the words of Peter-Paul Koch (who's articles I've been reading a lot lately), Internet Explorer 5 for Mac is a "bug ridden crash prone piece of junk". It is still used in the venerable Mac OS 9, but then, so is Netscape 4, and that whole OS is fading out slowly anyhow. OS 9 won't run the majority of newer browsers, anyway, so it's not like they could upgrade, even if they wanted to. Code for it if you want, you'll probably need to use the commented backslash hack. In this scheme, it gets to see "Level 1".

 

Opera

Great, small, relatively obscure, and not free. It has the advantage of being small and light enough to run smoothly on older machines, with excellent CSS support. I don't wanna pay for it, but more power to you if you use it.

Konqueror

Part of the K-windows environment on Linux. Don't know much about it, and can't test on it. I hear Safari for Mac is based on much the same architecture, so I hope it's not too different.

For some professional insight, see these on-line articles:

• Browsers (on quirksMode.org)
• I'll fill this in more when I have time

The Methods

Finally, the application of what I've been talking about this whole article.

The @import "shield"

Nothing new here from my previous article. I use an @import statement that looks like this:

@import url("level1.css");

This hides the Level 1 style sheet from the following browsers, thus "shielding" them from it (source: http://w3development.de/css/hide_css_from_browsers/) :

• Netscape 4.x
• Win IE 3
• Win IE 4 (not 4.72)
• Mac IE 4.01
• Mac IE 4.5
• Konqueror 2.1.2
• Win Amaya 5.1

I haven't confirmed it yet, but it appears that IE Win 4.72, which isn't blocked by this statement, behaves much like IE 5 - it is blocked at the next level, and the simplified Modified Box Model Hack works as expected. It uses the non-standard box model, and parses CSS in a similar way to IE 5. This is good, because it means we can essentially treat IE 4.72 & 5 in the same way, hopefully without any big surprises.

By adding a comment after the @import, the Level 2 style sheet can be shielded from a few more browsers:

@import/* */ url("level2.css");

This hides the Level 2 style sheet from:

• Win IE 5 and lower
• Mac IE 4.01
• Mac IE 5

Notice that Mac IE 5 is now shielded, as well as "Win IE 5 and lower", but I don't know if this includes Win IE 5.5 - I really should confirm this someday.

I will point out that these import statements could be used in one of two ways:

1. In a primary (level 0) style sheet that is linked to html documents with the <link> tag. This linked, level 0 style sheet will be visible to many older browsers, so it could act as an extra layer (level 0.5?), but these browsers are still shielded from the imported sheets. The linked style sheet effectively acts as a collector for the other layers of CSS.
2. directly in a <style> tag in the html document. This requires a few html comments inside the tag, for older browsers that don't support styles.

I prefer the <link> tag, because you can also have some fun with media-dependent sheets (IE Windows won't import a style sheet if you specify a media in the @import statement, eve if it's "screen"), and alternate style sheets that are not practical if the sheets are imported directly from the html document. Your preferences, experience, or requirements may dictate otherwise.

For example, CSS Zen Garden uses a statement like the following in their page:

<style type="text/css" title="currentStyle">
 @import "/001/001.css";
</style>

This allows them to use a cgi or javascript (I don't know exactly how) to dynamically change which style sheet is loaded into the page, based on a link the user clicks on. Pretty neat, hugh? You're site may not need this, however.

 

With this approach, I don't use vey many hacks (except for that second @import statement), since the main browsers that can actually see my CSS should be stable enough that I don't have to worry too much about browser-specific behavior. Except for Internet Explorer for Windows (v 5.5? and 6).

Coping with Internet Explorer

Internet Explorer has it's own set of bugs and unsupported CSS, although version 6 for windows is the best of the lot. Until it dies, I feel it is important to ensure it can display a decent page.

As part of my crusade against IE, I will take this opportunity to remind to that if you are still using Internet Explorer to browse the web, please consider an alternative.

There are a few ways of doing this. Most notabley, there are the various incarnations of the "Box Model Hack". I don't like the original, but have been trying out the "modified Simplified Box Model Hack" (mSBMH) . You can also use conditional comments.

With any version of the box model hack, corrections for IE 5 (&4.72 Win) & 6 (& 5 Mac) are included along with the "standard" declarations. This can be easier for the process of tweaking or de-bugging. On the downside, this also means every other browser is also downloading extra statements that they don't need. There is also no safe bet that some other browser in the future will parse CSS the same way IE currently does, causing the hack to misfure when it shouldn't. Highly unlikely, but still...

Conditional Comments, on the other hand, can achieve a similar effect: feeding specific CSS rules to only certain versions of IE. Using this method, the corrections are not in the main style sheet that every other browser is downloading. This could be a small pain if you are changing things often, and need to adjust both sets of CSS, but for and "deisgn and leave" site, this won't be a problem. Conditional comments also have the advantage that it is a very safe bet that their contents will never be visible to any browser, except the one targetted by the comment.

Conditional comments only work in an html file, and not a CSS file. So, you could either use them to hide one or two corrections in a <style> tag in the header, or if you have a lot of statements, use a <link> tag instead to link to a style sheet with the corrections only for that version of IE.

For example:

<!--[if IE]>
 <link href="ie-only.css" rel="stylesheet" type="text/css" />
<![endif]-->

In theory, I envision the design process something along these lines: First, get a stable design for standards-compliant browsers. Use the modified SBMH in the design phase to add whatever you need to get it to work in IE5 and 6, and modify as you go. Once it's all working, just move all the selectors with * html you added using the mBMH, to a separate style sheet ("ie-only.css"). You might want to leave them in the Level 1 style sheet, because IE 4.72 does not support conditional comments. Then, link that style sheet to the html documents within a conditional comment, as above.

While you're at it, you could remove all the *'s in front of each selector. It's just extra info, and they're no longer necessary, since the "ie-only.css" style sheet is now only visible to IE 5 and up, because of the conditional comments. Keep the html's in there, since this will ensure higher specificity so the rules get applied, no matter when you load them. Taking out the *'s also ensure that, in case future versions of IE fix the selector "bug", but still can't handle the main css properly, the page will not get mangled, as it will see the same CSS as IE 6. If it's safe for IE 6, chances are it will be safe for IE 7, right? I hope so, too.

Summary

The strategy consists of the following layers:

• Level 0 (unstyled) raw HTML or XHTML - safe for non-CSS browsers, and Netscape 4
  • Level 1: Typography, basic CSS - safe for IE 4.72 - IE 5 (5.5?) Win & Mac
    • Level 2: CSS Layout and newer standards - safe for standards-compliant browsers such as Mozilla, Safari, and even IE6

The basic tools:

• @import, and commented @import to "shield" browsers of various grades, thus creating the 3 layers.
• Commented Backslash hack against IE 5 Mac, if you need it for Level 1.
• The modified Simplified Box Model Hack, for the design & testing phase, or if you need it for Level 1.
• Conditional Comments against Internet Explorer Windows (the versions that aren't blocked by the @import "shield").

That's it. Fewer headaches for the amateur web designer (like me!)

Related Links

• Peter-Paul Koch's "Keep it Simple" Column
• Browsers (on quirksMode.org)
• CSS Hacks (quirksMode.org)
• Web Development: Best Practices
• MacIE5 CSS Hack (aka "Commented Backslash Hack")
• The Modified Simplified Box Model Hack
• Hide CSS From Browsers (w3development.de)
• Hide CSS From Browsers
• Microsoft: About Conditional Comments
• more to come...

My new favourite CSS workaround

Originally posted at: http://homepage.mac.com/faucon/Design/newfave_CSS.html

2004-08-12 (Thursday, August 12, 2004)

Update

I haven't confirmed it yet, but it appears that IE Win 4.72 behaves much like IE 5 - the simplified Modified Box Model Hack works as expected. It uses the non-standard box model, and parses CSS in a similar way as IE 5. It won't ever be able to read anything IE 5 can't, but isn't blocked by the same things as other version of IE 4. *phew* breathing a huge sigh of relief...

I like having simple CSS. I don't want to have to remember a huge list of hacks. My usual approach is to shield dead browsers from seeing layout CSS, so they can still read the page, maybe even get to see some typography, but I don't trust them with the layout.

I recently discovered, however, that the first method might not work against Internet Explorer 5.5 for Windows (IE 5.5 Win), which uses an incorrect box model. Peter-Paul Koch has an excellent article about the list of hacks he considers "safe". Using his method, I would need to set up a separate layout CSS file intended solely for IE 5.5 Win, and link it to the html file using conditional comments.

The Modified Simplified Box Model Hack (mSBMH)

Recently, however, I have been playing with the "Modified Simplified Box Model Hack" (mSBMH, aka "Tan Hack"), which allows the CSS to feed approriate widths to IE only, with one statement for IE 5 Win (& the non-standard box model), and a correct statement for IE 6 Win and IE 5 Mac. The big caveat to this method is you have to ensure IE6Win is operating in "Standards" mode (see "DocType Switching").

It basically looks like this:

body { /* what I expect, acording to the standards. */
 width: auto;
 padding: 5%;
}
/* here comes the mSBMH */
* html body { /* the first * ensures only IE will read this */
 width: 100%; /* for IE 5 Win */
 w\idth: 90%; /* other IE */
}

Choice of hacks

I'm starting to prefer this method over the use of the child selector, because it means I can leave the basic declaration in a form that is standards-compliant, even omit width declarations, and feed the widths to the only browsers I care about that can't draw a page properly without them (IE 5 & 6 Win - IE Mac is shielded with an @import statement). It also means I can correct for IE 5 Win's box model, which I can't do easily using only the child selector.

On the Other Hand, I could be wrong...

I have to admit, however, that P. Koch has an excellent point that some of these hacks can't be guaranteed to backfire in the future. His list is pretty darn safe, using workarounds that can only be read by the buggy browsers, and never by one that is standards-compliant. Then again, nothing in this world is guaranteed, and I use the tools that make sense to me at the time.

Related Links

• CSS Hacks
• The Box Model Problem
• The Modified Simplified Box Model Hack

CSS "branded" as a traitor

Originally posted at: http://homepage.mac.com/faucon/Design/brands_css.html

This article is concerned with something I realized while reading "No Logo: Taking Aim at the Brand Bullies", by Naomi Klein. Much of her thesis centres around how brands are trying to usurp and take-over most of our public "space" & culture in the interests of corporate profit.

A point that is made several times throughout the book (I admit, I'm only halfway-through at the moment) is that while brands seek to swamp us with a plethora of products and variety, they also rob consumers of any real choices. Competition and choice are the antithesis of what Brands are all about.

Accessibility is a choice, not a right?

Cascading Style Sheets represent a promise for real choice to web browsers and their users. Cascading Style Sheets are intended to separate content (text) from style (appearance). Designs using only CSS are, by their very nature, fluid, and ultimately subject to the will of the user, who can even go as far as to turn off Style Sheets in some browsers. This technology is often lauded as the gateway to accessibility for the web. Indeed, there are many guidelines on how to make your webpages more "inclusive" and "accessible" (see the "Web Accessibility Initiative" put forth by the W3C for an example).

One of the major strengths of CSS is its ability to negotiate between the designer's preferences, and those of the user. Usually, the user's preferences override those of the designer, if they conflict, or if they are even specified. How many of us actually have a custom style sheet for our web browsers? However, someone with visual impairements, who may have trouble reading small text, or certain color combinations, can tell their browser to make all the text it displays larger, or use certain colors on certain backgrounds. Some users may not even be looking at the page, but relying instead on a screen-reader to read it out to them. As a web designer, it is sometimes difficult to remember that some users are listening to our pages instead of seeing the flashy layout we've constructed.

Many of these accessibility technologies can be thwarted if a web designer uses certain methods. Non-standard HTML code, browser-specific tags, the dreaded <font> tag, even table-based layouts can all interfere with a screen-reader, or user-defined style sheet. Table-based page layouts often require the use of a number of "spacer' graphics, which screen readers often read out, making a page appear quite garbled when the content, including normally blank space, is read out in a different order than the eye might expect.

None of this is new to anyone familiar with CSS, but the point I would like to make is that web designers and developers can choose to design their pages to be inclusive, or exclusive. Why would anyone want to make and exclusive page or site? Because it allows the designer to take advantage of exclusive technologies offered by certain platforms, browsers, etc. to create a desired effect, usually a visual, or multimedia effect. Indeed, if web designers aren't careful, they can unintentionally (or intentionally) make pages that are quite inaccessible to people who literally see things differently than the designer. This may be due to a visual impairement, or because they are using an older browser, or can't afford the latest bleeding edge in browser or display technologies. I have endeavoured to be as inclusive as I can with my own site design, but even I don't claim that my site is totally accessible, mostly because I simply don't have the experience to make that claim with confidence. I hope it is, though.

Why Brands won't like CSS

So, given that designers can choose to be inclusive or not, I realized that as the internet becomes more and more commercially-driven, that choice is threatened by the very forces that have made the web so popular and "accessible".

Following Naomi Klein's argument about how brands operate, it seems to me that, although large branded companies want you to get online and experience the multimedia entertainment that is their site, they want you to experience it the way they intended it. Microsoft may want everybody to get access to the internet, but when you visit their site, they would rather have better control over how their information is displayed to you.

Because brands require strict control over how their information is accessed, they don't want to allow any control to the consumer (in this case, the browser or user) in this respect. Cascading Style Sheets are the very antithesis of a branded entity's desire for control over how their content is accessed. To a brand, the content (text) and style (appearance) are one and the same - inseparable. More often than not, the style is the content, or at least the most important aspect of it.

The danger I fear is that, as more public web "space" becomes commercial, and branded, the more control these brands will desire over how content is accessed over the internet. This does not bode well for true accessibility to internet content, or even the idea of "free speech" and any sense of culture on the internet. This web "space" includes not only the content of the pages downloaded from the servers, but the servers themselves, the servers that create the very infrastructure of the network that is the internet, and ultimately the producers of the programs we use to browse the web. Let's not forget about how Microsoft "bundled" Internet Explorer with it's OS , without giving consumers a choice, so that users never knew there were better alternatives.

Concluding Thoughts

The internet has always seemed to be beyond the reach of corporations and lawyers, but they are catching up. As oppressive forces learn more how to control the internet, many exciting new technologies may be threatened by corporate brand extension. For examples, just look at Napster, mp3s, and other technologies that were, for a time developing faster than the corporate infrastructure could keep up.

I just hope CSS isn't driven out by the brand bullies. I like my choice, and I like being able to give others a choice in how they interact with my content. I believe that will ultimately encourage more people to experience and participate!

Related Links

• At the bottom of this article, you'll see how branding has affected a corporate site's functionality, and possibly accessibility - but at least they're using standards-compliant code :-)