Even More Rounded Corners With CSS

(Another technique for the pile.)

2009 update: CSS 3 and border-radius can do rounded corners without any images, and support for RGB/alpha opacity and gradients with opacity is also on the way. Check out CSS 3 and the future for newer, shinier examples!

There's an increasing desire (at time of writing, February 2007) to provide rounded corner dialogs with various visual effects. Based on the original More Rounded Corners With CSS, this update reduces the background to a single "sprite", retaining the alpha transparency benefits of PNG without bloating the markup required to produce the same effect. The end result is something which should allow for further customization.

Features:

  • CSS-only, no Javascript
  • Fluid layout, width/height (up to full image dimensions)
  • Single PNG image
  • PNG alpha transparency - corners, borders, drop shadows, inner gradients etc.
  • Standard Module Format-based content markup (SMF approach thanks to Nate Koechley) - see also, "It's Not Divitis" (2)
  • Degradation to GIF (or 8-bit PNG) for IE 6

Basic Exampless

See this Basic Rounded Corner CSS example.

Download

Download examples - Includes this demo page, basic examples, images and PSD dialog templates (use layer effects + color fill to customize)

Credits

About

Scott Schiller (contact) is a Front-end Engineer (previously "Web Developer") who builds fun creative and technical stuff on the web - or failing that, tries - when he has free time. He likes building cool things which contribute to, yet enjoys mocking, the Web 2.0 meme. (See How Web 2.0-Aware Are You?)

Notes + Observations

Performance, efficiency, limitations and so on

This rounded corner technique may not be appropriate for some uses.

PNG file size trade-off

Because this single-image technique uses PNGs which employ a deflate (ZIP)-style compression method, they can compress better than GIF, but generally not as well as JPEG (it is non-lossy unlike JPEG, however.) Nonetheless, file size will generally grow with the relative "complexity" of the image and its dimensions (gradients and patterns for example will likely not compress as well as flat colours.)

Images nearing 800x600 can be 6 KB, whereas 1600x1200 can be 16 KB. The blue background on this element (excluding IE 6), is 800x1600 and is 10.7 KB. It appears compression is far more efficient on the vertical axis, but it may be worthwhile to experiment with different dimensions and patterns to optimize file size.

It is also worthwhile to note that the demo images may not be well-optimized, and are also relatively complex as they use drop shadows, unique ("drip style") elements and gradients. I have not fully investigated this area yet.

Some PNG "crunching" utilies are available which can help to get the file size down as well, post-export from an editor like the GIMP or Photoshop. These work by removing excess gamma data and other channel information, as far as I understand. PNGCrunch is one such example.

Alpha transparency vs. render performance

It is assumed that alpha transparency affects rendering performance within the browser relating to rendering, scrolling, resizing and animation (dynamic updating) of content. Swapping GIFs for PNGs for example may provide improved performance, though lack certain features such as alpha transparency. Large areas of opacity may render more slowly than smaller ones (alpha corners vs. entire PNG being partially translucent, for example), but this has not been tested.

To test animation performance (excluding IE 6), double-click inside a dialog's content area. Speed may vary widely depending on browser window size and other variables. The native OS browsers (IE on Windows, Safari on Mac OS X) appear to handle this far better than others.

Single Image?

After some tinkering, I stuck to a single BAI because it seems to offer a fairly flexible way to accommodate various design styles such as gradients without excessive image weight. The potential downside is the limitation on height due to file size, and since there is no tiling, the desire to avoid scrolling. Changing the BAI to a tiling sprite format would also require a markup structure different from this approach. In short, "use what works."

Technique

The nitty gritty.

Given the use of alpha transparency throughout, elements with background images may not overlap. Therefore, a few hook elements and positioning are used to provide the required "slices" which make a complete, fluid image.

Markup Structure

Here is the base markup required for this format:

<div class="dialog">
 <div class="content">
  <div class="t"></div>
  <!-- Your content goes here -->
 </div>
 <div class="b"><div></div></div>
</div>

Here is a more-complete variant using Standard Module Format, nicely-formatted and with comments:

<div class="dialog">

 <!-- top/right PNG -->
 <div class="content">

  <!-- optional: vertical scroll wrapper -->
  <div class="wrapper">

   <!-- top/left PNG -->
   <div class="t"></div>

   <!-- Your content goes here -->

   <!-- Optional: Standard Module Format (hd/bd/ft)
   for providing semantic, meaningful content.
   Not required for visual effect. -->

   <div class="hd">
    <h1>Technique</h1>
    <h2>The nitty gritty.</h2>
   </div>

   <div class="bd">
    <p>Given the use of alpha transparency...</p>
   </div>

   <div class="ft">
    <p>This is where the footer goes.</p>
   </div>

  <!-- end content -->
  </div>

 <!-- end scroll wrapper -->
 </div>

 <!-- bottom PNG -->
 <div class="b"><div></div></div>

<!-- end dialog -->
</div>

The use of SMF here is optional, but recommended. The dialog CSS does not require it. If minimizing the code is a must, it can be omitted and the fluid dialog layout should still apply. However, left margins may need to be applied to bump the content on the content container used (eg. a single DIV.)