Re: [whatwg] access to local path in input type=file
On 23/03/2008, ddailey [EMAIL PROTECTED] wrote: Perhaps we need a new img type=local-file to cover the use cases??? What I'm ultimately interested in is not really the sort of thing one would expect to use forms for -- neither is doing content analysis inside a textarea however. Those just happen to be the tools that html provides. I know that under discussion in HTML5 is some amount of ability to read and write files locally. Would script access to local images be included in that capability? Gears has some experimental code to load local images. Experimental meaning that the API is still in flux, documentation is non-existant, and it's not bundled as part of official builds yet, but if you check out the latest version of the source code, you can play with it. Dion Almaer has blogged about upcoming Gears APIs at http://almaer.com/blog/category/gears
Re: [whatwg] access to local path in input type=file
On Thu, 20 Mar 2008 20:58:03 -0300, ddailey [EMAIL PROTECTED] wrote: In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user to change the src attribute of an image based on her perusal of local file space. Opera 9.5 doesn't seem to allow access to the path data necessary for accomplishing this rollover effect, and I suspect that may be how it is supposed to be according to emerging standards. ... Hi David, you might be interested in the fileIO proposal [1] from Opera in the WebAPI group at W3C, which is designed to allow for this kind of use case. [1] http://dev.w3.org/2006/webapi/fileio/fileIO.htm cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] access to local path in input type=file
On Sat, Mar 22, 2008 at 3:16 PM, ddailey [EMAIL PROTECTED] wrote: Well then I guess FF2.0012 and IE 7 are not considered modern. My FF3 installation seems flaky so I can't get it to launch. Opera 9. shows only the leaf but FF2 shows the whole path. good guess. http://en.wikipedia.org/wiki/MSIE#Version_7 July 27, 2005 for technical testing... released on January 31, 2006. so 2 years old. http://developer.mozilla.org/en/docs/CVS_Tags Firefox 2 is based on Firefox 1.5, Firefox 1.5 branched August 12, 2005. So it's even older. There is an object called DOMFile. http://mxr.mozilla.org/seamonkey/source/content/base/public/nsIDOMFile.idl#41 which would theoretically let you manipulate the data from a local file the user gave you. It looks like you could do: input type=file id=a img id=b input type=submit onclick=document.getElementById(b).src=document.getElementById(a).files[0].getAsDataURL(); This is of course entirely untested and probably not guaranteed to work or whatever. see https://bugzilla.mozilla.org/show_bug.cgi?id=371432 and http://wiki.mozilla.org/OfflineAppsSummit2006
Re: [whatwg] access to local path in input type=file
timeless replied to my concern: me In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user to change the src attribute of an image based on her perusal of local file space. Opera 9.5 doesn't seem to allow access to the path data necessary for accomplishing this rollover effect, and I suspect that may be how it is supposed to be according to emerging standards. That is the situation when the HTML file is stored on localhost. timeless The web changed, today firefox only provides the leafname, not the full path (this is a good thing for security/privacy reasons), and we don't allow remote access to local content (this is a good thing). Security Error: Content at http://granite.sru.edu/~ddailey/imageUpload.htm may not load or link to file://localhost/78255.png. Actually, when I use Firefox 2.0012, the script contained in that file ( http://granite.sru.edu/~ddailey/imageUpload.htm) actually results in displaying the local path name in the input on that page, as well as in the alert. The data seems to be available, but merely useless for the application at hand. me While I understand the possible risk of exposing a path name of the local file system to script, the various use cases of allowing users to access local images within HTML, the canvas tag and within svg all seem self-evident to me. Is there some standard workaround to allow the user to change the source of an image on a web page to one that is locally stored? timeless in the modern world, you shouldn't be able to embed local images from remote content. if a user wants to see a preview an image they can use their os, file picker, favorite image viewer, etc. Perhaps I should have spelled out the use cases a bit more: I am not interested in previewing the thing, rather I'm interested in working with it application style-- as in photo editing it (in a web-based application) warping it (as with SVG clipPaths in another of the examples I illustrated) in morphing two images together using triangulations, clipPaths, warping, and opacity. I'm interested in doing image analysis, using the canvas tag and producing chromatic histograms, in calcuating differences between two images, in finding median images from a collection. Yes, I know one can buy software (or even freeware) and install it, but I'm interested in among other things in supporting scientists who wish to collaboratively edit one another's images on the web, in allowing a person to create and preview morph and animation sequences locally using remote script. The end user maintains copyright on the images, the script writer retains copyright (and closed source if desired) of the script itself. The app runs in the client rather than on the server, hence allowing the server to play server games rather than doing image processing. The first application I developed (circa 1999) using this ability to access pictures on localhost was an animation generator that allowed the user to import a series of jpg files (as from a movie clip) and to create a small video using setTimeout from which the source code (HTML and script) was generated by the app so that the end user could create the video without herself having to script. The thing worked in the two dominant browsers at the time. Last I looked there was no consensus between browser companies on formats for video in HTML so this still seems like the only way to proceed for the task at hand short of paying bigbucks. you can silently auto submit the image and send them back a version. The privacy (and copyright) exposure to the end user of having to submit the image to a server, have that stored temporarily on the server and then make a round trip back to the local machine seems far worse that the privacy risk of having script read the path of a file the user has already consented to make visible. Perhaps we need a new img type=local-file to cover the use cases??? What I'm ultimately interested in is not really the sort of thing one would expect to use forms for -- neither is doing content analysis inside a textarea however. Those just happen to be the tools that html provides. I know that under discussion in HTML5 is some amount of ability to read and write files locally. Would script access to local images be included in that capability? modern browsers will not expose path, only leaf. Well then I guess FF2.0012 and IE 7 are not considered modern. My FF3 installation seems flaky so I can't get it to launch. Opera 9. shows only the leaf but FF2 shows the whole path. regards, David
Re: [whatwg] access to local path in input type=file
The spec should just say to not expose the full path by default. That way, browser makers can (not must or should or anything like that) provide a I'll be the judge of that! user option to override that globally or per-site if they want. -- Michael
[whatwg] access to local path in input type=file
In the code which follows, both IE7, FF(2.0), and Safari(3.1) allow the user
to change the src attribute of an image based on her perusal of local file
space. Opera 9.5 doesn't seem to allow access to the path data necessary for
accomplishing this rollover effect, and I suspect that may be how it is
supposed to be according to emerging standards. That is the situation when
the HTML file is stored on localhost.
If however, one places the code on a server (see
http://granite.sru.edu/~ddailey/imageUpload.htm) then the program works from
none of the browsers. apologies in advance if I made a mistake :(
While I understand the possible risk of exposing a path name of the local
file system to script, the various use cases of allowing users to access
local images within HTML, the canvas tag and within svg all seem
self-evident to me. Is there some standard workaround to allow the user to
change the source of an image on a web page to one that is locally stored? I
used to have a dozen mini-apps that took advantage of the ability to do this
(they even used to work in Netscape 4 and IE 4), but the programs have all
broken in the past few years in all contexts except IE -- (for example here
http://granite.sru.edu/~ddailey/svg/clipembed.html where the input type=file
script is remarkably simple).
What seems odd to me is that the browsers (except Opera) all seem to expose
the path data to script, despite blocking the easy use of that data. Maybe
I'm missing something obvious.
Apologies, also, if this issue has already been discussed -- my memory seems
never to have been what it should have been.
regards,
David
-code
html
head
script
function change(I,s){
alert(document.getElementById(y).value)
pieces=I.src.split(/)
pieces.pop()
path=pieces.join(/)+/
spieces=s.split(/[\/\\]/)
file=spieces.pop()
path=spieces.join(/)+/
alert(path)
f.Q.value=file://localhost/+s
I.src=f.Q.value
}
/script
/head
body
form id=f
input type=file size=70 id=y onChange=change(z,this.value)br
input type=button value=personalize onclick=z.src=f.Q.value
img src=../p/p0.jpg id=z width=75 height=100 border=0 alt=br
input size=70 id=Q
/form
/body
/html
