There are countless advantages to building sites in this way, but arguably the most compelling reason is the ability to share one layout across both desktop and mobile browsers. However, if you’re new to mobile development there are a couple of tricks you’ll need to use in order to make this work. It wasn’t really in the scope of Marcotte’s article to cover the mobile-specific aspects of his technique, so I figured a quick post was in order to fill in the gaps.

The example site we’ll be looking at is a hypothetical site for foodies called Fork’d. When you look at it in a normal sized desktop browser, It’s got a vertical navigation list and three columns of content. If you resize the window to be a fair bit narrower, you’ll see that the floats disappear, and the navigation as well as all of the content is lined up in a single column. This is the layout we want our mobile users to see. However, what they’re actually going to see is this:

Fortunately, we just need a tiny sprinkling of pixie dust to make this work the way we expect it to. We’ll just add this meta tag to our page:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

(For way more info on viewports, check out Apple’s documentation on the subject.)

Once we put that in place, the Fork’d site renders like this:

Perfect! We now have one layout that works across different desktop screen resolutions as well as (high-end) mobile devices, and the only extra trick we had to employ was to add a single meta tag.

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.

At the lumbering behemoth of a company where I’m currently doing some contract work, all of the machines run IE6, and I can’t imagine that the IT group here is going to push an upgrade any time soon. Further, I don’t think it’s a stretch to say that there are scores of companies out there, from the very big to the very small, that are similarly unlikely to upgrade anytime soon.

As you can probably guess, the point of these queries & speculations is that I’m really starting to wonder if the web development community will ever be able to stop supporting IE6. Of course the answer has to be “yes, at some point” but when? It’s only been a year since IE7 shipped, and I’m guessing that there are still more folks out there using IE6 than IE7. Although I can’t find any numbers about the IE6 vs IE7 market share, W3schools has a breakdown of their site’s users that shows more people using IE6 than IE7, and if the web savvy still skew that way, it seems safe to assume that the general population does as well.

I don’t have a good answer for that question (if you do, I’m all ears), but it’s worth thinking about. I’m all for pushing ahead and creating new standards (CSS 3? ECMAScript 4? HTML 5? w00t!), but if there’s never going be a widely used browser that’s going to implement them (to say nothing of implementing them correctly), then isn’t it all just navelgazing?

Of course, as I type this, I can hear one of the formerly devout IE people near my cube explain to someone how the Firefox Wed Developer Toolbar “can really make your life easier.” Maybe there’s hope after all.

Postscript: The Wiki page about the history of IE mentions a rumor that a pre-alpha IE8 has been circulating on P2P networks. That pretty much has to be false, right? I’m sure the IE team will try their darndest to ship IE8 sometime before 2013, but I’m willing to bet they’re more focused on coming up with new and different ways to mangle web-standards bug-fixes than getting another version out the door.