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

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
>>
>>
>>
>>
>>
>>
>
>
>