W3C home > Mailing lists > Public > public-bpwg@w3.org > June 2009

Re: ACTION-961: usefulness of multipart-mixed [recent mobile CSS sprite case study]

From: Stephanie Rieger <steph@yiibu.com>
Date: Wed, 3 Jun 2009 12:42:13 +0100
Cc: public-bpwg@w3.org
Message-Id: <28C0CAD1-C701-4C13-97B2-09F64F6D9BFE@yiibu.com>
To: Eduardo Casais <casays@yahoo.com>
Hello,
I've just joined the list so have not been privy to the entire  
conversation however have just completed a large mobile web project  
that made extensive use of CSS sprites.

So I thought i'd pass on what we learnt during this project as real- 
world examples on this topic are hard to find...

The primary reason we decided to use sprites was to reduce lag when  
loading rollovers and multi-state graphics. This worked remarkably  
well! We successfully implemented and tested CSS sprites across all  
Nokia WebKit browsers (including the earliest webkit versions and the  
newer S40 webkit devices). After testing RAM consumption with a  
variety of sprite sheets (ie. one large one for the entire web site vs  
various groupings of small ones and executing comparisons of RAM  
consumption when larger or smaller numbers of graphics are 'revealed'  
at a time,) we opted for a collection of small sheets (ie. containing  
on average 2-5 states) rather than one or multiple larger sprite sheets.

 From a workflow point of view, this approach was far preferable to  
single graphics and (with judiciously written CSS) eliminated common  
design discrepancies caused by differences in pixel positioning across  
devices as it allowed us to make extensive use of the 'top' and  
'bottom' x/y positions rather than set a pixel value for each sprite  
state.  It also allowed the grouping of sprites by use-case/task to  
limit the 'accidental' download of graphics that are not actually  
needed during common tasks or flows. Finally, as the sprites were used  
for non-semantically critical elements (hover states, tiled  
backgrounds etc), the need for alt tags was reduced. (In cases where  
search engine friendly text-strings were critical, the sprite would  
typically not have been the sole purveyor of this data anyhow).

FYI - We also tested the entire project on Opera Mini (v4) and found  
that the support to be excellent (i.e. it all worked fine :-)). The  
very same HTML/CSS also worked perfectly on Maemo, desktop Firefox and  
Safari (including the iPhone) so this was not 'Nokia-optimized' markup.

If memory serves from a past projects, pre-webkit Nokia devices (and  
many other devices of that calibre) do not support the necessary CSS  
to make consistent use of sprite sheets. It is worth noting however  
that, when formulating device groupings and design/adaptation rules,  
pre-webkit/less capable devices will most often fall in to a separate  
category anyhow due to their screen size and overall capabilities.  
These devices will most often not share the same design/style sheet  
and will make far more extensive use of native background colours than  
graphics for rollovers, backgrounds etc.

It is therefore plausible to safely use sprites extensively within the  
mid and upper range of your device groupings without necessarily  
compromising design or performance on less capable devices. All this  
should be tempered with a realistic assessment of just how many  
graphics you actually need as it's by no means wise to implement vast  
numbers of graphics on a mobile site.

 From a desktop web best-practice point of view, CSS sprites remain  
quite popular as they are extremely consistent in behaviour (notable  
exception being desktop Opera 6) and are hugely useful from a workflow  
point of view. I would also suggest that in recent years, they may  
have finally moved out of the realm of 'hack' and into that of best  
practice on the desktop.

http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/
(sprite usage examples from Amazon, Google, YoutTube etc.)

Hope this was useful. Feel free to ask for clarification on points if  
needed.

Regards,
Stephanie

On 3 Jun 2009, at 11:45, Eduardo Casais wrote:

>
> I am the one who originally suggested to look at multipart/mixed  
> rather than
> sprites as a mechanism to reduce the number of HTTP transactions,  
> and hence
> overall latency. I try to summarize the discussion so far.
>
>
> 1. SPRITES
>
> They require pre-processing (assembling a composite image and  
> generating CSS
> directives to present the individual images from the composite  
> bitmap).
>
> Because of the absence of the "alt" attribute, sprites are at most  
> only
> suitable for decorative bitmaps, without semantic properties (alt is  
> important
> for accessibility and search engine optimization).
>
> We are not sure the CSS required for sprites is available and  
> implemented
> correctly in a sufficiently large proportion of mobile devices.
>
>
> 2. MULTIPART/MIXED
>
> Is a technique, defined by standards, to encapsulate resources of  
> all types
> (not just images) into one package. There is a MIME type associated  
> to it.
>
> It can be used both at the proxy and at the server (greatest  
> benefits) side..
>
> Availability of implementation varies considerably:
>
> a) Desktop browsers have been generally lacking support for  
> multipart/mixed
> (Firefox and Opera: buggy; Safari entirely absent; IE ok).
>
> b) Mobile browsers require accurate knowledge to avoid delivering  
> content
> that is unrecognized by the device. From what I know, Openwave and  
> Blackberries
> have had fair support for multipart/mixed, jataayu should have it  
> too; Nokia
> was notable in not implementing it in its original mobile browser,  
> and since it
> relies upon Safari/WebKit nowadays, I am not at all surprised at the  
> results of
> Luca's quick test with a N95.
>
> c) It is reasonable to assume that mobile browsers derived from  
> desktop
> technology (i.e. Safari/WebKit, Opera, Ozone) do not support  
> multipart/mixed.
> Information about other major mobile browsers (NetFront, Obigo) or  
> newcomers
> (UCWeb, Bolt, Skyfire, Android) is missing. Maybe representatives of  
> the
> respective companies in the W3C can shed some light onto this.
>
>
> 3. CONCLUDING REMARKS
>
> Sprites appear to be a hack of a restricted scope and of limited  
> interest, not
> really suitable as a best practice.
>
> I share the opinion of Magnus Lönnroth and John Hardi that multipart/ 
> mixed is
> not an obsolete technology, and can really help reduce latency while  
> keeping
> resources of different types separate. However, one must be very  
> knowledgeable
> about the target devices, and hence this is not a technique to apply  
> blindly.
> It seems like a good practice for experts -- whether it is a best  
> practice is
> doubtful.
>
> The fact that there are discussions about how to reduce the number  
> of HTTP
> transactions for one page, whether by bundling resources into one  
> page, using
> sprites or relying upon multipart/mixed, and that some of these  
> approaches
> were developed or proposed in the _wireline_ Internet (and recently  
> at that)
> means that 3G or 3.75G or 4G or whatever, latency remains and will  
> remain an
> important factor when developing mobile services. I wish browser  
> manufacturers
> would keep this in mind and implement standards that help address  
> this problem.
>
>
>
> E.Casais
>
>
>
>
>
Received on Wednesday, 3 June 2009 11:54:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:54 UTC