For far too long, web designers have had to deal with a lack of real-world design tools in CSS. In their place, we’ve used kludgy HTML, images, and even JavaScript to accomplish basic visual treatments such as transparency, shadows, gradients, and, yes, rounded corners. Every solution using this old toolset calls for an uneasy compromise of appearance vs. semantic markup vs. development time vs. file count/size.

Why can’t we just ask the browser to provide a 5px radius in CSS in whatever color/width/shape we want and get on with our day? We can.

Welcome Border Radius

Firefox has supported a border radius property for some time now (-moz-border-radius) and Safari recently came out with their own experimental syntax (-webkit-border-radius). Furthermore, the CSS Working Group recently announced some pretty robust support for the border-radius property which means the usually standards-leading Opera should be getting around to roundness soon as well.

Using border-radius today provides nice, rounded corners and shaves a ton of development time (no more round-trips to the image editor or nesting HTML for flexible dimension boxes).

The problem, of course, is that 70% gorilla in the corner. So, what about IE? The yet-to-be-released IE8 is finally getting things right with CSS2.1 (a good thing) and moving their proprietary properties into -ms- vendor specific extensions (also a worthy effort). Yet it doesn’t look as though the IE team will be tackling border-radius until IE9 (2 years?).

Progressive Visual Enhancement

So at this point we have two options when it comes to going all CSS on rounded corners: we can whine and cry about how IE sucks (been done already) and wait for IE to get around to border-radius or we can take progressive enhancement to the next level.

Let’s take the latter route. Starting today, let’s throw out all the crappy, nested HTML; the countless, un-scalable images; and the overly-complicated JavaScript work-arounds. Let’s start fresh…

1. Lay a foundation of basic borders—square, un-adorned, solid borders. Every browser shall see squared edges by default. No problemo.
2. Then throw in some rounded corners for Firefox and Safari and anyone else that’d like to join the party. Kewl.
3. Lastly, add a dash of gradient to Safari as prescribed in Shiny Happy Buttons. Brilliant!

Sweet. No one gets hurt, the cool kids get the nicest looking stuff, and those squares that want to join the cool kids just have to download a free browser. What could be better?

One irritation defied all my attempts to resolve: disabling CSS via the Web Developer Extension’s long-standing keyboard shortcut CMD-SHIFT-S. Apparently the Mozilla team decided to Shanghai that shortcut for their History Sidebar. Why?

No matter. Today I found my solution in Keyconfig for Firefox 3. Now I can create, edit, or disable existing any FF3 shortcut I wish. Buhbye, History Sidebar!

Web development on a Mac is pure joy. There are so many tools that just that make building websites simple and even fun. From the dead-simple MAMP web server setup to the deceptively powerful TextMate editor to the game-changing Firefox browser-cum-editor/tester (with the essential Web Developer, FireBug, and ySlow extensions), it’s all good in Mac land.

And since Mac went Intel, we can develop like crazed bunnies and test our work in each nasty little flavor of Internet Explorer running in separate virtual Windows environments. Granted, it took a bit of Googling on my part to find out how to point Windows browsers to MAMP. But the two primary solutions are fairly straight forward and work in most cases:

1. use the Mac’s IP address (e.g., 192.168.2.2:8888)
2. create and use a hostname
   1. open the C:\WINDOWS\system32\drivers\etc\hosts file (in Notepad)
   2. add a line to the bottom with the Mac’s IP address and desired hostname (e.g., 192.168.2.2 mamp) and save
   3. use that hostname (e.g., http://mamp:8888)

In most cases? Yep. Everything runs fine so long as your apps don’t reference MAMP’s default webserver name, localhost:8888. Of course, the popular apps such as ExpressionEngine and WordPress do need a base URI—and localhost:8888 is it.

Bugger. Windows has it’s own localhost quite separate from Mac’s and neither the two shall meet. Accessing MAMP’s localhost just isn’t going to happen with Windows’ localhost listening in and intercepting. The only solution is to set up a hostname other than localhost on the Mac side and enter that same name in the Windows host config file.

The gritty, command-line way of changing MAMP’s hostname from localhost is to make some changes to its httpd.conf file and to muck with dscl (Apple’s NetInfo replacement). Feel free to Google the specifics, but I personally don’t want to have to fire up Terminal every time I want to change to another site. Thank goodness for VirtualHostX.

My new pal, VirtualHostX, allows me to create different virtual host names for all my projects. So rather than using the localhost URI, I can create meaningful URI’s such as newproject.dev and anotherproject.dev with impunity (which makes it superior to the Headdress method of merely assigning new port numbers to localhost). VirtualHostX makes all the changes behind the scenes and even backs up the default settings before making those changes. Sweet!

We’ve almost achieved web developer inner-peace… but we need to make one more stop. Let’s remove that crufty port 8888 bizness (e.g., localhost:8888, myproject.dev:8888). By default, MAMP uses port 8888 to avoid conflicts with OS X’s built-in web server (which listens to the http default port 80). Since I have no immediate intentions of using OS X’s built-in server, I immediately changed MAMP’s default port setting to good ole port 80. From here on out, just enter myproject.dev in any Mac browser and go. Yay. Nirvana.

Now, back to the Windows side. After adding myproject.dev to the Windows host file (e.g., 192.168.2.2 myproject.dev), fire up your Windows browser of choice, point it to myproject.dev, and Shazam! Everything works.