Archive Category ‘Web Development‘

 
 

An Intro to CSS Sprites

What is it?

CSS Sprites are an interesting method to cut down on both a website’s initial construction phase and the bulkiness of excessive loading time. Instead of creating a separate image file for each graphic used on a website, several can be combined in one with only the appropriate element showing based on specific positions defined in the CSS.

Why Is It Important?

Websites with lots of graphic elements can benefit from the use of sprites on both the developers’ end and the users’ end. It’s definitely a win-win situation when the developer can cut back on the tedious work of image slicing and the users have a faster web page load time. The old train of thought was that by cutting up the images into a bunch of smaller pieces that it would be faster and easier to load. Unfortunately, that was not the case. By creating more files than necessary for a browser to retrieve from the server, it actually creates a longer loading time. CSS sprites also replaces the need for JavaScript rollovers and image preloading – all in all, a very helpful solution.

The Basic Theory

Let’s say that you have a menu of 5 image links that when you hover over each individual button you want the respective image to swap out. The old way would be to create 10 separate images and link to each one. While nothing is technically wrong with this method, that’s 10 separate server requests and lots of image slicing. Let’s see an example button.

In Action

Since this sprite only has two states for one button, when used it is far easier to define the CSS. Something along the lines of the following would work just fine:

<style>
 

#nav a.button {background: url(samplebutton.gif) top; display: block; width: 171px; height:49px}

#nav a.button:hover {background: url(samplebutton.gif) bottom; display: block; width: 171px; height:49px}

</style>

More Explanation

With a more complicated sprite, the theory is just the same. Instead of using the “top” and “bottom” attribute to define the correct positions of the on/off states, you simply have to use more precise positioning. If you’re using a sprite with four images, using “top left”, ” top right”, “bottom left” and “bottom right” will suffice. However, the larger the sprite grows, the more specifics the dimensions will have to be — usually in pixels — to define the position of a sprite that holds more than 4 images. For the example button, using pixels to define the position looks something like the following:

<style>
 

#nav a.button {background: url(samplebutton.gif) 0px 0px; display: block; width: 171px; height:49px}

#nav a.button:hover {background: url(samplebutton.gif) 0px 49px; display: block; width: 171px; height:49px}

</style>

The first positioning attribute defines the x-axis coordinates of the image and the second defines the y-axis coordinates, both from the top left corner. Since both images are 49 pixels tall stacked on top of each other, the second image’s definitions are the same x-axis position but pushed 49 pixels down to call the rollover image in exactly the right spot.

And that’s it! A brief explanation that can take you onto the road of CSS sprite creation so long as your graphing and plotting skills are good.

SXSWi 2011: Highlights from Johnny D

The highlight of my Interactive experience would have to be Bruce Lawson’s presentation on Mobile Optimization with HTML5, CSS3 and JavaScript.

Bruce quickly dismisses the idea of separate webs. He presented the idea that there is no mobile web, there is just one web. Just like there is no desktop web or tablet web. He supports this with reasons why we should think of a more unified web. He says that rather than creating different desktop and mobile sites (which ultimately confusers the end user) why not create responsive web development using CSS. We are able to use CSS to detect properties such as width, height, device-width, device-height, orientation, resolution and color to name a few using CSS3 Media Queries. Using these properties, we enable our browsers to detect the device settings and offer up proper css styles and rules for a better user experience on the web.

Bruce also presented various tips and tricks for a better mobile web experience, which I will run through below:

1. No browser sniffing for the simple reason that over 100 new browsing solutions appear every day and there is no possible way to cover all those solutions.

2. Don’t use tables for layouts. Tables are heavy on CPU and battery usage on mobile devices.

3. Give width and height dimensions in HTML in your image tags 
( i.e. <img src=”/source/” alt=”" width=”xx” height=”xx” />).

This will enable your browser to make room for these images when loading, rather than guessing the size of these images.

4. Use the <a href=”tel:xxx-xxxx”></a> tag for phone numbers.

5. Future proof your CSS. You do not have to limit your prefixes to -moz and -webkit. You can also throw in -o for opera and -ms for IE, and once these properties are available on those browsers your site will already be CSS3 enabled in those browsers. So for instance when setting up the CSS3 transition property:

-moz-transition
-ms-transition
-o-transition
-webkit-transition
transition

6. Minimize HTTP requests to save on CPU and battery power by combining JavaScript into one file and combining CSS into one file. CSS sprite images can also be used to minimize HTTP requests.

7. CSS optimization:
- use ems instead of px for fonts (for browser scalability)
- use fluid layouts (for landscape and portrait mode flexibility)
- turn off fancy shadows and transitions to conserve on CPU and battery power

8. JavaScript optimization:
- put JavaScript files at the bottom of the source file and especially after CSS.
- if you don’t have you use a library (i.e. jQuery), use your own script.

Why does Microsoft hate email designers?

The answer is — nobody really knows.

Not a big surprise, the Email Standards Project gave Outlook 2007 a “poor” rating when it comes to email standards support –  Why Does Microsoft Hate Email Designers?I guess “piss poor” wasn’t an option.   Not only does 07 limit what we as designers can do from a creative standpoint but it creates a lot of angst with our clients who don’t want to pay for the additional time required to properly test and troubleshoot.

To try and (let’s say) “gently pursued” Microsoft to pay a little attention to the glaring frustration, Fix Outlook (http://www.fixoutlook.org), a Twitter mashup campaigning site, has been created with the goal of getting MS to finally hear the screams from voth the world’s designers and client marketing bugdets.  After 20,000 signatures responded to the campaign, Microsoft released a statement that they are going to stay the course.

So, just when you think we might have rounded the corner to safely wave bye-bye to Outlook 2007 in the rear view mirrors velcroed to our monitors (yeah, we have those), Microsoft has decided to stand with their belief that “Word is the best email authoring experience around” — so looks like MS Word will once again be used for rendering emails in Outlook 2010.

According to the Email Standards Project, “For the next five years your email designs will need tables for layout, have no support for CSS like float and position, no background images and lots more.”

Good times. :)