Re: Paths exposed in input type=file (was: Re: Moving File API: Directories and System API to Note track?)

On Fri, Sep 21, 2012 at 1:14 AM, James Graham <jgraham@opera.com> wrote:

> On 09/20/2012 11:45 PM, Darin Fisher wrote:
>
>  File path information is already exposed via <input type=file multiple>.
>>
>> "File names may contain partial paths."
>> http://www.whatwg.org/specs/**web-apps/current-work/**
>> multipage/states-of-the-type-**attribute.html#concept-input-**
>> type-file-selected<http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#concept-input-type-file-selected>
>>
>
> I couldn't get any actual browser to expose paths in this way. Did I miss
> something? It also seems to be encouraging wilful violation of the FileAPI
> spec which clearly states that File objects don't return path info [1].
>
> Having a may-level conformance criterion that supposes to override a
> must-level criterion in another spec, but no strong compat. requirement,
> doesn't seem like the optimum path to interoperability or sanity of people
> trying to understand and implement the platform. Is there any reason this
> paragraph shouldn't be considered a bug in HTML?
>

I'm not sure.

Note: Chrome exposes relative file path information via
File.webkitRelativePath.  I haven't reviewed the history of this property.

Exposing partial path information like this is useful in conjunction with
<input type=file directory> [*].  It enables people to upload directories
of files to a web server.  The web server can re-create the exact directory
structure, including empty directories.

Regards,
-Darin

[*]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-April/025764.html


>
> [1] http://dev.w3.org/2006/webapi/**FileAPI/#dfn-file<http://dev.w3.org/2006/webapi/FileAPI/#dfn-file>
>
>
>