Re: Comments about the limitations of Data URIs and why I believe you should avoid them

On 12/23/2010 03:05 PM, Ronny Orbach wrote:
> Hi everyone,
> I was bummed to see I've missed the publication of the "Mobile Web Application Best Practices" document in a week - I have strong opinions about the matter and I think the clause about the matter in the spec is problematic as it isn't clear enough about the drawbacks of the technique.
>
> Here's an English version of my post on the matter. I'd love any feedback: http://frontend.co.il/avoid-data-uris-en/

Hi Ronny,

Thanks for sharing your comments!

I don't think we disagree in terms of data URIs cons. The short best practice description in the specification is precisely meant to alert authors about these limitations. I guess the only disagreement is on the conclusion as the Mobile Web Best Practices working group still thinks that data URIs should be considered when developing mobile Web applications. Please note that, as opposed to the first set of Mobile Web Best Practices, the Mobile Web Application Best Practices are not meant to be applied on a systematic basis. On top of the drawbacks (that the spec tries to document), some best practices also require skills  that may be regarded as "advanced" depending on one's background, and the spec leaves it up to Web authors to evaluate whether the practice is easy to implement or not in their view.

Here are short comments to each of your points. These are my opinions, other participants in the working group may have other views...


> IE 6 and 7 doesn't support the Data URI scheme at all. We're talking images here, not rounded corners – You have to support it, which means you should use the Microsoft proprietry MHTML (presented with IE5.5 in '99), but then code weight is more than doubled.

True. It's also relatively easy to find not-so-old mobile Web browsers that don't support the scheme. That's the reason why the "Requires RFC2397 data uri support" note got added. If data URIs are only used for "visual effects" (purely decorative images), not rendering them in some Web browsers may still be acceptable. If not, well, they should not be used!


> Even without MHTML, Data-URI images weigh around %36 more than PNG. GZipping the text makes it about %6 more, but it's still something.

That's what the spec tries to capture in the second paragraph. An HTTP request/response is something, too. For very small images (say 1 or 2KB), the overhead is of the same order of magnitude as the HTTP header that comes with a separate HTTP response, or it can be acceptable as opposed to having to send yet another network exchange in a low latency mobile network.


> There's an extra step to build a webpage, and if you want it to be remotely maintainable you'll add comments referring to the original image, which should be stored somewhere.

I think the comment applies to other best practices as well. Most optimization-oriented practices (e.g. Javascript compression, fingerprinting, sprites) are hard to implement manually. They kind of require developers to maintain a "build" process. This build process could remove comments, useless spaces, turn images into sprites or data URIs where appropriate, and so on. It is neither hard nor easy to achieve.


> Images always download, unlike referenced images in CSS declarations which doesn't apply on a given page. Go ahead, try it.

Small decorative images used in the theme used throughout a Web site are good candidates for the technique. Images that only appear in a handful of Web pages are definitely not good candidates. The same comment would apply for sprites: embedding images that don't appear on all Web pages in a sprite that gets downloaded with each and every Web page is not that a good idea.


> Images aren't cached separately, so embedding in HTML doesn't cache at all, and embedding in CSS means any change you do to the CSS invalidates all embedded images' cache.

True. Equally, many Web authors only update the style sheets of their Web site from time to time once deployed.


> You might be thinking now "That's not a problem, I'll combine groups of related image in dedicated external stylesheet, i.e. header-sprite.css". Congrats, you've just reached image sprites with 10 more limitations.

I'm not sure I understand the "10 more limitations". Image sprites, which are also listed as a best practice, do not strike me as trivial to put into practice either!


> CSS blocks download, unlike images, so you don't want to bloat it too much.

True.


> IE8 can't handle Data URIs over 32KB, so that rules out content images

Last time I checked, the limit for Opera was much lower than that (4KB). Content images are ruled out in any case because you should use proper <img> tags there. The spec could perhaps have been more explicit about the fact that it's not a good idea to use that technique to medium-to-large images.


> Maintaining sprites is still more natural and easy – Who misses image slicing?

Is it? I have been following students that were learning mobile Web techniques and I'd say it really depends on individuals. It's obvious for some people, and hard for others. I personally find both techniques to be equally hard.

> These URIs are damn ugly. Even in Firebug, even in wide screens, they are human-unreadable, create terribly long lines and just makes their hosting files dirty.

Right. Again, I think most optimization techniques create obfuscation and should be applied at the end of the development chain, in as automated a way as possible to ease maintenance.

Thanks,
Francois.

Received on Monday, 3 January 2011 11:08:07 UTC