• deviant box model
• DOCTYPE switching
• no min- or max- widths or heights
• no variable-opacity PNG support
• no SVG support
• inability to serve XHTML as application/XML

and the sad list could go on. Many of these faults have been addressed and corrected, but increased support has been incremental, over the last six or seven years. However, earlier this year, Microsoft announced that IE 8 passed the Acid 2 test, an important demonstration of supporting most key CSS properties. Yesterday, they made that good news quite a bit sweeter, by announcing that the default rendering mode for IE8 will be with their highest support of standards, which reversed a previous plan requiring designers to include special code in their pages to trigger IE8′s standards rendering mode.

See also Microsoft’s announcement.

On their download page, Apple touts the many advantages of Safari for Windows, although most of them are advantages only over the rapidly diminishing Internet Explorer 6. However, the top of the list promised that Safari would be, hands-down, the fastest browser. Well, it is. It’s amazingly fast. It also handles Flash exceptionally well. I tested it on some very Flash-intensive sites, e.g. marinewebservices.com and truckwebservices.com, and pages flew in, particularly when compared to Firefox, which seems to struggle with Flash in large quantities. (Flashblock is one of my favorite Firefox extensions.)

But the speed comes at a cost. Windows Safari’s CSS rendering is a shambles compared to its brother on the Mac. Positioned divs overlap each other unpredictably. CSS-based slideshows don’t work. I was curious how it would perform on the Acid2 Test, since Safari for Mac earned well-deserved fame for being the first to pass it. As you can see from the screenshot, it rendered the test image slightly better than Firefox 2, but not by much. Something is clearly wrong with Safari.

I might make a more detailed inventory sometime, but for now, all I can say is another broken browser is not what Windows needs.

C’mon Apple. Keep doing what you do best… iTunes, iPod, iPhone, and … what’s that computer you specialize in? Oh yeah, the Mac. Nice job, that.

Just start off your stylesheet with:

* {margin: 0; padding: 0;}

and bam! suddenly you, not the browser manufacturers, are in control of the “white space” of every element. No worrying about differing bottom margins on headings, paragraphs, or anything else, for that matter.

So what’s the problem? In a word, the universal whitespace reset is dumb. It’s not necessarily a dumb thing to do—I simply mean that it lacks the intelligence to see when it should be applied and when it shouldn’t. I first encountered a problem with it when I was using on a dynamic site that retrieved large amounts of inventory items. I found that these inventory search results were consistently crashing in Internet Explorer (go figure), but it stopped crashing when I removed the universal whitespace reset from the stylesheet.

What was happening was every element, every em, i, b, every table, tr, td, every img, div, and p, was being checked for the presence of dreaded padding or margin, and IE was being crushed by the task. (Sometimes you’ve got to feel sorry for Internet Explorer.)

Another disadvantage is that in any environment where non-coders might be editing pages to any extent… (e.g. clients via a CMS) some of the most familiar and intuitive means of working with tables become unpredictable. For instance, in both Firefox and IE, the cellpadding attribute becomes useless. In standards-friendly browsers such as Firefox, the “align” attribute stops working when the value is “center.” (Yes, it centers via equal margins, but with the universal white space reset, you, my friend, have wiped out those margins.) CSS declarations, even with very low precedence levels in the cascade, override HTML attributes.

Since the whitespace properties of margin and padding don’t even occur in most inline elements, it doesn’t really make sense to have the browsers check them on every page, now, does it?

Here’s my proposed solution to creating a level playing field regarding whitespace concerns:

address, blockquote, p, div,
form, iframe, select, textarea,
h1, h2, h3, h4, h5, h6,
dl, ol, ul, li, dt, dd
{margin:0; padding:0;}

This deals with all of the major elements most likely to create whitespace problems, without squandering browser resources or disabling HTML attributes. You may also be interested in Eric Meyer’s solution, although his reset stylesheet deals with many tags that are unlikely to have padding or margin presets in browser stylesheets. He also goes for a complete font-weight/font-style reset—as for myself, I can live with the fact that browsers give bold text for headings and italics for cite. I’ll restyle those assumptions when I feel the need to. Also, if one limits the reset to matters of margin and padding only, it seems to make sense to me to include form elements. What do you think?

Although on this particular site I use a fixed-width layout, I’m a huge fan of liquid layouts, as you can see at A1 ProCoat and frimmin.com. The common arrangement of a 640- or 800-pixel-wide fixed-pixel presentation floating in the middle (or worse, slapped against the left side of the window) of an 1200- or 1600- pixel-wide screen works for many situations (as for this site), but they have disadvantages as well. Web pages flow. W3C specifications speak of the flow of the page on the screen, but too many designers IMHO, don’t understand that the Web really isn’t print, and use pixel-perfect designs to try to translate a print message to the screen. Some problems I’ve noticed with these designs are:

• An absurd amount of wasted screen space; This will only get worse as monitor resolutions get bigger and bigger. I recently tested my personal site (all liquid) on a 2560-pixel-wide Mac monitor, maximized (or as close to maximized as Mac allows). It looked just as good as at 800px.
• Frequently, inaccessible text which can not be resized, which is amazing when you consider how many of these sites are in micro text! I propose every site should be tested by its designers for readability after 24 hrs. without sleep. (That would give some incentive to make the text scalable!)
• Frequently, an inability to think in semantic (X)HTML. (Great, you optimized it for a soon-to-be-obsolete monitor resolution, but what about the Palm? Or the cellphone? The Braille reader or text reader?)

Liquid layouts avoid these problems. They adapt to any size screen, they’re more conducive to thinking in terms of document flow rather than print positioning, and they simply “let the Web be the Web.” I can only speak for myself, but I think other designers who are comfortable using liquid layouts are probably also more comfortable thinking in semantic (X)HTML, and basic accessibility. Furthermore, they encourage users to resize, which is a great habit for users to get into, as they are the ones who ultimately know what’s “too big,” “too small,” or “too long” for themselves.

But there are disadvantages with liquid vis-a-vis fixed:

• Line lengths can become too long for extensive reading. (Easily remedied by resizing the browser window.)
• The huge screen resolutions available today, a layout stretched too wide can reveal “holes” or gaps where background images end. However, this can be worked around by using background colors in conjunction with background images, and making sure that the images used blend into the background colors.<”/li>
• A more serious difficulty is that images can break the layout when the window is made smaller.

Richard Rutter of clagnut.com » has done some fascinating work that solves the latter problem. I like his solution » of using percentage widths (with max-width set to actual width) for small and medium images, and overflow:hidden for wide images.

I’ve extensively used this technique on my personal website, The Wild Things of God.

NN4 will choke on a page where there is inline style on images, but this problem is rapidly becoming irrelevant as that browser fades from use.

So it began. I searched everything I could for information on this bug, from CSS books, to my favorite CSS sites, to Google searches with every combination of keywords I could think of. Nothing! Nothing I had read could account for this. I tested other stylesheets in my preferred layout. Some broke, some didn’t, and the ones which broke, broke in different places!

So my layout wasn’t buggy, but by now, I was going buggy! At least I could concentrate my search for the bug in the styles rather than the structure. The worst one was the Forest stylesheet (which is the default index page on my personal site.) I had noticed from the beginning that the problem was worse the smaller the window became—the “magic” points were closer together. Finally, I realized it was related to word-wrapping in some hyperlinked movie titles in my most recent post. I tried using Microsoft’s “word-wrap” property, which helped nothing. At odd points, when these italicized hyperlinked words wrapped down to the next line, the content DIV would fall away. Italicized words. (I may be one of the few designers who actually uses the recommended CITE tag for titles, and CITE renders as italics by default.) Not expecting anything, I typed “IE CSS bugs italics,” and found

the page that explained everything».

Italics! How could the bug be italics? Every word processor in the last 20 years has handled italics. as has every Web browser from Netscape 1 on. How could Internet Explorer 6 mangle them? (Answer: it mangles them effectively as it mangles many things.) Sarcasm aside, IE panics when calcuting width for italics in boxes that are beside floats. This is a nefarious problem that seems to be almost unknown compared to, say, the Box-Model bug. Nefarious, because when can you guarantee that your client will not need italic text, maybe a LOT of italic text, whether it’s an extended quote, a long title, or an emphasized sentence? Understanding this potential layout-destroyer should be as well understood as float bugs and box-model bugs.

There is a fix, and it’s not as simple as styling CITE and EM as “font-style:oblique,” (which doesn’t work, in case you were wondering, the bug affects anything with a slanted type). Bruno Fassino explains all that is known about it at this time on a page at the Position is Everything page. My very brief explanation of the fix, which follows, is no substitute for his lucid work, but I think more pages explaining this are desperately needed.

The key is to add styles to the lowest-level block element which contains the italic text. This will almost always be either a P, DL, UL, OL, BLOCKQUOTE, or DIV tag. Often it’s a direct parent, but sometimes, as in the case of my CITE tags within A tags, the lowest-level block is a grand-parent or higher. The styles must be visible only to Internet Explorer for Windows, and not only that, but there are two mutually exclusive stylings needed, one set for IE Win 5.5+, and another for IE Win 5.0.

IE 5.0 Win must make the width of the containing block 100%, and give it the overflow:hidden style. IE 5.5+ Win must give it an auto-sized width, a minimal height, and visible overflow. The stylesheet snippet below hides it from all non-IEWin browsers, and feeds the corrected styles to the proper versions of IE rather painlessly. For details, see IE and Italics Problem» at Position is Everything.net.

/* \*/
* html p, * html dl, * html ul,
* html ol, * html blockquote, * html div {
         overflow: hidden;
	 overflow: visible;
	 width: 100%;
	 width: auto;
	 height: 1%;   }
/* */

An alternate solution would be to use IE Win’s conditional comments in the HTML. Peter Paul Koch at Quirksmode» makes an excellent case for using conditional comments rather than parser hacks. I sometimes use them, but sometimes prefer to put them in the stylesheets—they don’t mix well with stylesheet switchers, for instance.