Observe the following:
http://granite.sru.edu/~ddailey/svg/clipembed.html
In IE 4 - 7 (with the Adobe SVG plugin enabled), the end user can select an
image from her own hard drive using a file upload.
In IE 4, I had a similar thing (sans SVG) that worked also in Netscape. It
doesn't work in the other (more standards compliant?) browsers though, and
folks have cited the "obvious security reasons".
I had complained a year or two ago here that the spec no longer seemed to
enable this. I recall someone becoming quite indignant that an author would
even WANT to allow users to have access to images. The reason for the
security concern as well as the indignation eluded me, and the security
seems not to be SO terrible, I thought, if old Netscape and comparatively
new IE7 still allowed me to do it.
The ability of the browser to be able to support user-selected image content
(without making a roundtrip to the server which to me seems like a bigger
security risk than having local images displayed and manipulated ) seems to
be at the core essence of what I would define as "web hypertext
applications".
Hixie, responded to this thread a year or so ago, with supportive remarks
(that I confess I didn't totally understand) saying that it looked as though
there would be a way to do this through some mechanism that I gathered was
outside the scope of WHATWG or HTML5.
While we're on the subject, I would really like to be able to read pixel
values from local images by plugging them into (as through a input
type=file) a <canvas>. Having access to pixel values, allows certain filter
effects to be defined in JavaScript rather than relying on the preexisting
filters build into canvas and SVG. Not only that but analysis of image data
(as in scientific image processing) would be enabled.
Overall, while I respect the need for security, I think functionality is the
primary objective and that security should be designed around functionality
rather than the reverse. Let's make that a design principle!
cheers
David
----- Original Message -----
From: "Tab Atkins Jr." <[email protected]>
To: "Martin Atkins" <[email protected]>
Cc: <[email protected]>
Sent: Monday, December 22, 2008 2:39 PM
Subject: Re: [whatwg] Embedding images within editable content
On Mon, Dec 22, 2008 at 1:33 PM, Martin Atkins <[email protected]>
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.
~TJ
