Redesign: x + 3 v2

I’ve been remiss in calling attention to the redesign launched here a few months ago. May thanks to Stephanie for helping with the design.

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.

Images for Form Submit Buttons Using CSS

Browsers’ default submit buttons can be boring, ugly, or just not match your site. Whatever your reason, it would be nice to dress up the buttons using CSS when you don’t want to (or can’t) change the HTML to use <input type="image" />

I’ve been struggling to find a way to do it in a cross-browser way, and just recently stumbled upon the answer.
Continue reading “Images for Form Submit Buttons Using CSS”

Browser Statistics

My general rule for browser compatibility when I develop a site is to follow a simple formula: if a browser has a 5% or larger share, make sure the site works on that browser, with or without JavaScript. If it’s under 5%, make sure it works so long as JavaScript is enabled (since JavaScript can be used to work around a lot of bugs). If it’s under 1%, just ignore it.

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

Browser Visitors
Firefox 66.9%
Internet Explorer 10.6%
Safari 8.6%
Chrome 8.1%
Opera 3.2%
Mozilla 2.2%

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

Browser Version Visitors
Firefox 3.5.x 49%
Firefox 3.0.x 17%
Safari 4.0.x 8%
Internet Explorer 8.0 6%
Chrome 3.0.x 6%
Internet Explorer 7.0 4%
Opera 9.80 3%
Mozilla 1.9.x 2%
Firefox 2.0.x 1%

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.

IE Bug Improperly Displays Floats

Updated (2009-01-15): I finally stumbled across the answer (see below).

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

Flowing red and blue boxes

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

Floating red with blue, 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:

Floating red with blue, IE

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.