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

Hi Adam,
Let me get back to you on questions 2 and 3. While our tests were by  
no means exhaustive we did make use of some simple utilities which had  
been built into a series of widgets for easy install and dissemination  
during testing. I'm not sure however if we can release these to the  
general public so need to check with my client first.

To answer your first question, this may seem a bit arcane and geeky  
but when working on large sites, with multiple teams and/or on long- 
term projects that require lots of maintenance, sprite sheets can help  
workflow in a bunch of ways. Firstly, you always know where the  
graphics files are because there are limited numbers of them vs the  
often huge folders of disparate graphics that result from the use of  
single images.

Whether you're actually implementing one great big sprite sheet or sub- 
collections of smaller ones, the whole lot can be housed in one  
graphics file then sliced up using native slicing tools enabling you  
to export any number of sprites as needed.

Re-skinning or making site-wide changes can also be much easier both  
from a visual point of view (checking the consistency of 30 sprites on  
one big page is far easier than trying to cross-check 30 separate  
images), and a workflow point of view (search and replace in most  
graphics tools can re-skin a whole site in minutes). It's also quite  
useful when obtaining sign-off from stakeholders as once again, you  
provide one big graphic which gives brand teams an excellent overall  
view of look and feel and adherence to guidelines.

Will try to provide more input on the other items by the end of the  
week.

Regards,

Stephanie


On 9 Jun 2009, at 15:03, Adam Connors wrote:

> Hi Stephanie,
>
> Thanks for that incredibly useful feedback. Your experiences tally  
> well with my own and as you say it is extremely helpful to collate a  
> good number of real-world experiences. Couple of further  
> clarifications / questions if that's okay:
>
> 1. Can you explain to me what you mean by "helping workflow" ? I'm  
> not quite clear on how css sprites help here ?
>
> 2. I'm very interested in your comments on how you decided to  
> partition your sheets, trading off how many images to place on a  
> single sheet. If you have some numbers / experiments to hand that  
> can demonstrate the trade off and how to optimize latency that would  
> be very helpful.
>
> 3. Do you have any measures / samples that indicate the latency  
> saving you see over mobile networks, and / or memory usage on target  
> devices ? Or if not, any code snippets that we could use as a  
> starting point to create some samples ?
>
> 3. Have you any experience with using css spriting with off-line  
> technologies (e.g. appcache). Is it still useful in this context?  
> (My suspicion is that it is since an appcache reload happens in the  
> background while the app is loading and can still impact latency,  
> but I have no concrete numbers in this area).
>
> Many thanks,
>
> Adam.
>
> On Wed, Jun 3, 2009 at 12:42 PM, Stephanie Rieger <steph@yiibu.com>  
> wrote:
> 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
>
>
>
>
>
>
>
>
>

Stephanie Rieger

http://yiibu.com
Yiibu: lovingly crafted mobile experiences
+44 (0) 7957 651 177

Twitter: stephanierieger