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 :-)

Who sets the standards?

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

After trying to re-design 3 websites using CSS-only layouts, I have had to re-think a few things about CSS, standards & web design.

Not so standard

Cascading Style Sheets (CSS) sound great on paper, a screen, or screen reader. That's the theory, anyway. I recently got excited again about web design when I started learning about the potential benefits of using CSS to format web pages. It all sounded great to me, until I tried my hand at fashioning a layout using CSS, and no tables.

I very quickly realized the limitations; CSS is supported differently by each and every different browser out there. So, I can design a layout that makes perfect sense according to the standards set down by the W3C, but some wonder-brat code-monkey at Microsoft decided to use a different box model, so the page will look completely different in Internet Explorer (IE) than intended. Or, a bug in Opera causes floated elements to behave strangely. Older browsers don't fully support even the complete set of CSS1 rules, so things get left out. I've seen Netscape 4 (NS4) garble a page that looks perfectly normal on Safari, and even older versions of IE crash when faced with perfectly standards-compliant CSS code.

Web designers have known about this issue for a long time, and have developed a few strategies to cope:

CSS hacks & workarounds

creatively spicing up the CSS code, exploiting one browser's bugs to solve another bug, resulting in the same layout in each browser. This approach requires a lot of testing - in each and every version of each and every browser - and targetting specific commands to each such browser to achieve the proper effect. I'm an amateur web designer, who also happens to be a graduate student! I don't have the time or resources for this!

Convincing people to actually follow the standards

lobbying the software developers to make standards-compliant browsers, and convincing users to upgrade to these standards-compliant browsers. The folks at the W3C and especially the Web Standards Project (WaSP) have done a great job of this.

The New Face of the Web

Many of the older browsers with poor CSS support are now used so infrequently that it has become relatively practical to simply shield these older browsers from CSS altogether; these browsers only ever get to see the raw HTML. Sure, the page looks boring, but at least you can read it. Any computer still running these older browsers most likely will never be able to upgrade anyway, and will eventually fall into disuse.

There are now some really great, standards-compliant browsers out now, such as any gecko-based browser (Mozilla, Netscape), and Apple's Safari (Apple always tries to do things better). Even IE has come a long way to being more standards-compliant. Although IE (Mac) was the first browser with 100% support for CSS 1, it fallen behind, and has not been updated in years. For instance, IE 6 still does not support:

• position: fixed
• width: auto
• child selectors (i.e. html>body)
• and it often requires widths to be specified explicitly, in order to draw border & backgrounds properly.

So, I usually end up designing a page that looks the way I want in Safari & Mozilla, and then testing in IE and adding IE-specific corrections just for that cursed browser. Microsoft (& Bill Gates) has become a plague upon sensible & intelligent computing design.

Normally, I have adopted the following strategy: I code to standards, and if a browser can't handle it without making a page illegible, it doesn't get to see the code (more on this later). I can quite easily prevent IE from ever seeing the CSS, even using valid statements, but I realized I couldn't afford to do that wholesale to all my CSS code.

The scourge that is Evil Internet Explorer (IE)

This is because IE is the single most popular browser on the internet. Last I checked (for 2003), IE 6 was used by at least 60% of people on the internet, with older versions totalling about the same. Over 95% of all browsers are some version of IE. About 5% of users are on Netscape or Mozilla, leaving a few miniscule slices for all other browsers. Many believe that having IE bundled with MS Windows is responsible for IE's domination. Netscape used to dominate, until IE came on the scene. Microsoft has been taken to court with allegations that this is an unfair business practice.

Mozilla (or Netscape), and Safari (for Mac OS X) are the most common alternatives, but there are other free ones out there - have a look for yourself. It certainly seems to me that most users out there are simply not aware that there are, often better, alternatives to what has been handed to them in a free package. Designers the world over seem to be catering to this lowest common denominator, because they feel they have to accomodate the hordes of ignorant IE users. I have tried to convince people to switch to a more-standards-compliant browser that uses less memory, runs faster, and isn't full of security bugs, and the response I typically get is "well, IE works fine, why should I bother to replace it?" The dramatic shortcomings and dangers of using IE are not apparent to most users, in part because designers work so hard to accomodate them (even if it means having to bend the standards that IE doesn't support.

In fact, I find that many "Internet-based Applications", including the Student information System at my University, does not support browsers other than IE. The older system didn't support any Mac browsers at all (despite being a relatively mac-friendly campus). The new one freezes, or doesn't work properly, unless it's running under IE (Mac/Win). I would have deleted IE on my mac, except for the fact that I may need it to access and use sites that require it.

We are still caught in a vicious cycle. We try to convince people to make better products. We try to convince people to use better alternatives, but after all that, the most common browser is now the least standards-compliant. So, we feel we have to support it. This only encourages users to remain complacent, and continue to use an inferior product.

Conclusion

So, who sets the standards? The W3C has done an amazing job of defining systems & methods for interoperability. The guys at the Web Standards Project are out there lobbying people to adopt these standards. But, if the single most-popular browser on the web doesn't support them, where are we? In "the real world", we are slaves to the popular user; it seems that the public masses define what is "standard" and used most often.

Ultimately, I suppose each web site needs to know it's own clients, and what they use. But, for us amateurs, we're stuck having to support a crappy, yet popular browser. Here's my plea to the internet community: stop using Internet Explorer! Microsoft has already announced there will be no new (free) versions for any platform. Please, let it die. Get a better browser. For the sake of a better internet.

Coping with poor CSS support and buggy browsers

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

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

Another Update

I've had a slight change of heart, and I'm still experimenting. I now have a new approach to coping with CSS bugs. Same strategy, different methods.

2004-08-11 (Wednesday, August 11, 2004)

Update

I have become rather fond of my new favourite CSS Hack, which I have gotten into the habit of using instead of the second method described in this article.

2004-05-18 (Tuesday, May 18, 2004)

CSS is supposed to be very elegant tool for achieving flexible layouts of sensibly-marked HTML pages. But, not all browsers support CSS to the same degree, or even in the same way. And then there are the various bugs, etc. What's an amateur web designer to do?

The power of CSS, and it's limitations

I have had an interest in web design re-awakened. To be honest, the main reason for this was the re-discovery of Cascading Style Sheets CSS. I decided to learn more about this tool from the World Wide Web Consortium (W3C), and discovered the real power of CSS:

• using a single file to describe the layout for many pages on a single site.
  • this makes entire site re-designs much simpler & efficient.
• allows pages to be less cluttered with spacer graphics & extra table code, nested tables, etc.
  • can also decrease download time because of this!

The idea is to separate content from format. You have a page with the content, marked up to apply semantic structure, and the CSS makes it look the way you want. I find this makes editing in the HTML file much easier, because I don't have to wade through nested tables, etc. If you use XHTML (Extensible Hypertext Markup Language), the same document (content) can be used and displayed completely differently on the screen, on paper, or through another XML-based reader. The possibilities for document publishing are seemingly limitless.

This model makes a lot of sense for formatting a lot of content. However, internet-pages have become more and more visually-based. The content & format have become merged in many cases, or dependent on each other. This makes sense to me from a marketing perspective; form & content are inseparable. But, if you want to publish documents, the W3C model of XHTML & CSS is a powerful combination.

I found some problems when I tried to apply this model. The most important is the fact that seemingly every browser out there supports CSS to different degrees, and even in different ways. IE's infamous incorrect box model, and other browser bugs and quirks, have spawned the need for several hacks & workarounds. As an amateur web designer, I don't have time to test for every single possible browser and how it's going to butcher my valid, standards-compliant code.

Fortunately, the good people at the Web Standards Project (WaSP) work tirelessly with software developers and users, to encourage everyone to adopt and support the standards. This has led to some important changes toward the end of the last century, including much better support for standards, including CSS, XHTML, and many others, I am sure. Plus, users have been convinced to upgrade to these improved standards-compliant browsers, whenever possible, so designers can start designing to standards.

Unfortunately, browser bugs, and older versions have not been completely eliminated. Older computers may never be able to upgrade to the newer browsers. And then there's Microsoft Internet Explorer - the bane of all web designers. This is currently (2003-2004) the single most popular browser in use. But Microsoft has even admitted to no longer developing it as a stand-alone product. It has fallen behind in support of standards. It is also full of security problems, so I would highly recommend finding an alternative if you are still using IE. I suggest a few on my links page.

Coping with the bugs

In order to cope with the perilous sea of buggy browsers, I have adopted the following strategy: I code to standards, and I only show it to browsers that can handle it properly.

There are an overwhelming number of CSS hacks & worksrounds out there. I only use two (2), although the first is really a combination of 2 other hacks I've seen out there.

1. modified @import statement.

I use a basic stylesheet for textual formatting - hopefully nothing that it not almost universally supported. This is linked to the html document in the header. All the layout, etc. goes into a separate style sheet that is imported into the basic style sheet. This hides the layout from many older browsers, including the notable Netscape 4. The following statement

@import url("stylesheet.css");

is perfectly valid, according to CSS level 1, but the following browsers can't understand it, and ignore it, thus never loading the imported stylesheet (according to w3development.de):

• 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

However, this won't hide the Style Sheet from IE 4.72 - which I've seen crash when fed perfectly valid CSS level 2, or other code it doesn't understand. So, I add a comment immediately after the @import declaration, but before the url statement:

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

This comment hack was originally intended to go immediately after a selector (see w3development.de), but I've found that it also works here. This also confuses and thus hides the import statement for the following browsers:

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

The idea is that all these older & buggy browsers will not load the layout CSS code. They will still display the document. And it may look plain, but at least it's readable, and the browser doesn't crash! Theoretically, only version 6 browsers or higher will be able to see the layout CSS code. All of the these that I know of are very standards-compiant and don't garble the page. I have tested this for Safari & Mozilla (Mac OS X) and IE 6 Win, but I presume it works for others (let me know if you know otherwise). This is also validated by the W3C.

The one major drawback is that IE 6 Win still sees the code, and it is still not terribly standards compliant. It has some problems with the following:

• position: fixed
• width: auto (IE needs explicit width specified to draw many things properly)
• max-width: and min-width:
• child selectors; IE 6 Win does not support this CSS 2 rule.

I could exclude IE 6 Win from seeing the imported sheet, by adding a media rule.

@import/* */ url("stylesheet.css") screen;
/* This also hides the style sheet from other browsers 
that do not support this CSS level 2 statement */

However, I felt I needed to support some version of Internet Explorer because it is sadly the single most popular browser in use (over 60% in 2003).

By the way, if you are still using Internet Explorer, please consider an alternative.

When necessary, I employ a workaround that exploits a parsing bug in IE 6 Win to help me write code that it understands...

2. Child selector (for IE 6 Win)

I first design a layout that works on Safari & Mozilla. I then test in IE 6 Win, and fix the problems. For example, where I had width: auto, I replace with a specified width. I then add a duplicate selector statement that starts with html>body, and feed the correct (intended) values to CSS2-compliant browsers.

For example:

p { width: auto; }

would become:

p  { width: 640px; } /* IE6w */
html> body p { width: auto } /* correct values, hidden from IE 6 Win by the child selector */

The body tag is always a child (immediate descendent) of the html tag, so this always applies. Anything else is contained within the body (descendants of body), so this is always valid.

The Tantek Hack, refined in the Simplified Box Model Hack (or Tan Hack) is often used as a similar work around to target code specific for IE 5.x/Win, but I find that it is irritatingly complex, and I don't have time to figure out the 3 different values you need to feed to 3 different types of browsers. Plus, I've already excluded IE 5 from even seeing the CSS code with the first @import statement, so who cares?

All this trouble, to achieve complex layouts that are stable across different browsers. Actually, I end up with 2 distinct layouts: one that use the standards, and is flexible, according to what I envisioned. And then an inferior one for IE 6 Win that works, but is not as elegant. There are other approaches described on the internet, such as nesting div's & such in the html to achieve a visual layout separate from the "content" (text), but in my mind this is counter-productive, since it goes against the whole point of using CSS! The layout becomes dependent on a bunch of extra div tags that are there solely for layout purposes. Granted, they are much more flexible and take up less space than the table mark-up, but it still bugs me. I admit that I sometimes wrap things in a few div's to allow for more complex layout schemes, but they always make semantic sense; to contain content separately from an index, footer, or title banner, and so forth.

Conclusion

So, this approach allows a well-structured HTML, or XHTML document to be displayed in a potentially graphically and visually interesting way. But, only on newer browsers, because I don't have the time to craft special code to accommodate every browser bug in existence. I have chosen to fight the few battles worth fighting.

Related Links

• My New Favourite CSS Hack
• Hide CSS from Browsers
• CSS Hacks (quirksmode.org)
• Browsers, and how to deal with them

Layout: Tables or CSS?

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

HTML purists (& the W3C) frown upon using html tables to achieve page layout & design. However, the layout power of a table has been exploited since the 1990's to create visually interesting page designs. CSS was supposed to free us from the inappropriate use of html for layout. But, CSS has it's limitations.

Comparison

This section added 2004-05-23 (May 23, 2004).

Tables and CSS are different. They are different tools, suited for different tasks. Learn to use them appropriately.

Tables	CSS
Intended to display tabular data. This could be data (experimental, computer, etc.), rigid forms, and any other information where the layout is part of the information, crucial to it's content and meaning.	Intended to apply style to (any) all elements in an HTML document. Style is independent of content.
Coded directly with other content of a document.	Many ways to attach & apply style sheets (separate file) to one, or several documents. Potentially allows users to choose from several alternate style sheets for the same page (the Mozilla browser already has this option). Makes it simpler to change the look / style / layout design of many documents on a site, just by changing the style sheets.
Design is distributed (redundantly) throughout all pages in the site. All the layout code from the table must be downloaded with each page, but only as much as is present within the document.	Site design could be potentially "front-loaded", where all the style sheets must be downloaded with the first page. However, once downloaded, style sheets are then cached, and don't need to be downloaded again for the rest of the pages on the site. Designers may wish to limit the style sheets required and downloaded for the first page of a site, thus allowing this important front page to load faster. If the user chooses to visit more pages in the site, the required style sheets can be downloaded when they are needed. Or, keep the style sheets short & simple, thus reducing overall file sizes needed to download.
Rigid layouts (relatively).	Fluid layout (much more fluid than tables).
User has no control over layout.	CSS negotiates with the user to decide how to apply a style sheet. The user always has the last say about how to display elements. An extreme case is a user's custom style sheet, ignoring any style sheet specified within the document. Designers may not like this, but it allows users with special needs to control how they access the content. e.g. larger fonts, or certain color combinations to enhance readability (custom line-lengths, etc.). This can ultimately allow the content to be more accessible.
Widely supported by almost any browser (even the older ones).	In practice, CSS is only supported by newer browsers, sometimes not fully, and each has its own bugs.
Many Techniques widely used and time-tested for over a decade.	Many creative techniques described, and tested, though usually complex. Continually developing. Forward-compatibility may be uncertain.
A practice started in the early days of graphical web design, tables are often exploited to create the layout of entire documents by placing content within the table structure. Complex layouts often require nesting tables within tables, or combinations of colspan and rowspan attributes.	Complex layouts sometimes require extra tags within the document, but these can have semantic value (e.g. dividing obvious sections of a document), but hot nearly as many tags as tables require.
Easy to understand the concepts (if you're used to working with tables). Nested tables & tags can be confusing and difficult to figure out.	Must learn syntax, box-model, etc. - but it's all explained in the standards, freely available from the W3C. Can be confusing, if you're used to working with tables, but some find it makes a lot of sense (once you get used to it). The most frustrating and time-consuming aspect is coping with all the browser bugs and varrying levels of support. The best advice I can give is that you can't design with CSS the same way you would using tables. You have to think more fluidly, and you can't expect your pages to have the exact same, pixel-perfect layout in all browsers.

From Tables to CSS; standard problems

Since the 1990's, web designers (professional, and amateur alike) have been using html tables & nesting tables inside tables to position graphical and content elements on a web page. How else could you have a 3-column text layout, and position bits of graphics around text?

Cascading Style Sheets (CSS) are supposed to allow us to do what html was intended for: separate content (html) from format (style). The standards intelligently designed by the W3C are elegant and powerful. Unfortunately, they were not truly standard when first written, as many browsers did not support the full CSS specification. For more info, see the WaSP for a slightly longer description of the problem with web "standards".

So, where does that leave the amateur web designer? I still need to make a page, and I have creative energy to channel into my page design. What should I use, tables or CSS? Well, I recognize the benefits of using CSS and have decided to switch over. I really like the power of the standard, and the benefits, so I have decided to use it. After many hours of frustration, I have developed an approach to limit the browser bugs I need to address. Older browsers may see my pages as boring, without any CSS layout, but at least they are readable. Such pages are also more accessible to screen readers and people using other special software to help overcome visual impairements, faster to download (without extra code & spacer graphics), and easier to maintain and manage content. For other benefits, see the W3C.

I think it's absurd (but understandable) that html elements like tables are more stable & widely supported than CSS layout tools. CSS may simply be too new to become well established in browsers, but a standard is necessary to make web design practical. Standards mean I don't have to test or write special workarounds for separate browsers that read the same code in different ways.

The W3C and html purists frown on using tables to achieve layout for an entire page. They were intended to display tabular data. I've read many articles online re-enforcing this notion, so I decided to abandon the table for page layout. Unfortunately, this has meant that it takes me significantly longer to design a page, because I have to test CSS code and sift through lots of code to fix bugs, and test on a few platforms. But, I end up with a very flexible design, and pages that are sematically and structurally sound (and valid!). However, I have often wondered if having a "valid" document & CSS is worth all the extra time, when it ultimately results in pages that are less exciting on older browsers, and all the extra time & frustration it takes.

I have committed to an approach of separate content from style, because I believe it makes more sense from the perspective of publishing documents for others to view. HTML (or XHTML, see the W3C for more info) and CSS are a powerful combination allowing the same content to be displayed in a dynamic fashion, in different media types. CSS negotiates between the designer's intent, and the needs of the user. For example, some users need larger text to read - CSS allows the user to override the designer's format to allow one that is more accessible to the user's needs. This is why the <font> tag is so dangerous in html; not only is it not a real html tag (it's an extension supported by many browsers), but it does not allow the user a say as to what the browser will do with it, unlike CSS. There is really no good reason to use the<font> tag, since CSS is a much better way to format text and is generally much better supported in this respect. On the other hand, layout is another story altogether!

The right tool for the job

The internet (specifically, the World Wide Web) has evolved to be quite different than what was originally envisioned. It has become a powerhouse of marketing and business enterprise. At least, in developed countries. Anyway, the point is that the internet is no longer simply a tool to post documents to read. It is used by companies to sell things, manage information, and run "internet applications". In this setting, it seems to me that content can not be easily separated from format. In many respects, the two are very much inter-dependent, such as from a marketing perspective, or when designing an internet application. In this case, it does make sense to me to use a table, or other html markup to rigidly structure the layout of a page. The layout and style of these pages need to be stable across many different platforms, or the content will be lost. In this setting, pages are no longer simply documents to be posted for others to read - they are locations where users can interact with the content. And the content includes the graphics, layout, and formatting of every pixel in the browser window.

Conclusion

My conclusion is that if you want to use the internet to sell things, or to create a visual environment that is stable across multiple platforms & user agents, using tables for layout makes a lot of sense. It just means people with visual problems may have problems getting your message. But, this is a relatively small sector of the market for most businesses, and there are other alternatives for accessibility. If you want interactivity, that's what flash is for (or other technologies). But, if you want to publish documents, the W3C standards model of XHTML & CSS is a powerful combination. Perhaps what this eludes to is a need for the world wide web technology itself to change into a structure that is more suitable to interaction among users, and between users and their content. But the task of designing the future of the internet I leave to the professionals, and the needs of the users. I pray that it is not dictated to us by Microsoft.

Related Links

• Tables My Ass
• An Objective Look at Table Based vs. CSS Based Design