[whatwg] The Rapidly Approaching Dawn of data uri
chuck at jumis.com
Sun May 2 21:58:26 PDT 2010
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;
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
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
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
string toString, // returns a encoded in the current StringFormat setting.
bool noPrefix, // skip the data:mime/type,encoding prefix when
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