You bring up some interesting issues Triel, thanks for the question!

CSS Benefit #1: Forward Compatibility

First off, CSS is a web standard which means it is not likely to go away anytime soon. Moreover, it is designed to be forward-compatible, which means what you write today will continue working into the future. Even if the specifications for how CSS is written change, it is a guiding principle of CSS’s design that changes to a given property can only build upon existing syntax, they cannot replace it entirely.

A perfect example of this is the evolution of CSS backgrounds to allow for multiple background images. For any given background property, we originally supplied a single value (e.g. background-image: url(single.png)). When the idea of multiple backgrounds was introduced, the syntax needed to remain compatible with existing syntax, so the specification authors opted to simply separate multiple image values with a comma (e.g. background-image: url(first.png), url(second.png)).

CSS Benefit #2: Browsers Ignore What They Don’t Understand

In concert with CSS’s design being inherently forward-compatible, the specifications for CSS (and HTML) instruct browsers to ignore any syntax they don’t implement or recognize. This creates an interesting opportunity for us as designers: armed with this knowledge, we can supply alternate rules to browsers based on their level of CSS understanding. In the case of the background-image property, we could write something like this:

.selector {
  background-image: url(single.png);
  background-image: url(first.png), url(second.png);
}

This may look a bit weird because you are essentially defining the same property twice, but thanks to the “ignore what you don’t understand” rule, it makes magic happen. In modern browsers that implement multiple backgrounds, the second declaration acts as a replacement for the first and the two background images are applied to the element. In browsers that don’t know what to do with that comma, the second declaration is thrown out and the first declaration is applied.

This concept is what makes progressive enhancement possible in CSS and allows us to offer support to older browsers while optimizing the experience in modern browsers. Because CSS is so smartly designed in this way (and others), I would not worry about it going away.

The Larger Question

Your question does hint at one challenge we deal with constantly: How many hoops should we jump through to achieve cross-browser design parity?

In your case, you used CSS to round some corners and then added JavaScript into the mix to make older IE versions play along. Your co-worker, on the other hand, would have gone the route of multiple images to achieve the same effect, probably because it is what works universally back to browsers like Netscape 4.

For a while now, many of us have been promoting the idea that attempting to craft a design that looks identical in every browser is an impossible task because:

• Each browser is slightly different in its interpretation and/or execution of certain features.
• Some browsers accidentally introduce rendering bugs when certain properties are used in concert (or on adjacent elements).
• Every browser implements only the subset of CSS they deem “worth it.”
• Users surf the web with browsers at different, arbitrary window sizes; not everyone surfs on a 1024 × 768 monitor with maximized windows.
• Monitors, tablets, phones, and other screen have wildly differing dimensions, color depths and resolutions.

So unless you are going to send every customer an identical computer, and you don’t let them use anything but one browser at full screen, and you prohibit them from calibrating the colors on the monitor, you are not going to ensure that everyone sees the same exact design when they load your web page.

Be Flexible, Be Progressive

From the very beginning, the Web has been about embracing flexibility and variety of experience. So, with that in mind, it’s ok to let go and assume that everyone’s experiences will be different. Of course, we should spend time ensuring everyone’s experience is a positive one. But if someone comes to your site and they happen to be on IE6 and don’t see rounded corners on your buttons, would it be a crime? Chances are they won’t even know they’re missing something.

Your solution of CSS for rounded corners is by far the best approach. It is a progressive enhancement to the page and will not cause errors for users whose browsers don’t implement the CSS border-radius property.

Adding the curvycorners.js helps you achieve design parity in older browsers, but it also penalizes those users by forcing them to download execute extra code just to attain some extra visual flourishes. Would the design’s integrity be lost without the curves? Doubtful.

And your co-worker’s solution, while a tried-and-true approach in early days of the web, has not been considered a good approach for the better part of a decade. The reasons?

• Extra markup is required to achieve the effect, increasing the size of your page.
• Extra images are required to achieve the effect, increasing the size of your page and introducing several extra HTTP requests.
• Additional design time is required to create and slice up said images.
• Maintainability suffers because if you ever want to change the display of the box (e.g. adjusting the radius of the corners, swapping background colors, adding a drop shadow) you have to create all new assets and update the styles.
• If you ever decide to drop the old-school rounded corners, you are left with ridiculously nested div elements around much of your content and (while it does no real harm) it is extra cruft polluting your markup until someone manually removes it.

With CSS border-radius you avoid all of this and can control everything in one spot. It just makes sense.