ASP.NET MVC CSS Sprite

A month ago, I wrote about my technique to output a CSS sprite for ASP.NET. Granted, I made a big mistake. I put WAY too much bloat into the post. Not a K.I.S.S. moment.

I have reworked my CSS sprite technique to be unique to MVC. I've used the most recent build of the MVC framework, which can be downloaded on Codeplex, to take advantage of ActionResult. What the ActionResult does is makes your controllers more testable and makes the execution of the controller more specific. Instead of a void, controllers now return an ActionResult (see Scott Guthrie's post on the interim release).

I have a download, see the bottom of the post, that includes a sample application and a class library that you can distribute with any MVC application. The sample pulls 2 images off the Internet, plugs them into a sprite through the Sprite controller.

image

 

What you get when you execute the Sprite controller is a sprite that looks like so:

image

 

What you do in your CSS file is reference the sprite URL and specify the background-position, width, and height.

image

 

Then with the following HTML:

image

you get the images separate from the sprite.

image

What you get is an easy-to-use API for sprite generation and faster-loading website (less HTTP requests per page) using sprites instead of multiple images. If you want all of the CSS editing to happen at runtime, see my original post of CSS Sprites for that code.

DOWNLOAD SAMPLE APPLICATION AND CODE




kick it on DotNetKicks.com

6 Comments

  • By using this method the browser needs to do the cutting, do you happen the know what is the speed/load difference on the browser when using this method?

  • @markvt I do know that HTTP requests drop exponentially... most websites have 10+ images and with this solution you only need 1. I think the "cutting time" depends on the browser's CSS efficiency. Usually, this is pretty high and the cost to your users rarely suffers.

  • There's really no "cutting" time to worry about. The browser is displaying the entire image in each instance, but shifting the visible area by your specified amounts. Any extra time that might take is orders of magnitude faster than even a single extra HTTP request.

    It's best practice to leave a bit of spacing between the images though. Due to CSS rendering differences between browsers, it's very easy to end up with elements that are slightly larger than you expected. If your images have no spacing in the sprite, you'll end up with unsightly bleeding.

  • @gt1329a You make a good point that the image is rendered in every place it is used. However, for the initial time for the site to come down from HTTP there is a significant performance boost since you are loading only 1 file. And on typical browsers, it is faster for the CSS parser and formater than extra downloads.

    Can you detail the spacing issue... maybe with an example? I can see how this would be beneficial... but I am unsure as to the error.

  • Just how hard do you reckon moving existing images to this technique would be?

  • @acyment

    Are you talking about the images themselves or HTML/CSS? If you are talking about the images themselves, they can reside in both the sprite (since it is generated when your application starts up) and on the file for use independent of the Sprite.

    If you are talking about the references to the images in HTML or CSS, that all depends on your application.

Comments have been disabled for this content.