Tab Atkins Jr. wrote:
On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins <m...@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.
