As you might expect, the border-radius property is used a lot like border. That is, you can specify one value for each corner (border-radius: 10px;), one value per corner (border-radius: 1px 2px 3px 4px;), or values for opposite corners (border-radius: 5px 10px). It actually gets more complicated, since in addition to describing corners with one radius (i.e. those with semi-circular curves), you can make elliptically rounded corners by naming two radii. For more detail on this, take a look at the draft spec. Lastly, you can use a property for each corner, border-top-left-radius: 2em;, etc. So, assuming there aren’t any major changes in the spec, expect this to be what gets implemented as part of CSS3, and what you’ll ultimately using in your code.

But what about now? Here? Today? It happens that two of the standards-aware, forward-thinking rendering engines have developed proprietary extensions to CSS that should stand in for border-radius until certain ambiguities in the spec can be resolved, and the property is implented according to the standard. So if you want to use border-radius in your code today, you’ll have to use both the Mozilla– and Webkit-specific CSS properties. Fortunately, both of the proprietary extensions work in the current major releases of their respective browsers.

If you’re making a box with four corners of the same radius, the syntax is the same in Mozilla and Webkit:

-moz-border-radius: 10px; /* 4 corners of radius = 4px*/
-webkit-border-radius: 10px; /* Same as Mozilla */

To specify different radii for each corner, things diverge somewhat.

/* Mozilla: */
-moz-border-radius: 1px 2px 3px 4px;
/* Webkit:
    (The four declarations below amount to the
    same thing as the single rule above) */
-webkit-border-top-left-radius: 1px;
-webkit-border-top-right-radius: 2px;
-webkit-border-bottom-right-radius: 3px;
-webkit-border-bottom-left-radius: 4px;

And that’s the guts of it. So to make a tabbed navigation list, you would use a declaration along the lines of the following (and see the below code in action.):

li {
  border: 1px solid #587402;
  border-bottom: none;
  border-radius: 0 10px 0 10px;
  -moz-border-radius: 10px 10px 0 0;
  -webkit-border-top-left-radius: 10px;
  -webkit-border-top-right-radius: 10px;
  list-style-type: none;
  float: left;
  padding: .5em 1em 0 1em;
}

There you have it. But there are just a couple of other things I want to point out. If the container you’re rounding the corners of has only text content and a background in it, the background will clip to the rounded corners. And indeed, according to the spec, any the contents of a block-level element on which a border-radius is set should clip do the same as long as you set overflow: hidden on those contents. However, the implementations just aren’t there yet. Instead, with anything over and above plain HTML text (for instance, an img or iframe) inside such a container, the square corners will peek outside of the rounded container. (Example)

One solution would be to make the border thick enough that the corners of the inner element can’t poke through the outer border (like so). Though inelegant, this will work just fine if you don’t need everything to round nicely. And this method should suffice for whatever kind of content you’re trying to stuff into your nicely rounded box.

However, if it’s an image you’re putting in the box and you need the inner corners to be rounded as well as the outer corners, then the only answer (for now) is to set the image as a background. Still, if the language of the spec is any indication, it won’t always be this way.

For the poor soul who is trying to squeeze iframe content into a rounded corner box, you’re essentially out of luck at the moment. You can certainly use the thick border method I described above, but short of that, you’ll have to look to the bleeding edge. That is to say, you’ll need something which isn’t yet in any production-quality browser, but that is currently in the Webkit nightlies. I speak of the arcane methods of -webkit-mask-image. This property can take a png or an svg as its url, and pretty much anything you apply it to will play nice and clip to the shape of the image. See for yourself. Still, this last bit is obviously not anything anybody will be using in production code for some time to come.

After reading all of this, if nothing else, I do hope that you’ve come away with a better idea of some of the great things that the CSS working group has in store for you, the developer. But even moreso, hopefully there’s something in all of this mess that you’ll be able to put to use today.

1. What CSS Did We Learn in 2007
   SEO site Search-This lists the CSS techniques they covered throughout last year. It’s a lot of useful, basic, meat-and-potatoes stuff.
2. 101 CSS Techniques Of All Time– Part 1
   Noupe begins a multi-part list of what they find to be the most useful CSS techniques. Again, a lot of great basic stuff for those who may be new to CSS, but it should also be pretty handy as a reference for the grizzled vets out there.
3. Acid 3 Tackles ECMAScript
   Resig lays out exactly what Acid 3 is testing. Very interesting, and some nice insight into some edge cases in Javascript
4. Thoughts on Firefox 3.0
   Nice overview of some of the changes in Firefox 3. He mentions some improvements to the DOM implementation (and links to Mozilla’s more exhaustive list).
5. Resetting Again
   Eric Meyer once again pushes the state-of-the-art in CSS resets.
6. IE6 — CSS Bugs and Fixes Explained
   Another nice reference post. Dave Woods looks at a rogues gallery of cross-browser rendering issues.

That’s it for now. Hopefully someone will find something useful in here.

I’m coming back to this project after letting it go for a while, and sure enough, the problem I was having when I put it down is still vexing me.

One script is intended to grab all of the play-by-play data from retrosheet.org. The files all have urls like this:

http://www.retrosheet.org/1957/1957al.zip

http://www.retrosheet.org/1957/1957nl.zip

http://www.retrosheet.org/1957/1957ml.zip

The snippet below is a simplified version of the code I’m using to build the urls. It’s intended to print the urls of each zip file for each league from 1957 to 2006:

year = 1957
leagues = ['al', 'nl', 'ml']leagues.each do |league|
  while year <= 2006
    url = "http://www.retrosheet.org/#{year}/#{year}#{league}.zip"
    puts url
    year += 1
  end
end

However, it doesn’t do that. It only generates the urls for the AL files, and I can’t get my brain around why.

I’ll be sure to add the solution when I figure it out, but for now I wanted to just document some of the struggles of a Ruby n00b.