Embed Image in HTML

The first Javascript method did not seem to work in either Firefox or IE, or I might just be implementing it wrong. Anyhow, I would not suggest using such a method currently. The browsers are not well designed to handle these changes yet. Who knows? Perhaps in the next release of Firefox or in IE7, things will be in a better light!

The first method is definitely a clean solution, but it's not worth implementing anything if I there's no solution that works in Internet Explorer.  I may have to resign to waiting for IE 7.

I presume that binding an image will only set its url, not the actual data?

> http://www.bennherrera.com/EmbeddedImage/
Geez louise... Those are TABLES!!!
That's quite interesting.

that they are ... a rather simple implmentation but it works (and in i.e.) :)

anyway you do it, its a bad idea for anything more than 64x64 MAYBE 128x128 as it absolutly kills your throughput.

Greg

This idea is indeed a highly creative one and effectively deals with the browser limitations in Internet Explorer--the first solution I've encountered that even begins to work in IE.  The problem of throughput is a cost that is inherent with embedding binary data in a text transport.

The biggest problem with this solution is that, from the standpoint of a user, it does not feel like an authentic solution.  Here's why:

-A printable 256x256 image takes anywhere from 200ms-750ms to render.  Internet Explorer hangs during this time, and makes the site seem slow.
-The user cannot right-click on the image to save a copy.
-Copying out the image to the clipboard and pasting it into an application such as Microsoft Word is very slow, and of course, Microsoft Word does not come close to rendering this as an image.

These problems could perhaps be overcome by:

-Optimizing the image rendering.  I am unsure how document.write calls into an IFRAME compares with DOM generation.  If I recall correctly, the latter is somewhat slow in most browsers, especially when used extensively.  I'm curious how document.write would perform when rendering an image with particularly succinct HTML.
-The right-click could be disabled, and a link could be added to the page that would allow the user to download the image through a separate request to the server.  (The purpose of this embedded image, as I pointed out earlier, is to lessen the burden of statefulness by the server.  The user would need to wait 20-30 seconds for the server to generate the image when saving to the hard-drive.)
-The document could be laid out in such a way that, with some JavaScript coding, the user would be unable to select the image.  (Obviously this would have to happen at a lower level than mere mouse clicks.)

Then, I would end up with a generic DHTML/JavaScript control that would look and feel very much like a flash control.

In summary, this is a very interesting idea and may merit points not because it is a solution that performs particularly well, but because it is a solution that performs at all.

Having written an essay about the table approach, I would like to offer two counter solutions that I thought of, not because I believe they're the ideal solution, but because I believe a critique must follow up with constructive feedback.

My first idea is quite simple: the server could have a custom script that would receive the contents of the image in the query string (if IE indeed allows URLs that long; otherwise, in the POST data), and return it as an image.  Yes, this does mean that the image content is transferred three times--twice in a text-friendly format (perhaps base36 encoded or some other proprietary format) and once in a binary format.

My second idea is similar, although I'm not exactly sure of the implementation details.  Essentially, the src of the image could contain the base64-encoded version of the image, and the low-res url could contain a path to the lengthy server-side process that regenerates the image.  Presumably IE would not recognize the first and would request the image from the second URL.  All other browsers would render the image immediately.

Here's yet a twist on these ideas:  The HTML page containing the image could include a global JavaScript variable including the base64 encoded data.  In IE, the script would write out an image with a url for either the give-me-an-image-for-this-data script (idea 1) or the lengthy server-side process (idea 2).  For all other browsers, it would simple write out an image tag with the base64 encoded data in the src tag.

The problem with these ideas is that it penalizes users for browsing with IE.  This is a controversial subject, of course, but given the large target audience of IE users, I believe it's a fairly large strike against the ideas.

If the problem cannot be satisfactorily solved client-side (which I hate to say is true, but might be), the only option is beefing up the servers.  I cannot pre-emptively generate my HTML page, because the server process needs to display a status.  The obvious server-side solution is optimizing the server application until the image can be generated through its own URL/entrypoint.  At that point, the HTML page can be generated either pre-emptively or using the same backend server process.  Perhaps that's what everyone else has been doing up till now.  Still, that's a lot of work, and I believe there would be a good bit of potential in well-designed embedded images.

As a final thought (as I mentioned before) the accepted solution ay not merit points not because it is a solution that performs particularly well, but because it is a solution that performs at all.  The best solution is to wait for the IE7 beta and explore the possibilities there.