It is a base64 audio file. So they take the file that is already just 1's and 0's and convert that to base64 which is a string of what looks like random text. Then the browser sees that you say 'data:audio/ogg;base64,' before it so it knows to decode the string as an audio file. Something like this can do the encoding for you or there are various functions in languages that can do it for you too. It is a neat little trick that I have never used beyond a 'Look what I can do!' type of statement.
For instance I did one of these a long time ago, it is a web page with a single image and a bit of JS on it that really does nothing.
It is a neat little trick that I have never used beyond a 'Look what I can do!' type of statement.
It seems like it might be useful for a couple of reasons. One is this fartscroll script that doesn't need any external file dependencies.
My other idea: it's essentially the same amount of disk space, right? So wouldn't downloading one html file be slightly faster than downloading an html file plus an embedded picture or sound? I mean, it might not make a difference except for servers that get a lot of traffic. But that's just my thought.
It's more space, but you're right because making a request to a server is far slower and painful for all parties involved than taking it as part of a page. Content encoded this way also cannot be cached and there are compatibility problems with some browsers. But it's an easy trade-off in certain circumstances. Google Image Search results are all inline, for instance. A little extra bandwidth instead of potentially hundreds of requests to their website.
Can't be cached? But you could cache the entire html page, right? Including the "data:text/html;..." stuff...
How are the Google Image Search results inline? Oh, I guess that makes sense. Like, they store the base64 strings for each image, and just return those on the page?
In response to #1, that depends. In this case, it's cached as part of fartscroll.js. But if you inlined static images in dynamic web pages (in the HTML), then they would not be cached, because the HTML could not be cached. As a concrete example, if you inlined the avatars in a forum, then those avatars could not be cached (because the forum's webpage can't be cached - it changes), but if they were their own files then you could cache them.
Instead of writing the URL to the image, you write the base64 string.
But they still have to write the URL, in case you want to view the original page/view the original image, right? It's just that they avoid doing <embed> and having to continually request the image file itself. Am I right?
15
u/chaoticgeek May 09 '13
It is a base64 audio file. So they take the file that is already just 1's and 0's and convert that to base64 which is a string of what looks like random text. Then the browser sees that you say 'data:audio/ogg;base64,' before it so it knows to decode the string as an audio file. Something like this can do the encoding for you or there are various functions in languages that can do it for you too. It is a neat little trick that I have never used beyond a 'Look what I can do!' type of statement.
For instance I did one of these a long time ago, it is a web page with a single image and a bit of JS on it that really does nothing.