[whatwg] The Rapidly Approaching Dawn of data uri

Charles Pritchard chuck at jumis.com
Sun May 2 21:58:26 PDT 2010

Hello All,

Though this is more of an implementers discussion, it certainly has a place
amongst developers (users).

I've come to see that data-uri embedded resources will grow as a practice.
They're just plain handy. More, the Canvas standard really expands their 

At present, it's quite difficult to get the binary code for a jpg image; 
you must
first draw it to a Canvas and export it as a png. XmlHttpRequest with binary
support makes this a little easier -- but you still must run a 
window.btoa call,
something generally unsupported and prone to failure.

The localStorage API allows us to save dynamic image resources in a web 
when they're not included by the applicationCache manifest. Again, we 
see data-uri
images coming into use.

And this is where my implementers note becomes distressing:

Currently, we're all copying these large binary objects as base64 strings.
There's nothing wrong with base64, but why in the world do we have so many
unnecessary memory copies?

I don't expect that DOMDataUri will become a primitive, but I do suggest
a closer look at the state of things.

With an opaque object, one which does have a simple toString() matching
current data-uri/base64 features, we could cut down tremendously on memory
copies and memory/disk usage.

The Blob API is very much intended to solve some of these issues, but I 
think that we need an intermediate step, to solve these issues prior to 

DOMDataUri {
  string toString, // returns a encoded in the current StringFormat setting.
  bool noPrefix, // skip the data:mime/type,encoding prefix when 
returning toString.
  string mime,
  string encoding

Something along those lines will allow some easy optimizations to our
current data uri/base64 string handling. Mainly, we won't need so many
data copies. But, as well, it could provide an easy transition to Blob 
interfaces in the future.


More information about the whatwg mailing list