[whatwg] Embedding images within editable content

Tab Atkins Jr. wrote:
> On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins <mart at degeneration.co.uk> wrote:
>> However, I'm not sure what the solution is here. If contentEditable was a
>> "real" form widget you could imagine it supporting a multipart/form-data
>> upload of all of its contained images, or something. However, as long as
>> client-side code is manually shifting the data to and from real widgets it's
>> not clear how to do this since you can't just create a file-upload control
>> with the filename pre-populated and submit it transparently.
> 
> You can't create a file input with the filename pre-filled for obvious
> security reasons, but you *can* still do some clever stuff here.  In
> order to add a picture you'll probably need them to go through a file
> dialog anyway to select the picture, and you can make this *actually*
> be the file dialog of a hidden file input.  You can then move this
> input around in the DOM without clearing its value, and submit it
> transparently.
> 
> It's a bit hacky, but hey, web security is Serious Business.
> 

This is indeed the solution I employed in a webapp I developed some time 
ago. The main irritation with it was that I needed to submit the image 
to the server before it could be displayed in the WYSIWYG view, which 
required considerable hoop-jumping to put the image in a transient 
location that would eventually be cleaned up if the user didn't actually 
end up using the image on the page, or didn't save the page at all. It 
also didn't work in the copy-paste case, though admittedly in that 
situation we usually just ended up linking to off-site images rather 
than file: URLs, since the copy-pasting was from other websites.

In an ideal world, the content and all embedded media would be submitted 
together in the ultimate form submission. One approach would be to use 
multipart/form-data and have the browser act as if the images were in 
file upload form widgets, and another approach suggested by another 
poster was to include the image using a data: URL. In both cases I would 
still want to do some server-side work after submission to extract the 
images and store them separately, but at least the user experience 
matches the expectation that the image is part of the document.

Of course, neither of these approaches have particularly great fallback 
behavior. The data: URL approach looks the most promising, but apps that 
are not written with that in mind will presumably end up serving the 
content with data: URLs and confusing downlevel browsers. At least it'll 
do something sensible in modern browsers, though, while still making the 
images available for extraction server-side if desired.

Received on Monday, 22 December 2008 13:18:00 UTC