There’s still a fair amount of tweaking to be done (isn’t there always?), and I can’t promise universal browser support.

I’m experimenting with a few newer CSS features. Notably:

• Headers use the Republikaps font, loaded using @font-face
• A fair number of drop-shadows are scattered throughout
• The border of the main content area is a combination of two rounded-corner boxes, the inner with a drop-shadow, the outer with an inset drop-shadow (note that due to a bug in WebKit, Safari and Chrome users may see a square outer border)

Much of the above won’t be visible to the 6% of my readers still on Internet Explorer. Frankly, I’m alright with that. In the past month, Opera’s 1.69% among visits to this site outranks IE6 and IE7 combined.

Let me know what you think, or call my attention to any bugs you might notice.

I’ve been struggling to find a way to do it in a cross-browser way, and just recently stumbled upon the answer.

The Problem

Assume the following HTML snippet:

<form action="" method="post">
  <div class="form-submit">
    <input type="submit" name="submit" value="Submit" />
  </div>
</form>

Here’s my first attempt at CSS for the submit button (assume, here, that I have a 101x39px image to use for the submit button):

form .form-submit input {
  display: block;
  width: 101px;
  height: 39px;
  background-color: transparent;
  background-image: url(submit.png);
  background-repeat: no-repeat;
  background-position: 0 0;
  padding: 0;
  margin: 0;
  border: none;
  cursor: pointer;
  text-indent: -9000px;
}

Not to bad. It’s a standard CSS image replacement technique with a few small additions to override some default button styles. But in IE7 and below, the button disappears. Why is that? It seems the text-indent is applied to the whole input, sending it far off the screen.

So what if we remove that text-indent? As you might have guessed, the text still appears on top of the image. Even if we set text-indent: 0 in a conditional comment for IE7 and below, you still have a problem for those browsers.

So what about putting the image into the padding, instead?

  text-indent: 0;
  padding: 39px 0 0 0;
  height: 0;

Once again, the button disappears in IE7 and below.

The Solution

But, what if one day you make a mistake? What if you forget to set height to 0 when you add the padding-top? Amazingly, you don’t get a 78px tall element; it remains 39px tall in all browsers (where all includes IE8, IE7, IE6, Firefox 3.5, Chrome 3, Safari 4, and Opera 10)! Why is that? I have no idea, but it works.

One problem still remains, though. In Opera, the text is still visible on top of the image. So we return to our good friend text-indent. Set it to an arbitrarily large negative number, but keep it at 0 for IE7 and below using CSS in a conditional comment. The button should now be replaced with an image in all browsers.

form .form-submit input {
  display: block;
  width: 101px;
  height: 39px;
  background-color: transparent;
  background-image: url(submit.png);
  background-repeat: no-repeat;
  background-position: 0 0;
  padding: 39px 0 0 0;
  border: none;
  cursor: pointer;
  text-indent: -9000px;
}

And don’t forget, in your IE lte 7 conditional stylesheet:

form .form-submit input {
  text-indent: 0;
}

I’m in the preliminary stages of thinking about a re-design for this site, so I thought it would be interesting to look at the browser statistics for my readers before I get going.

Here’s the breakdown for the last month, by browser (including those 1% and above):

The order changes a bit when you break it down by browser version (again, only those 1% and above):

Notice a browser not on that list? That’s right, fewer than 1% of my visitors use IE 6. As far as I’m concerned, that browser version is no longer supported for this site. It can hang out in the corner with Camino, Konquerer, and Firefox 1.5.

I’m also surprised by both the high position of Safari on the list and the low position of IE 7. It seems that a lot more people with Macs read this site than I expected (24% of my visitors) and that the IE users are actually upgrading (and if you haven’t yet, please do so now; it would be nice to get IE 7 under that 1% mark, too).

I’m still not to the point where I can rely on visitor’s browsers supporting much of CSS3, in large part due to the still-high position of Firefox 3.0.x. I anticipate that number dropping significantly in the coming months, though, so I may revisit this before I get around to actually doing a re-design. Overall, I would say things are trending in an agreeable direction, though (thank you!).

Note: I should make it clear that the above conclusions only apply to this site, and have little bearing on other websites I develop. Unfortunately, IE 6 still has a strong impact elsewhere on the Internet.

[Originally posted 2008-01-18] I’ve recently come to understand a bug in how Internet Explorer handles floats. I doubt this is a new discovery, but I haven’t read about it and can’t easily find it through Google. To put it simply, floated boxes should overlap non-positioned block boxes but displace inline boxes; Internet Explorer displaces both. Now that I’ve said it simply, I’ll try to say it more clearly and accurately and with pictures.

We’ll start with a pretty simple XHTML document:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>
		<title>IE Float Bug</title>
	</head>
	<body>
		<p id="red">red</p>
		<p id="blue">blue</p>
	</body>
</html>

Now let’s add some color and play with our p boxes, adding the following to our header:

<style type="text/css">
	p {
		margin: 0 5px 0 0;
		padding: 0;
		color: #FFFFFF;
		border: 5px solid #000000;
		text-align: center;
	}
	#red {
		background-color: #FF0000;
		width: 100px;
		height: 100px;
		line-height: 100px;
	}
	#blue {
		background-color: #0000FF;
		width: 150px;
		height: 150px;
		line-height: 150px;
	}
</style>

That should give us a page that looks like:

Now, let’s add float: left; to #red and see what happens in Firefox:

To explain what’s going on here, #red is removed from the normal flow of the document. #blue, then, being a block box, moves to where it would be if #red were not in the document at all. The text inside of #blue, though, has to be aware (if you’ll allow this personification) of the float, because its line box has to be shortened to avoid overlapping with #red‘s margin box. This all conforms to the CSS 2.1 visual formatting model.

But look at what happens in Internet Explorer 7:

Instead of just displacing the text, the entire block-level box #blue has shifted to make room for #red. This would be entirely appropriate if I had created a new block formatting context by, for example, adding overflow: hidden to #blue. But so long as #blue‘s overflow is set to its default value of visible, as it is here, we have no new block formatting context, so #red should overlap #blue.

So how do I fix this? How do I make IE render this the same way as Firefox? I would appreciate any help.

Update: The Answer

If you can avoid triggering hasLayout in IE, then #blue will behave as it should. In the example above, setting height and width on #blue both triggered it, but with a few changes, we can avoid that to get the results we want.

First, remove height and width from #blue. To be honest, height wasn’t necessary, since line-height already sets the height of the element (assuming you’ve only one line of text).

So how do we constrain the width? By setting width on body (or a div that wraps both ps, if you want to do this in the context of a real page). So give body a width of 165px(to accommodate the desired width, margin, and border or #blue).

So our final CSS looks like:

<style type="text/css">
	body {
		width: 165px;
	}
	p {
		margin: 0 5px 0 0;
		padding: 0;
		color: #FFFFFF;
		border: 5px solid #000000;
		text-align: center;
	}
	#red {
		background-color: #FF0000;
		width: 100px;
		height: 100px;
		line-height: 100px;
	}
	#blue {
		background-color: #0000FF;
		line-height: 150px;
	}
</style>

That gives us the same result in IE and Firefox.