W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2008

[whatwg] What should the value attribute be for multi-file upload controls in WF2?

From: Joćo Eiras <joao.eiras@gmail.com>
Date: Fri, 20 Jun 2008 15:20:10 +0100
Message-ID: <e72b1b360806200720q3e032773tfc15c06558e8313d@mail.gmail.com>

> There's a small problem with that too, because we would need a way to handle file names
> that contained quote marks, which is possible on Mac and Linux, but not on Windows.

Not only that, but in unix flavours, paths are separated with : while
in windows they're separated with ;
In *nix special char are escaped with \ while in windows \ separates
directories in paths.
So IMO, it won't be possible to com up with a solution that is cross
platform without making up something completly new.
I'd suggest for HTMLInputElement to have a .files or .paths property
which would be an array of all the files choosen, names only.

On Fri, Jun 20, 2008 at 2:44 PM, Lachlan Hunt <lachlan.hunt at lachy.id.au> wrote:
> Adele Peterson wrote:
>> I'm looking at the Web Forms 2 specification for the multi-file upload
>> control that uses the min/max attributes.  When multiple files are selected,
>> its unclear what the value attribute should contain.
> Assuming you're referring to the value DOM attribute, not the value=""
> content attribute, It seems to be unclear what the value should contain even
> when there's only a single file selected.
> I did some testing to see what each returned.  All tests use this markup to
> obtain the value, using the Live DOM Viewer:
> <!DOCTYPE html>
> <input type="file" id="test" size=100>
> <input type=button onclick="w(document.getElementById('test').value);"
> value="Read Value...">
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Cinput%20type%3D%22file%22%20id%3D%22test%22%20size%3D100%3E%0D%0A%3Cinput%20type%3Dbutton%20onclick%3D%22w(document.getElementById('test').value)%3B%22%20value%3D%22Read%20Value...%22%3E
> In each one, I selected a file named test.txt from within my home or My
> Documents directory.  These are the vaules returned in each browser:
> Windows browsers:
> IE 8:         test.txt
> IE 7 mode:    test.txt
> Firefox 2:    D:\My Documents\test.txt
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 3.1.1: D:\My Documents\test.txt
> Mac browsers:
> Firefox 3:    test.txt
> Opera 9.5:    C:\fake_path\test.txt
> Safari 4 (Developer Preview): /Users/lachlanhunt/test.txt
>> It could contain just the first filename, or a comma separated list of all
>> of the filenames.  I think it will be useful though to add something about
>> this in the specification for consistency.
> Opera 9.5 supports multiple file selection when a max="" attribute is set to
> a value greater than 1.  It currently only returns the fake path of the
> first file, as shown above.  However, the control displays to the user the
> real paths of all files selected as quoted strings separated by semi-colons.
> e.g.
> "/Users/lachlanhunt/test.txt";"/Users/lachlanhunt/other.txt"
> Since Both Firefox 3 and IE 8 only return the file name, and Opera 9.5
> refuses to return the real path anyway, maybe we should define that when
> there's only a single file selected, it returns just the file name. When
> there are multiple files selected, would a string containing the file names,
> each surrounded by quotes and separated by semi-colons work?
> e.g. "test.txt";"other.txt"
> There's a small problem with that too, because we would need a way to handle
> file names that contained quote marks, which is possible on Mac and Linux,
> but not on Windows.
> But it really depends what use cases we need to address.  Do authors ever
> actually obtain the file name using JavaScript for anything?  If so, what
> for?  With multiple file selection, is it likely they would want to inspect
> each individual file name for anything, in which case, should we find a way
> to make it easier to obtain individual file names?
> --
> Lachlan Hunt - Opera Software
> http://lachy.id.au/
> http://www.opera.com/
Received on Friday, 20 June 2008 07:20:10 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:03 UTC