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

Hi Stephanie,

 

I appreciate your input on this topic, but I'm afraid I don't agree with some of the arguments you put forward regarding workflow. Of course, the real question was about the use of multi-part mixed, so perhaps we're drifting off topic.

 

It's quite easy to generate a "contact sheet" of images from a large folder of images (or a database of image blobs, if that's the storage mechanism you use). With the right metadata, you can even arrange these images according to 'purpose', 'target' or any other attribute you care to mention. This is far more flexible than having the images confined to a small number of big image files. You can even use such contact sheets as part of your sign-off, if that makes it easier for you to deal with the stakeholders. Basically, you need better image management tools, not an image file packing scheme.

 

Even if you can show that multiple images in a single file have a performance benefit for mobile content delivery, you can easily derive these files from the collection of individual images. It's a process that's easily automated. Furthermore, if you subsequently discover that certain devices in certain circumstances perform better with a larger/smaller number of multi-image files, you can generate these individually from the master images, and this would make your mobile content solution even better. Again, this is all automated.

 

However, in the context of this mailing list, the important thing is whether or not the practice of image "sheets" has sufficient benefit for mobile content delivery, and sufficient stable/interoperable support among the mobile devices in use to warrant being called a best practice and thus recommended to the community. It could be that this practice only has benefits when confined to certain use cases and/or certain device categories, which is OK if that's the space in which you are interested.

 

We've found it better to concentrate on the site flow and layout, encouraging proper use of caching, confining graphics to clear functional uses, keeping things simple and focussed. However, we accept that there are niche spaces and cool corners of the mobile world where curvy graphics and slick moves have a heightened importance, so maybe there you'll find sprites and other eye-candy techniques could be considered BPs. Or it could all go the way of the <blink> tag...

 

Still, it's interesting to hear of the technique working successfully and being useful for someone.

 

---Rotan.

 

 

 

From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Stephanie Rieger
Sent: 10 June 2009 10:40
To: Adam Connors
Cc: Eduardo Casais; public-bpwg@w3.org
Subject: 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